SSL 인증서

SSL 인증서 구성 및 로드

그림 1 은 SSL 프록시의 구성 방식에 대한 개요를 표시합니다. 구성 SSL 프록시에는 다음이 포함됩니다.

루트 CA 인증서 구성
CA 프로필 그룹 로드
SSL 프록시 프로필 및 루트 CA 인증서 및 CA 프로파일 그룹 연결
보안 정책에 SSL 프록시 프로파일 적용

그림 1: SSL 프록시 구성 개요 SSL Proxy Configuration Overview

다음 섹션에서 이러한 절차에 대해 자세히 논의할 수 있습니다.

루트 CA 인증서 구성

CA는 트리 구조의 형태로 여러 인증서를 발행할 수 있습니다. 루트 인증서는 트리의 최상위 인증서이며, 이 인증서는 다른 인증서에 sign 사용되는 프라이빗 키입니다. 루트 인증서 바로 아래의 모든 인증서는 루트 인증서의 서명 또는 신뢰성을 갖습니다. 이는 아이덴티티와 notarizing 다소 유사합니다.

루트 CA 증명서를 구성하려면 반드시

루트 CA 인증서 얻기(둘 중 하나 또는 가져오기)
- SRX 시리즈 디바이스에서 Junos OS CLI를 사용하여 루트 CA 인증서를 생성할 수 있습니다.
- 외부 CA에서 인증서 얻기(이 항목에서는 다루지 않음)
루트 CA를 SSL 프록시 프로파일에 적용합니다.

CLI를 사용하여 루트 CA 인증서 생성

CLI에서 자체 서명 인증서를 정의하려면 다음 세부 정보를 제공해야 합니다.

인증서 식별자(이전 단계에서 생성됨)
인증서에 대한 완벽한 FQDN(Domain Name)
인증서를 소유한 엔터티의 이메일 주소
공통 이름 및 관련 조직

Junos OS CLI를 사용하여 루트 CA 인증서를 생성합니다.

운영 모드에서 로컬 디지털 인증서를 위한 PKI 퍼블릭/프라이빗 키 쌍을 생성합니다.
예제:

자체 서명 인증서를 정의합니다.

예제:

옵션을 구성 add-ca-constraint 하여 다른 인증서에 서명하는 데 인증서를 사용할 수 있는지 확인합니다.

구성 모드에서 로드된 인증서를 SSL 프록시 프로파일에 루트 ca로 적용합니다.

예제:

루트 CA를 신뢰할 수 있는 CA로 임포트하여 클라이언트 브라우저로 가져옵니다. 클라이언트 브라우저가 SRX 시리즈 디바이스에서 서명한 인증서를 신뢰하려면 이 요구 사항을 적용해야 합니다. 브라우저에 루트 CA 인증서 가져오기를 참조하십시오.

신뢰할 수 있는 CA 프로파일 그룹 구성

CA 프로필은 인증을 위한 인증서 정보를 정의합니다. 여기에는 SSL 프록시가 새 인증서를 생성할 때 사용하는 공용 키가 포함됩니다. Junos OS를 사용하면 CA 프로파일 그룹을 생성하고 하나의 작업에서 여러 인증서를 로드하고, 그룹의 모든 인증서에 대한 정보를 확인하고, 원치 않는 CA 그룹을 삭제할 수 있습니다. 연결이 시작되면 연결 장치(예: 웹 브라우저)가 인증서가 신뢰할 수 있는 CA에 의해 발행되었는지 여부를 확인합니다. 이러한 인증서가 없으면 브라우저에서 대부분의 웹사이트의 ID를 검증하고 신뢰할 수 없는 사이트로 표시할 수 없습니다.

신뢰할 수 있는 CA 프로필 그룹 구성에는 다음 단계가 포함됩니다.

신뢰할 수 있는 CA 인증서 목록 얻기. 다음 방법 중 하나를 사용하여 신뢰할 수 있는 CA 인증서를 얻을 수 있습니다.
- Junos OS는 신뢰할 수 있는 CA 인증서의 기본 목록을 PEM 파일로 제공합니다(예: trusted_CA.pem). Junos OS 패키지를 다운로드한 후에는 시스템에서 기본 인증서를 사용할 수 있습니다.
  
  운영 모드에서 기본 신뢰할 수 있는 CA 인증서를 로드합니다(그룹 이름은 CA 프로파일 그룹을 식별합니다).
  예제:
  이 방법을 사용하는 것이 좋습니다.
