SSL 인증서

SSL 인증서 구성 및 로드

그림 1 은 SSL 프록시가 어떻게 구성되었는지에 대한 개요를 표시합니다. SSL 프록시 구성에는 다음이 포함됩니다.

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

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

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

루트 CA 인증서 구성

CA는 트리 구조의 형태로 여러 인증서를 실행할 수 있습니다. 루트 인증서는 트리의 최상단 인증서이며, 프라이빗 키는 다른 인증서에 sign 사용됩니다. 루트 인증서 바로 아래의 모든 인증서는 루트 인증서의 서명 또는 신뢰성을 상속합니다. 이는 ID와 notarizing 다소 비슷합니다.

루트 CA 인증서를 구성하려면

루트 CA 인증서 얻기(또는 가져오는 것)
- SRX 시리즈 방화벽에서 Junos OS CLI를 사용하여 루트 CA 인증서를 생성할 수 있습니다.
- 외부 CA에서 인증서를 획득합니다(이 주제에서는 다루지 않음)
루트 CA를 SSL 프록시 프로필에 적용합니다.

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

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

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

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)에서 신뢰할 수 있는 SA 목록을 얻고 PEM 파일을 특정 위치(예: /var/tmp)에 저장합니다. 기술 자료 기사 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. 콘텐츠 탭에서 인증서를 클릭합니다.
3. 신뢰할 수 있는 루트 인증 기관 탭을 선택하고 가져오기를 클릭합니다.
4. 인증서 가져오기 마법사에서 필요한 루트 CA 인증서로 이동하여 선택합니다.
Firefox에서(버전 39.0):
1. 도구 메뉴에서 옵션을 선택합니다.
2. 고급 메뉴에서 인증서 탭을 선택하고 인증서 보기를 클릭합니다.
3. 인증서 관리자 창에서 당국 탭을 선택하고 가져오기를 클릭합니다.
4. 필요한 루트 CA 인증서로 이동하여 선택합니다.
Google Chrome(45.0):
1. 설정 메뉴에서 고급 설정 표시를 선택합니다.
2. 고급 메뉴에서 인증서 탭을 선택하고 인증서 보기를 클릭합니다.
3. HTTPS/SSL에서 인증서 관리를 클릭합니다.
4. 인증서 창에서 신뢰할 수 있는 루트 인증 당국을 선택하고 가져오기를 클릭합니다.
5. 인증서 가져오기 마법사에서 필요한 루트 CA 인증서로 이동하여 선택합니다.

인증서 체인 구현

릴리스 15.1X49-D30 Junos OS SSL 포워드 프록시가 인증서 체인 구현을 지원합니다. 인증서 체인 개념 이해와 SRX 시리즈 방화벽에서 구성하는 방법에 대해 토론할 수 있습니다.

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

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

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

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

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

요구 사항
개요
구성

요구 사항

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

개요

이 예에서는 도메인 예.domain-1이 있으며 도메인에 대한 XYZ-Authority의 인증서를 구입하려고 합니다. 그러나 XYZ -Authority는 루트 CA가 아니며 방문 웹 브라우저는 루트-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에 대한 최종 사용자 인증서를 설치할 때는 모든 중간 인증서를 번들하고 최종 사용자 인증서와 함께 설치해야 합니다. 인증서 체인에는 인증서-1에서 루트 CA 인증서로 시작하는 모든 인증서가 포함됩니다. 웹 브라우저가 루트 CA를 신뢰하기 때문에 모든 중간 인증서도 암묵적으로 신뢰합니다. SSL 인증서 체인이 유효하지 않거나 손상된 경우, 일부 디바이스에서 인증서를 신뢰할 수 없습니다.

참고:

모든 인증서는 PEM(Privacy-Enhanced Mail) 형식이어야 합니다.
연결된 인증서 파일을 디바이스로 가져올 때 CA는 서명된 서버 인증서에 추가해야 하는 연결 인증서 번들을 제공합니다. 서버 인증서는 결합된 파일의 연동된 인증서 앞에 나타나야 합니다.

구성

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

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

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

관리자는 인증서 체인과 로컬 인증서(인증서 서명)를 PKI 데몬 인증서 캐시에 로드합니다.
네트워크 보안 데몬(nsd)은 SSL 프록시 프로필에 구성된 서명 인증서에 대한 인증서 체인 정보를 제공하기 위해 PKI 데몬에 요청을 보냅니다.

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

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

단계별 절차

인증서 체인 구성 방법:

로컬 인증서를 PKI 메모리에 로드합니다.
다음과 같은 메시지가 표시됩니다.
인증서 ID는 SSL 프록시 프로필의 root-ca 섹션에 따라 사용됩니다.

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

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

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

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

SSL 프록시 프로필에서 서명 인증서를 root-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 AUTH 실패로 인해 생성됩니다. 이를 통해 클라이언트 브라우저가 인증서가 유효하지 않다는 경고를 표시합니다. 인증을 위해 이 옵션을 권장하지 않습니다. 구성하면 웹 사이트가 전혀 인증되지 않기 때문입니다. 그러나 이 옵션을 사용하여 손실된 SSL 세션의 근본 원인을 효과적으로 식별할 수 있습니다. SSL 프록시에 대한 디버깅 및 추적 활성화를 참조하십시오.