- 신뢰할 수 있는 CA 인증서의 고유한 목록을 정의하고 시스템에서 임포트합니다. 단일 PEM 파일(예: IE-all.pem)에서 신뢰할 수 있는 CA 목록을 확보하고 특정 위치(예: /var/tmp)에 PEM 파일을 저장합니다. 기술 자료 기사 KB23144를 참조하십시오.
  
  운영 모드에서 신뢰할 수 있는 목록을 장비로 로드합니다(그룹 이름은 CA 프로필 그룹을 식별합니다).
  예제:
- Mozilla(https://curl.haxx.se/docs/caextract.html)와 같은 다른 타사에서 최신 CA 번들 목록을 다운로드합니다. 신뢰할 수 있는 인증 기관 목록은 시간이 지남에 따라 변경되어 최신 CA 번들을 사용하도록 보장할 수 있습니다.
- PKI(Public Key Infrastructure)를 사용하여 신뢰할 수 있는 CA 인증서를 임포트합니다. PKI는 신뢰할 수 있는 CA 인증서의 유효성을 검증하고 인증하는 데 도움이 됩니다. 신뢰할 수 있는 CA 증명서가 포함된 CA 프로필 그룹을 생성한 다음 서버 인증을 위해 장비에서 그룹을 임포트합니다.
CA 그룹을 SSL 프록시 프로파일에 연결합니다.
- 모든 CA 프로필 그룹을 첨부합니다.
  
  예제:
- 하나의 CA 프로필 그룹을 첨부합니다(그룹 이름은 CA 프로필 그룹을 식별함).
  
  예제:

CA 프로필 그룹의 모든 인증서에 대한 정보를 쉽게 표시할 수 있습니다.

CA 프로필 그룹을 삭제할 수 있습니다. CA 프로필 그룹을 삭제할 경우 해당 그룹에 속한 모든 인증서가 삭제된다는 점을 유념해야 합니다.

다음 단계

이제 SSL 프록시 프로파일 구성으로 진행하여 보안 정책에 SSL 프록시 프로필을 적용합니다. SSL 프록시 구성을 참조하십시오.

브라우저로 루트 CA 인증서 가져오기

브라우저 또는 시스템이 SSL 프록시 프로파일에 구성된 루트 CA에 의해 서명된 모든 인증서를 자동으로 신뢰하도록 하려면 플랫폼 또는 브라우저에 CA 루트 증명서를 신뢰하도록 지시해야 합니다.

루트 CA 증명서를 임포트하려면 다음을 수행합니다.

구성된 루트 CA에 대한 PEM 형식 파일을 생성합니다.

루트 CA 증명서를 브라우저로 임포트합니다.

Internet Explorer(버전 8.0)에서 오신 경우:
1. 도구 메뉴에서 인터넷 옵션을 선택합니다.
2. Content 탭에서 Certificates를 클릭합니다.
3. Trusted Root Certification Authorities 탭을 선택하고 Import를 클릭합니다.
4. Certificate Import Wizard에서 필수 루트 CA 증명서를 탐색하고 선택합니다.
Firefox에서 오신 경우(버전 39.0):
1. 도구 메뉴에서 옵션을 선택합니다.
2. Advanced 메뉴에서 Certificates 탭을 선택하고 Certificate 보기(View Certificate)를 클릭합니다.
3. Certificate Manager 창에서 Authorities 탭을 선택하고 Import를 클릭합니다.
4. 필요한 루트 CA 증명서를 탐색하고 선택합니다.
Google Chrome에서(45.0):
1. [설정] 메뉴에서 [고급 설정 표시]를 선택합니다.
2. Advanced 메뉴에서 Certificates 탭을 선택하고 Certificate 보기(View Certificate)를 클릭합니다.
3. HTTPS/SSL에서 인증서 관리를 클릭합니다.
4. 인증서 창에서 Trusted Root Certification Authorities 를 선택하고 Import를 클릭합니다.
5. Certificate Import Wizard에서 필수 루트 CA 증명서를 탐색하고 선택합니다.

인증서 체인 구현

Junos OS 릴리스 15.1X49-D30부터 SSL 포워드 프록시는 인증서 체인 구현을 지원합니다. 인증서 체인 개념과 SRX 시리즈 디바이스에서의 구성 방법에 대해 설명합니다.

Certificate Authority (CA)— CA는 신뢰할 수 있는 제3자로서 엔터티의 ID(웹사이트, 이메일 주소, 회사 또는 개인 등)의 신원을 검증하고 암호화 키를 바인딩하여 디지털 인증서를 발급합니다. 조직이 CA 서버를 소유하는 경우, 귀하는 자신의 CA가 되어 자체 서명 인증서를 사용합니다.
Root Certificate—루트 인증서는 신뢰할 수 있는 CA(Certificate Authority)에서 발행한 인증서입니다. 루트 인증서는 트리의 최상위 인증서이며, 이 인증서는 다른 인증서에 서명하는 데 사용되는 전용 키입니다. 루트 인증서 바로 아래의 모든 인증서는 루트 인증서의 서명 또는 신뢰성을 갖습니다. 이러한 인증서는 두 단말 장치 간의 연결을 설정하는 데 사용됩니다.
Intermediate CA Certificate—중간 CA 인증서는 특히 최종 엔티티 인증서를 검증하기 위해 트러스트 루트에서 서명한 하위 인증 인증서입니다.
Certificate Chain - 인증서 체인은 SSL 인증서, 중간 인증서 및 루트 인증서를 포함하는 순서대로 구성된 인증서 목록입니다. 일부 CA(Certificate Authorities)는 루트 증명서에 서명하지 않고 중간 인증서를 사용합니다. 중간 CA는 루트 CA 증명서를 대신하여 인증서에 서명할 수 있습니다. 루트 CA는 신뢰 체인을 형성하는 중간 인증서에 서명합니다.

중간 인증서는 연결 장비(브라우저, 애플리케이션, 모바일 장치 등)가 신뢰할 수 있도록 SSL 인증서와 동일한 서버에 설치되어야 합니다.

연결을 시작할 때 연결 장치(예: 웹 브라우저)는 인증서가 정품인지, 브라우저의 신뢰할 수 있는 저장소에 내장된 신뢰할 수 있는 인증 기관에 의해 발행되는지 확인합니다.

SSL 인증서가 신뢰할 수 있는 CA가 아닌 경우, 연결 장비는 SSL 인증서가 중간 CA에 의해 발행되고 이 중간 CA가 루트 CA에 의해 서명되는지 계속 확인합니다. 루트 CA를 찾을 때까지 검사가 계속됩니다. 루트 CA를 발견하면 보안 연결이 설정됩니다. 루트 CA를 찾지 못하면 연결이 끊기고 웹 브라우저에서 신뢰할 수 없는 잘못된 인증서 또는 인증서에 대한 오류 메시지가 표시됩니다.

이 예에서는 브라우저가 인증서를 신뢰할 수 있도록 인증서 체인을 설치하는 방법을 보여줍니다.

요구 사항
개요
구성

요구 사항

이 기능을 구성하기 전에 디바이스 초기화 이외에는 특별한 구성이 필요하지 않습니다.

개요

이 예에서는 도메인 예.domain-1을 가지며 도메인에 대해 XYZ-Authority에서 인증서를 구입하려고 합니다. 그러나 XYZ -Authority는 Root-CA가 아니며 방문한 웹 브라우저는 Root-CA 인증서만 신뢰합니다. 즉, 해당 인증서는 웹 브라우저에 직접 내장되어 있지 않으므로 명시적으로 신뢰할 수 없습니다.

이 경우 인증서 체인(중간 인증서)을 사용하여 다음과 같은 방식으로 트러스트가 설정됩니다.

토폴로지

그림 2를 통해 이 체인을 시각화해 보겠습니다. 이 이미지는 루트 CA 인증서부터 최종 사용자 인증서까지 전체 인증서 체인을 묘사합니다. 체인은 최종 사용자 인증서에서 종료됩니다.

그림 2: 인증서 소유자에서 루트 CA Certification Path from the Certificate Owner to the Root CA

로의 인증 경로

표 1: 인증서 체이닝 세부 정보
사용자	인증서 사용	서명자	형식
example.domain-1	최종 사용자 인증서	XYZ-Authority	최종 사용자 인증서. CA에서 구입한 솔루션입니다.
XYZ-Authority	Certificate-1	중급 CA-1	중급 인증서
중급 CA-1	Certificate-2	중급 CA-2	중급 인증서
중급 CA-2	Certificate-3	중급 CA-3	중급 인증서
중급 CA-3	Certificate-4	루트 예제 권한(root-example-authority)입니다. 이것은 루트 CA입니다.	루트 인증서 이 인증서는 웹 브라우저에 직접 내장되어 있습니다. 따라서 명시적으로 신뢰할 수 있습니다.

서버 예제.domain-1에 최종 사용자 인증서를 설치할 때는 모든 중간 인증서를 번들하고 최종 사용자 인증서와 함께 설치해야 합니다. 인증서 체인에는 Certificate-1에서 Root-CA 인증서로 시작하는 모든 인증서가 포함됩니다. 웹 브라우저는 루트 CA를 신뢰하기 때문에 모든 중간 인증서를 암묵적으로 신뢰합니다. SSL 인증서 체인이 잘못되거나 깨진 경우 일부 장치에서 인증서를 신뢰할 수 없습니다.

참고:

모든 인증서는 PEM(Privacy-Enhanced Mail) 형식이어야 합니다.
연결된 인증서 파일을 장비로 임포트하면 CA는 서명된 서버 증명서에 추가해야 하는 연쇄 인증서의 번들을 제공합니다. 서버 증명서는 연결된 파일의 연쇄 인증서 앞에 나타나야 합니다.

구성

SSL 인증서 체인 구성에는 다음 작업이 포함됩니다.

서명 인증서와 해당 키가 포함된 CA에서 SSL 인증서를 구입합니다.
신뢰할 수 있는 CA 프로필 그룹을 구성합니다.
서명 인증서와 키를 장비에 로드합니다.
PKI(Public Key Infrastructure) 메모리에 중간 및 루트 CA를 로드합니다. 이 인증서 파일에는 필요한 모든 CA 인증서가 PEM 형식으로 서로 1개씩 포함되어 있습니다.
중간 또는 루트 CA 증명서에 대해 신뢰할 수 있는 CA 프로필을 생성합니다.
보안 정책에 SSL 프록시 프로필을 구성하고 적용하여 CA로부터 받은 서명 인증서를 사용하도록 장비를 설정합니다. SSL 포워드 프록시는 이 인증서 체인 정보(CA 인증서 프로파일 이름)를 해당 SSL 프로파일에 저장합니다. 보안 정책 구현의 일환으로 인증서 체인 정보와 CA 인증서를 갖는 SSL 프로필이 사용됩니다.

인증서 체인 처리에는 다음 구성 요소가 포함됩니다.

관리자는 인증서 체인과 로컬 인증서(인증서 서명)를 PKI 데몬 인증서 캐시에 로드합니다.
nsd(Network Security Daemon)는 SSL 프록시 프로파일에 구성된 서명 인증서에 대한 인증서 체인 정보를 제공하기 위해 PKI 데몬에 요청을 보냅니다.

이 예에서는 CA로부터 SSL 인증서를 이미 구매한 것으로 가정합니다.

디바이스에서 인증서 체인 구성

단계별 절차

인증서 체인을 구성하려면 다음을 수행합니다.

로컬 인증서를 PKI 메모리에 로드합니다.

다음 메시지가 표시됩니다.

인증서 ID는 SSL 프록시 프로파일의 root-ca 섹션에서 사용됩니다.

PKI 메모리에 중간 또는 루트 CA 증명서를 로드합니다.

CA 프로필에는 인증에 사용되는 인증서 정보가 포함되어 있습니다. 여기에는 SSL 프록시가 새 인증서를 생성할 때 사용하는 공용 키가 포함됩니다.

이 인증서는 인증서 체인으로 첨부됩니다.

CA 프로필 그룹을 SSL 프록시 프로파일에 연결합니다. 신뢰할 수 있는 CA를 한 번에 연결하거나 하나의 작업으로 모두 로드할 수 있습니다.

서명 증명서를 SSL 프록시 프로파일에 루트 ca로 적용합니다.

보안 정책을 생성하고 정책에 대한 일치 기준을 지정합니다. 일치 기준으로 SSL 프록시를 사용할 트래픽을 지정합니다. 이 예에서는 요구 사항에 따라 보안 존을 이미 생성했다고 가정합니다.
SSL 포워드 프록시는 이 인증서 체인 정보(CA 인증서 프로파일 이름)를 각 SSL 프로파일에 저장합니다. 보안 정책 구현의 일환으로 인증서 체인 정보와 CA 인증서를 갖는 SSL 프로필이 사용됩니다.

연결된 웹 브라우저(즉, 클라이언트)에서 인증서 체인을 볼 수 있습니다.

서버 인증

클라이언트와 장비 간의 암묵적 신뢰(클라이언트가 장비에서 생성한 인증서를 허용하기 때문에)는 SSL 프록시의 중요한 측면입니다. 서버 인증이 손상되지 않도록 하는 것이 매우 중요합니다. 그러나 실제로는 이상 징후를 가진 자동 서명 인증서와 인증서가 풍부합니다. 예외에는 만료된 인증서, 도메인 이름과 일치하지 않는 일반 이름 인스턴스 등이 포함될 수 있습니다.

서버 인증은 SSL 프록시 프로파일에 옵션을 설정 ignore-server-auth-failure 하여 관리됩니다. 이 옵션 설정의 결과는 표 2에서 확인할 수 있습니다.

표 2: 서버 인증 실패 무시 옵션
SSL 프록시 프로파일 작업	결과
`ignore-server-auth-failure` 옵션이 설정되지 않음(기본 옵션)	인증이 성공하면 키를 교체하고 프록시 프로파일의 루트 CA 증명서에 구성된 발행자 이름을 발급자 이름으로 변경하여 새로운 인증서가 생성됩니다. 인증에 실패하면 연결이 끊어지게됩니다.
`ignore-server-auth-failure` 옵션이 설정되어 있습니다.	인증서가 자체 서명되면 키를 대체하여 새 인증서가 생성됩니다. 발행자 이름은 변경되지 않습니다. 이를 통해 클라이언트 브라우저가 인증서가 유효하지 않다는 경고를 표시합니다. 인증서가 만료되었거나 일반적인 이름이 도메인 이름과 일치하지 않으면 키를 교체하고 발급자 이름을 SSL-PROXY로 변경하여 새 인증서가 생성됩니다. DUMMY_CERT:SRVR 인증 실패로 인해 생성됨. 이를 통해 클라이언트 브라우저가 인증서가 유효하지 않다는 경고를 표시합니다. 웹 사이트를 구성하면 전혀 인증되지 않기 때문에 인증에 이 옵션을 권장하지 않습니다. 그러나 이 옵션을 사용하여 드롭된 SSL 세션의 근본 원인을 효과적으로 식별할 수 있습니다. SSL 프록시를 위한 디버깅 및 추적 활성화를 참조하십시오.

클라이언트 인증

현재 클라이언트 인증은 SSL 프록시에서 지원되지 않습니다. 서버가 클라이언트 인증을 요청하는 경우 증명서를 사용할 수 없다는 경고가 발행됩니다. 경고는 서버가 계속할지 또는 종료할지 여부를 결정할 수 있게 해줍니다.

SSL Proxy에 대한 인증서 철회 목록

SSL Proxy에 대한 인증서 철회 목록으로 작업

CA(Certificate Authority)는 CRL(Certificate Revocation List)을 사용하여 취소된 인증서 목록을 주기적으로 게시합니다. 보안 장비는 가장 최근에 발행된 CRL을 다운로드하여 캐시합니다. CRL에는 만료일 전에 취소된 일련 번호가 포함된 디지털 인증서 목록이 포함되어 있습니다.

CA는 인증서가 손상될 가능성이 있을 경우 발행된 인증서를 취소합니다. 인증서를 취소해야 하는 다른 이유는 다음과 같습니다.

지정되지 않음(특별한 이유가 부여되지 않음).
인증서를 발급한 인증서 또는 CA와 관련된 전용 키가 손상되었습니다.
인증서의 소유자는 더 이상 인증서 발급업체와 제휴하지 않습니다.
다른 인증서가 원래 인증서를 대체합니다.
인증서를 발급한 CA의 작동이 중단되었습니다.
추가 조치가 있을 때까지 인증서가 보류 중입니다. 취소된 것으로 처리되지만 나중에 수락될 수 있습니다.

참여하는 장비가 디지털 인증서를 사용하는 경우 인증서 서명 및 유효성을 검사합니다. 기본적으로 CRL 검증은 SSL 프록시 프로파일에서 활성화됩니다.

Junos OS 릴리스 15.1X49-D30 및 Junos OS Release 17.3R1부터 SRX 시리즈 디바이스는 CRL(Certificate Revocation List)을 지원합니다. SRX 시리즈 디바이스에서 CRL 검증은 서버에서 취소된 인증서를 검사하는 작업이 포함됩니다.

SRX 시리즈 디바이스에서 SSL 프록시 프로파일에 대한 인증서 철회 검사가 기본적으로 활성화됩니다. CRL 검증을 활성화하거나 비활성화하여 특정 보안 요구 사항을 충족할 수 있습니다.

CRL 검증을 비활성화합니다.

CRL 검증을 다시 활성화합니다.

CRL 다운로드 실패 또는 루트 또는 중간 인증서의 CRL 경로 사용 불가능과 같은 이유로 CRL 정보를 사용할 수 없는 경우 세션을 허용하거나 드롭할 수 있습니다.

CRL 정보를 사용할 수 없는 경우 세션을 허용합니다.

CRL 정보를 사용할 수 없는 경우 세션을 드롭합니다.

해지 상태에서 사용할 수 있는 신뢰할 수 있는 확인 없이 인증서를 수락하도록 SRX 시리즈 디바이스를 구성하고 인증서가 취소되고 철회 사유가 보류된 경우 세션을 허용합니다.

SSL 성능 향상

SRX 시리즈 장비의 SSL 성능 향상에는 다음과 같은 기능이 포함됩니다.

SSL 성능 최적화
세션 재개
세션 재협상
도메인 이름에 대한 동적 해석

SSL 성능 최적화

SSL/TLS 핸드셰이크는 CPU 집약적인 프로세스입니다. SSL/TLS는 웹에서 가장 널리 사용되는 보안 프로토콜이기 때문에 성능은 웹 성능에 상당한 영향을 미칩니다.

Junos OS 릴리스 15.1X49-D120부터 성능을 최적화하기 위해 다음 옵션을 사용할 수 있습니다.

최적화된 RSA 키 교환 사용
AEAD(Authenticated Encryption with ASSOCIATED Data)—AES128-CBC-SHA, AES256-CBC-SHA 사용
인증서 캐시 유지—인증서 캐시는 서버 인증서 세부 사항과 함께 인증된 서버 인증서를 저장합니다. SSL/TLS 핸드셰이크 도중에 SSL 프록시는 새로운 인증된 인증서를 생성하는 대신 캐시된 인덱싱된 인증서를 클라이언트에 제공할 수 있습니다.

SSL 성능이 향상되어 보안 및 사용자 경험 극대화 없이 웹 사이트 성능이 향상됩니다.

인증서 캐시에 대한 다음 설정을 선택적으로 구성할 수 있습니다. 그러나 기본값을 유지하는 것이 좋습니다.

예제:

(선택사항) 인증서 캐시 타임아웃 값 설정(예: 300초) .
이 예에서 인증서 캐시는 인증서 세부 정보를 300초 동안 저장합니다. 기본 타임아웃 값은 600초입니다.
(선택사항) 인증서 캐시를 비활성화합니다.
인증서 캐시를 비활성화하면 새 연결에 대한 SSL 전체 핸드셰이크를 허용합니다. 기본적으로 인증서 캐시가 활성화됩니다.
(선택사항) 기존 인증서 캐시를 무효화합니다.
이 예에서는 CRL(Certificate Revocation list)이 업데이트되면 장비가 기존 인증서 캐시를 무효로 만듭니다. 기본적으로 CRL 업데이트의 잘못된 인증서 캐시는 비활성화됩니다.

세션 재개

SSL 세션 재개는 이미 협상된 세션 ID를 사용하여 이전 세션을 재개하는 메커니즘을 제공합니다. 세션 재개는 전체 SSL 핸드셰이크 및 새로운 기본 키 생성의 연산 오버헤드를 클라이언트와 서버에 절약합니다.

세션 재개는 핸드셰이크 프로세스를 단축하고 SSL 트랜잭션을 가속화하여 성능을 향상시키는 동시에 적절한 수준의 보안을 유지합니다.

TLS 1.2는 세션 식별자 및 세션 티켓 메커니즘을 통해 세션 재개를 지원합니다. SSL 세션 재개에는 다음 단계가 포함됩니다.

세션 캐싱 메커니즘은 마스터 전 암호 키 및 클라이언트 및 서버 모두에 대한 합의된 암호와 같은 세션 정보를 캐시합니다.
Session ID는 캐시된 정보를 식별합니다.
후속 연결에서 양 당사자는 사전 마스터 암호 키를 만드는 대신 세션 ID를 사용하여 정보를 검색하는 데 동의합니다.

Junos OS 릴리스 22.1R1부터 TLS 1.3은 SSL 프록시의 PSK(Pre-shared Key)를 사용하여 세션 재개를 지원합니다. PSK를 사용한 세션 재개를 통해 SSL 핸드셰이크 오버헤드를 줄이기 위해 이전에 설정된 공유 암호 키를 사용하여 세션을 재개할 수 있습니다.

PSK는 최초 TLS 핸드셰이크에서 파생된 고유의 암호화 키입니다. 성공적인 TLS 핸드셰이크 이후 서버는 PSK ID를 클라이언트로 보냅니다. 클라이언트는 향후 핸드셰이크에서 해당 PSK ID를 사용하여 관련 PSK의 사용을 협상하여 세션을 재개합니다.

TLS1.3이 포함된 SSL 세션 재개에는 다음 단계가 포함됩니다.

최초 TLS 핸드셰이크 이후 서버는 PSK ID(PSK의 암호화된 사본)가 포함된 새로운 세션 티켓 메시지를 클라이언트로 보냅니다.
그런 다음 클라이언트가 세션을 재개하려고 할 때 Hello 메시지의 서버에 동일한 세션 티켓을 보냅니다.
서버는 메시지를 복호화하고 PSK를 식별하며 캐시에서 세션 정보를 검색하여 세션을 재개합니다.

SSL-I(SSL 시작)는 ECDHE 키 교환 모드에서 PSK를 사용하고, SSL-T(SSL-T)는 ECDHE 교환 모드에서 PSK 및 PSK를 사용합니다.

SSL 프록시 세션은 세션 재개를 위해 TLS1.3과 TLS1.2 및 이전 버전 간의 상호 운영성을 지원합니다.

기본적으로 SSL 프록시에 대해 세션 재개가 활성화됩니다. 요구 사항에 따라 세션 재개 또는 재 활성화를 취소할 수 있습니다.

세션 재개를 지우려면:

세션 재개를 다시 사용하려면 다음을 수행합니다.

세션 타임아웃 값을 구성하려면 다음 명령을 사용합니다.

300초에서 86400초 사이의 타임아웃 값을 구성할 수 있습니다. 기본값은 86400초(24시간)입니다.

세션 재협상

SRX 시리즈 디바이스는 세션 재협상을 지원합니다. 세션이 생성되고 SSL 터널 전송이 설정되면 SSL 매개변수의 변경에 대한 재협상이 필요합니다. SSL 프록시는 보안(RFC 5746)과 비보안(TLS v1.0, TLS v1.1 및 TLS v1.2) 재협상을 모두 지원합니다. 세션 재개가 활성화되면 세션 재협상은 다음과 같은 상황에서 유용합니다.

SSL 세션이 장기간 진행된 후에는 암호 키를 새로 고쳐야 합니다.
보다 안전한 연결을 위해 더 강력한 암호가 적용되어야 합니다.

인증서 또는 암호 강도 또는 신뢰할 수 있는 CA 목록을 변경하여 SSL 프록시 프로필을 수정하는 경우 수정된 정책을 커밋할 때 시스템에서 캐시 엔트리가 플러시됩니다. 이 경우, 새로운 SSL 매개변수를 설정하려면 완벽한 핸드셰이크가 필요합니다. (비SL 세션에는 영향이 없습니다.)

SSL 프록시 프로필이 변경되지 않으면 해당 프로파일에 해당하는 캐시 항목이 플러시되지 않고 세션이 계속됩니다.

도메인 이름에 대한 동적 해석

도메인 이름과 관련된 IP 주소는 동적이며 언제든지 변경할 수 있습니다. 도메인 IP 주소가 변경되면 SSL 프록시 구성으로 전파됩니다(방화벽 정책 구성에서 수행되는 것과 유사함).

이 페이지의