클라이언트 인증

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

SSL 프록시에 대한 인증서 해지 목록

SSL 프록시에 대한 인증서 해지 목록 작업

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

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

지정되지 않았습니다(특별한 이유가 없습니다).
인증서를 발급한 인증서 또는 CA와 연결된 비공개 키가 손상되었습니다.
인증서 소유자는 더 이상 인증서 발행사와 제휴하지 않습니다.
다른 인증서는 원래 인증서를 대체합니다.
인증서를 발급한 CA의 작동이 중단되었습니다.
인증서는 추가 작업을 보류 중입니다. 취소된 것으로 처리되지만 나중에 수락될 수 있습니다.

참여 디바이스가 디지털 인증서를 사용할 때 인증서 서명 및 유효성을 확인합니다. 기본적으로 SSL 프록시 프로필에서 CRL 검증이 활성화됩니다.

Junos OS 릴리스 15.1X49-D30 및 Junos OS 릴리스 17.3R1부터 SRX 시리즈 방화벽은 CRL(인증서 해지 목록)을 지원합니다. SRX 시리즈 방화벽에 대한 CRL 검증에는 서버에서 취소된 인증서를 확인하는 것이 포함됩니다.

방화벽 SRX 시리즈 인증서 해지 검사는 기본적으로 SSL 프록시 프로필에 대해 활성화됩니다. CRL 검증을 활성화하거나 비활성화하여 특정 보안 요구 사항을 충족할 수 있습니다.

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

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

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

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

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

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

SSL 성능 향상

SRX 시리즈 방화벽의 SSL 성능 향상에는 다음 기능이 포함됩니다.

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

SSL 성능 최적화

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

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

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

SSL 성능을 향상하면 보안과 사용자 경험 극대화 없이 웹사이트 성능을 향상할 수 있습니다.

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

예제:

(선택 사항) 인증서 캐시 시간 제한 값(예: 300초)을 설정합니다.
이 예에서 인증서 캐시는 인증서 세부 정보를 300초 동안 저장합니다. 기본 타임아웃 값은 600초입니다.
(선택 사항) 인증서 캐시를 비활성화합니다.
인증서 캐시를 비활성화하면 디바이스에서 새 연결을 위한 SSL 전체 핸드셰이크를 허용합니다. 기본적으로 인증서 캐시가 활성화되어 있습니다.
(선택 사항) 기존 인증서 캐시를 무효화합니다.
이 예에서 디바이스는 인증서 해지 목록(CRL)이 업데이트되면 기존 인증서 캐시를 무효화합니다. 기본적으로 CRL 업데이트에 대한 인증서 캐시를 무효화하는 것은 비활성화됩니다.

세션 재개

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

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

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

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

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

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

TLS1.3을 통한 SSL 세션 재개에는 다음 단계가 포함됩니다.

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

SSL-I(SSL-I)는 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 매개 변수를 설정하려면 완전한 핸드셰이크가 필요합니다. (비 SSL 세션에는 영향이 없습니다.)

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

SMTP 세션에 대한 StartTLS 협상

StartTLS는 초기 일반 TCP 연결에서 보다 안전한 TLS 연결로 SMTP 세션을 활성화합니다. StartTLS는 피어 간의 성공적인 협상 후 TLS 계층에서 서버와 클라이언트 간의 SMTP 세션을 허용합니다. StartTLS는 보안 SSL/TLS 연결로 기존의 안전하지 않은 일반 SMTP 연결을 업그레이드합니다.

클라이언트로부터 StartTLS를 수신하지 않은 경우 세션을 무시하기 전에 대기 시간을 결정할 수 있는 임계값을 설정할 수 있습니다.

다음 옵션을 구성할 수 있습니다.

byte-threshold — 클라이언트로부터 StartTLS를 수신하지 않은 경우 세션을 무시하기 전에 허용된 암호화되지 않은 세션의 최소 바이트입니다. 범위 100 ~ 300입니다.
packet-threshold — StartTLS가 클라이언트로부터 수신되지 않은 경우 세션을 무시하기 전에 클라이언트-서버 방향으로 허용된 암호화되지 않은 패킷 수입니다. 범위 1~15.

예제:

이 예에서 SSL 프록시는 100바이트의 일반(암호화되지 않은) SMTP 트래픽을 허용합니다. 100바이트에 도달한 후 클라이언트에서 StartTLS를 수신하지 않으면 세션을 무시합니다.

이 예에서 SSL 프록시는 2개의 일반(암호화되지 않은) SMTP 트래픽 패킷을 허용합니다. 2개의 패킷에 도달한 후 클라이언트로부터 StartTLS를 수신하지 않으면 세션을 무시합니다.

도메인 이름의 동적 해결

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

이 페이지에서