TSL 프로토콜. SSL 및 TLS 프로토콜이 활성화되어 있는지 확인하십시오. TLS 핸드셰이크는 어떻게 작동하나요?

03.03.2020

우리의 모든 주장은 운영 체제가 모든 적절한 업데이트와 패치가 설치되어 있는 Windows XP 이상(Vista, 7 또는 8)이라는 사실을 기반으로 합니다. 이제 한 가지 조건이 더 있습니다. 우리는 "진공 상태의 구형 Ognelis"가 아닌 최신 버전의 브라우저에 대해 이야기하고 있습니다.

따라서 우리는 최신 버전의 TLS 프로토콜을 사용하고 오래된 버전과 SSL을 전혀 사용하지 않도록 브라우저를 구성합니다. 적어도 이론상으로는 가능합니다.

그리고 이론에 따르면 Internet Explorer는 이미 버전 8부터 TLS 1.1 및 1.2를 지원하지만 Windows XP 및 Vista에서는 그렇게 하도록 강요하지 않을 것입니다. 도구/인터넷 옵션/고급을 클릭하고 "보안" 섹션에서 SSL 2.0, SSL 3.0, TLS 1.0을 찾습니다. 다른 것을 찾으셨나요? 축하합니다. TLS 1.1/1.2를 가지게 되었습니다! 찾지 못했다면 Windows XP 또는 Vista를 사용하고 있으며 레드몬드에서는 귀하를 정신 장애자로 간주합니다.

따라서 모든 SSL 상자를 선택 취소하고 사용 가능한 모든 TLS 상자를 선택하십시오. TLS 1.0만 사용할 수 있다면 그렇게 하세요. 최신 버전만 사용할 수 있다면 해당 버전만 선택하고 TLS 1.0을 선택 취소하는 것이 좋습니다. 나중에 일부 사이트가 HTTPS를 통해 열리지 않더라도 놀라지 마세요. 그런 다음 "적용" 및 "확인" 버튼을 클릭합니다.

Opera를 사용하면 더 쉽습니다. 도구/일반 설정/고급/보안/보안 프로토콜 등 다양한 프로토콜 버전의 실제 연회를 제공합니다. 우리는 무엇을 봅니까? TLS 1.1 및 TLS 1.2에 대해서만 확인란을 남겨 둔 전체 세트에서 "세부 정보"버튼을 클릭하고 "256 비트 AES"로 시작하는 줄을 제외한 모든 줄을 선택 취소합니다. 끝. 목록 시작 부분에 “256비트 AES( 익명의 DH/SHA-256), 이 항목도 선택 취소하세요. "확인"을 클릭하고 보안을 누리십시오.

그러나 Opera에는 한 가지 이상한 속성이 있습니다. TLS 1.0이 활성화된 경우 보안 연결을 설정해야 하는 경우 사이트의 최신 버전 지원에 관계없이 즉시 이 버전의 프로토콜을 사용합니다. 예를 들어, 왜 귀찮게합니까? 모든 것이 정상이고 모든 것이 보호됩니다. TLS 1.1 및 1.2만 활성화된 경우 고급 버전이 먼저 시도되며 사이트에서 지원하지 않는 경우에만 브라우저가 버전 1.1로 전환됩니다.

그러나 구형 Ognelis Firefox는 우리를 전혀 만족시키지 못할 것입니다: 도구/설정/고급/암호화: 우리가 할 수 있는 것은 SSL을 비활성화하는 것뿐입니다. TLS는 버전 1.0에서만 사용할 수 있으며 할 일이 없습니다. 체크 표시를 남겨 둡니다.

그러나 비교를 통해 최악의 상황을 알 수 있습니다. Chrome과 Safari에는 사용할 암호화 프로토콜에 대한 설정이 전혀 포함되어 있지 않습니다. 우리가 아는 한, Safari는 Windows OS 버전에서 1.0보다 최신 TLS 버전을 지원하지 않으며, 이 OS의 새 버전 출시가 중단되었으므로 지원되지 않을 것입니다.

우리가 아는 한 Chrome은 TLS 1.1을 지원하지만 Safari의 경우와 마찬가지로 SSL 사용을 거부할 수 없습니다. Chrome에서는 TLS 1.0을 비활성화할 수 있는 방법이 없습니다. 그러나 TLS 1.1을 실제로 사용하면 큰 의문이 생깁니다. 처음에 켰다가 작동 문제로 인해 꺼졌고, 판단할 수 있는 한 아직 다시 켜지지 않았습니다. 즉, 지원이 있는 것 같지만 꺼진 것 같고, 사용자가 다시 켤 방법이 없는 것입니다. Firefox에서도 마찬가지입니다. 실제로 TLS 1.1을 지원하지만 아직 사용자가 사용할 수는 없습니다.

위 여러 글자의 요약입니다. 오래된 버전의 암호화 프로토콜을 사용할 경우 일반적인 위험은 무엇입니까? 다른 사람이 귀하의 사이트 보안 연결에 접속하여 "거기" 및 "거기"의 모든 정보에 액세스할 수 있다는 사실입니다. 실질적으로 그는 자신의 이메일 상자, 고객-은행 시스템의 계좌 등에 대한 전체 액세스 권한을 갖게 됩니다.

실수로 다른 사람의 보안 연결에 침입할 가능성은 거의 없습니다. 우리는 악의적인 행동에 대해서만 이야기하고 있습니다. 그러한 행동이 발생할 가능성이 낮거나 보안 연결을 통해 전송된 정보가 특별히 중요하지 않은 경우 귀찮게 TLS 1.0만 지원하는 브라우저를 사용할 필요가 없습니다.

그렇지 않으면 선택의 여지가 없습니다. Opera와 TLS 1.2만 있습니다(TLS 1.1은 TLS 1.0의 개선일 뿐이며 부분적으로 보안 문제를 상속받습니다). 그러나 우리가 즐겨찾는 사이트는 TLS 1.2를 지원하지 않을 수 있습니다. :(

TLS는 인터넷의 노드 간에 안정적이고 안전한 연결을 제공하는 프로토콜인 SSL의 후속 프로토콜입니다. 브라우저 및 클라이언트-서버 애플리케이션을 포함한 다양한 클라이언트 개발에 사용됩니다. Internet Explorer의 TLS란 무엇입니까?

기술에 대해 조금

금융 거래에 참여하는 모든 기업과 조직은 패킷 도청 및 침입자의 무단 액세스를 방지하기 위해 이 프로토콜을 사용합니다. 이 기술은 침입자의 공격으로부터 중요한 연결을 보호하도록 설계되었습니다.

기본적으로 해당 조직에서는 내장 브라우저를 사용합니다. 경우에 따라 - Mozilla Firefox.

프로토콜 활성화 또는 비활성화

SSL 및 TLS 기술 지원이 비활성화되어 일부 사이트에 액세스할 수 없는 경우가 있습니다. 브라우저에 알림이 나타납니다. 그렇다면 보안 통신을 계속 즐길 수 있도록 프로토콜을 어떻게 활성화할 수 있습니까?
1. 시작을 통해 제어판을 엽니다. 또 다른 방법은 Explorer를 열고 오른쪽 상단에 있는 톱니바퀴 아이콘을 클릭하는 것입니다.

2. "브라우저 옵션" 섹션으로 이동하여 "고급" 블록을 엽니다.

3. "TLS 1.1 및 TLS 1.2 사용" 옆의 확인란을 선택합니다.

4. 확인을 클릭하여 변경 사항을 저장합니다. 특히 온라인 뱅킹을 사용하는 경우 권장되지 않는 프로토콜을 비활성화하려면 동일한 항목을 선택 취소하십시오.

1.0과 1.1, 1.2의 차이점은 무엇입니까? 1.1은 TLS 1.0의 단점을 부분적으로 물려받은 약간 개선된 버전입니다. 1.2는 가장 안전한 프로토콜 버전입니다. 반면에 이 프로토콜 버전을 활성화하면 모든 사이트를 열 수 있는 것은 아닙니다.

아시다시피 Skype 메신저는 Windows 구성 요소로 Internet Explorer에 직접 연결됩니다. 설정에서 TLS 프로토콜을 선택하지 않으면 Skype에 문제가 발생할 수 있습니다. 프로그램은 단순히 서버에 연결할 수 없습니다.

Internet Explorer 설정에서 TLS 지원을 비활성화하면 프로그램의 모든 네트워크 관련 기능이 작동하지 않습니다. 더욱이, 귀하의 데이터 안전은 이 기술에 달려 있습니다. 본 브라우저에서 금융 거래(온라인 상점에서의 구매, 온라인 뱅킹이나 전자 지갑을 통한 송금 등)를 수행하는 경우 이를 무시하지 마십시오.

러시아 법률의 요구 사항에 따라 러시아 암호화 알고리즘 GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 및 GOST R 34.10-2001에 따라 설정된 TLS 연결의 사용만 인정됩니다. 따라서 GOST 알고리즘에 따른 암호화를 사용하는 사이트를 이용해야 한다면 CryptoPro CSP 프로그램을 설치해야 합니다.

Windows 운영 체제는 전자 서명을 생성하고 인증서로 작업하기 위한 암호화 유틸리티 세트인 CryptoPro CSP 프로그램을 사용합니다.

CryptoPro CSP를 설치하려면 공식 웹사이트의 자료를 사용하십시오.

CryptoPro CSP를 설치한 후 브라우저는 이 프로그램의 존재와 기능을 확인합니다.

GOST TLS 암호화를 요청하는 사이트

사이트에서 GOST TLS 암호화를 요청하면 브라우저는 CryptoPro CSP 프로그램이 설치되어 있는지 확인합니다. 프로그램이 설치되면 제어권이 해당 프로그램으로 이전됩니다.

암호화를 요청하는 사이트의 예: www.gosuslugi.ru, 도메인 .gov.ru, .kamgov.ru, .nalog.ru 사이트.

해당 사이트가 목록에 없으면 추가 확인을 요청합니다. 사이트를 신뢰하고 GOST TLS 암호화를 사용하여 연결해야 하는 경우 계속 버튼을 클릭하세요.

TLS 프로토콜은 모든 유형의 인터넷 트래픽을 암호화하여 온라인 통신 및 판매를 안전하게 만듭니다. 우리는 프로토콜이 어떻게 작동하는지, 그리고 앞으로 무엇이 우리를 기다리고 있는지에 대해 이야기할 것입니다.

이 기사에서 배울 내용은 다음과 같습니다.

SSL이란 무엇입니까?

SSL(Secure Sockets Layer)은 Netscape가 90년대 중반에 개발한 프로토콜의 원래 이름입니다. SSL 1.0은 공개적으로 사용 가능하지 않았으며 버전 2.0에는 심각한 결함이 있었습니다. 1996년에 출시된 SSL 3.0은 완전한 점검을 통해 다음 개발 단계의 분위기를 조성했습니다.

TLS란 무엇입니까?

1999년에 프로토콜의 다음 버전이 출시되었을 때 인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force)는 이를 표준화하고 TLS(Transport Layer Security)라는 새로운 이름을 부여했습니다. TLS 문서에 따르면 "이 프로토콜과 SSL 3.0의 차이점은 중요하지 않습니다." TLS와 SSL은 지속적인 프로토콜 시리즈를 형성하며 종종 SSL/TLS라는 이름으로 결합됩니다.

TLS 프로토콜은 모든 종류의 인터넷 트래픽을 암호화합니다. 가장 일반적인 유형은 웹 트래픽입니다. 브라우저가 언제 TLS 연결을 설정하는지 알 수 있습니다(주소 표시줄의 링크가 "https"로 시작하는 경우).

TLS는 메일 및 원격 회의 시스템과 같은 다른 애플리케이션에서도 사용됩니다.

TLS 작동 방식

온라인에서 안전하게 통신하려면 암호화가 필요합니다. 데이터가 암호화되지 않으면 누구나 데이터를 분석하고 민감한 정보를 읽을 수 있습니다.

가장 안전한 암호화 방법은 비대칭 암호화. 여기에는 공개 키 1개, 개인 키 1개, 총 2개의 키가 필요합니다. 이는 정보가 포함된 파일이며 대개 매우 큰 숫자입니다. 메커니즘은 복잡하지만 간단히 말해서 공개 키를 사용하여 데이터를 암호화할 수 있지만 이를 해독하려면 개인 키가 필요합니다. 두 개의 키는 해킹하기 어려운 복잡한 수학 공식을 사용하여 연결되어 있습니다.

공개키는 구멍이 뚫려 잠긴 편지함의 위치에 대한 정보라고 생각하면 되고, 개인키는 편지함을 여는 열쇠라고 생각하시면 됩니다. 상자가 어디에 있는지 아는 사람은 누구나 거기에 편지를 넣을 수 있습니다. 하지만 그것을 읽으려면 상자를 열려면 열쇠가 필요합니다.

비대칭 암호화는 복잡한 수학적 계산을 사용하기 때문에 많은 컴퓨팅 리소스가 필요합니다. TLS는 세션 시작 시에만 비대칭 암호화를 사용하여 서버와 클라이언트 간의 통신을 암호화함으로써 이 문제를 해결합니다. 서버와 클라이언트는 데이터 패킷을 암호화하는 데 사용할 단일 세션 키에 동의해야 합니다.

클라이언트와 서버가 세션 키에 동의하는 프로세스를 호출합니다. 악수. 통신 중인 두 컴퓨터가 서로 자신을 소개하는 순간입니다.

TLS 핸드셰이크 프로세스

TLS 핸드셰이크 프로세스는 매우 복잡합니다. 아래 단계에서는 일반적인 프로세스를 간략하게 설명하므로 일반적인 작동 방식을 이해할 수 있습니다.

클라이언트는 서버에 접속하여 보안 연결을 요청합니다. 서버는 사용 방법을 알고 있는 암호화된 연결을 생성하기 위한 알고리즘 세트인 암호 목록으로 응답합니다. 클라이언트는 목록을 지원되는 암호 목록과 비교하여 적절한 암호를 선택하고 두 암호 중 어느 암호를 사용할지 서버에 알립니다.
서버는 디지털 인증서(서버의 신뢰성을 확인하는 제3자가 서명한 전자 문서)를 제공합니다. 인증서에서 가장 중요한 정보는 암호에 대한 공개 키입니다. 클라이언트는 인증서의 진위를 확인합니다.
서버의 공개 키를 사용하여 클라이언트와 서버는 통신을 암호화하기 위해 세션 전체에서 사용할 세션 키를 설정합니다. 이에 대한 몇 가지 방법이 있습니다. 클라이언트는 공개 키를 사용하여 임의의 숫자를 암호화한 다음 해독을 위해 서버로 전송하고, 양 당사자는 해당 숫자를 사용하여 세션 키를 설정할 수 있습니다.

세션 키는 하나의 연속 세션에만 유효합니다. 어떤 이유로 클라이언트와 서버 간의 통신이 중단되면 새 세션 키를 설정하기 위해 새 핸드셰이크가 필요합니다.

TLS 1.2 및 TLS 1.2 프로토콜의 취약점

TLS 1.2는 가장 일반적인 프로토콜 버전입니다. 이 버전은 세션 암호화 옵션의 원래 플랫폼을 설치했습니다. 그러나 일부 이전 버전의 프로토콜과 마찬가지로 이 프로토콜에서는 이전 암호화 기술을 사용하여 이전 컴퓨터를 지원할 수 있었습니다. 불행하게도 이전 암호화 메커니즘이 더욱 취약해지면서 버전 1.2에서 취약점이 발생했습니다.

예를 들어, TLS 1.2는 공격자가 세션 중간에 데이터 패킷을 가로채서 읽거나 수정한 후 전송하는 변조 공격에 특히 취약해졌습니다. 이러한 문제 중 다수는 지난 2년 동안 표면화되었으므로 업데이트된 프로토콜 버전을 만드는 것이 시급합니다.

TLS 1.3

곧 완성될 TLS 프로토콜 버전 1.3은 레거시 암호화 시스템에 대한 지원을 포기함으로써 취약점과 관련된 많은 문제를 해결합니다.
새 버전은 이전 버전과 호환됩니다. 예를 들어 당사자 중 하나가 버전 1.3의 허용된 프로토콜 알고리즘 목록에서 최신 암호화 시스템을 사용할 수 없는 경우 연결은 TLS 1.2로 대체됩니다. 그러나 연결 변조 공격의 경우 해커가 세션 도중에 강제로 프로토콜 버전을 1.2로 다운그레이드하려고 시도하면 이 동작이 감지되고 연결이 종료됩니다.

Google Chrome 및 Firefox 브라우저에서 TLS 1.3 지원을 활성화하는 방법

Firefox 및 Chrome은 TLS 1.3을 지원하지만 이 버전은 기본적으로 활성화되어 있지 않습니다. 그 이유는 현재 초안 형태로만 존재하기 때문입니다.

모질라 파이어 폭스

브라우저의 주소 표시줄에 about:config를 입력하세요. 위험을 이해하고 있는지 확인하세요.

Firefox 설정 편집기가 열립니다.
검색에 security.tls.version.max를 입력하세요.
현재 값을 두 번 클릭하여 값을 4로 변경합니다.

구글 크롬

실험 패널을 열려면 브라우저의 주소 표시줄에 chrome://flags/를 입력하세요.
옵션 #tls13-variant 찾기
메뉴를 클릭하고 활성화(초안)로 설정합니다.
브라우저를 다시 시작하세요.

브라우저가 버전 1.2를 사용하고 있는지 확인하는 방법

버전 1.3은 아직 공개적으로 사용되지 않음을 알려드립니다. 네가 원하지 않는다면
초안을 사용하면 버전 1.2를 유지할 수 있습니다.

브라우저가 버전 1.2를 사용하고 있는지 확인하려면 위 지침과 동일한 단계를 수행하고 다음을 확인하세요.

Firefox의 경우 security.tls.version.max 값은 3입니다. 더 낮은 경우 현재 값을 두 번 클릭하여 3으로 변경합니다.
Google Chrome의 경우: 브라우저 메뉴를 클릭하고 선택하세요. 설정- 선택하다 고급 설정 표시- 해당 섹션으로 이동 체계그리고를 클릭하세요 프록시 설정 열기…:

열리는 창에서 보안 탭을 클릭하고 TLS 1.2 사용 필드가 선택되어 있는지 확인하십시오. 그렇지 않은 경우 확인하고 확인을 클릭하십시오.

컴퓨터를 다시 시작하면 변경 사항이 적용됩니다.

브라우저의 SSL/TLS 프로토콜 버전을 확인하는 빠른 도구

SSL Labs 온라인 프로토콜 버전 검사 도구로 이동합니다. 이 페이지에는 사용된 프로토콜 버전과 브라우저가 취약점에 취약한지 여부가 실시간으로 표시됩니다.

출처: 번역

TLS 핸드셰이크란 무엇이며 어떻게 작동하나요?

TLS는 인터넷에서 사용되는 가장 일반적인 보안 도구 중 하나입니다. 이 프로토콜은 파일 전송, VPN 연결(일부 키 교환 구현의 경우), 인스턴트 메시징 서비스 또는 IP 전화 통신 등 다양한 네트워크 통신 프로세스에서 적극적으로 작동합니다.

프로토콜의 주요 측면 중 하나는 핸드셰이크입니다. 이것이 이 글에서 우리가 이야기할 내용입니다.

"SSL/TLS 핸드셰이크"는 HTTPS 연결을 설정하는 단계의 이름입니다. SSL/TLS 프로토콜과 관련된 대부분의 작업은 이 단계에서 수행됩니다. 작년에 IETF는 TLS 1.3을 완성하여 핸드셰이크 프로세스를 완전히 개편했습니다.
이 기사에서는 TLS 1.2 및 TLS 1.3 프로토콜에 대한 두 가지 유형의 핸드셰이크를 다룰 것입니다. 이 프로토콜은 추상적 수준에서 시작하여 점차적으로 세부 사항을 탐구합니다.

암호화 프로토콜 조정;
SSL 인증서를 사용한 인증;
세션 키 생성.

TLS 핸드셰이크는 어떻게 작동하나요?

HTTPS 연결에는 클라이언트(연결 개시자, 일반적으로 웹 브라우저)와 서버라는 두 당사자가 관련됩니다. SSL/TLS 핸드셰이크의 목적은 사용 중인 SSL 인증서의 신뢰성을 확인하고 암호화 키를 생성하는 것을 포함하여 보안 연결을 설정하기 위한 모든 암호화 작업을 수행하는 것입니다.

다이얼 협상

모든 소프트웨어는 고유합니다. 따라서 가장 널리 사용되는 웹 브라우저라도 기능이 다릅니다. 서버 측에서도 마찬가지입니다. Windows Server, Apache 및 NGINX도 서로 다릅니다. 사용자 정의 구성을 추가하면 상황이 더욱 복잡해집니다.

그렇기 때문에 TLS 핸드셰이크의 첫 번째 단계는 클라이언트와 서버가 지원되는 암호화 기능을 추가로 선택하기 위해 해당 기능에 대한 정보를 교환하는 것입니다.

클라이언트와 서버가 사용할 암호화 제품군에 동의하면 서버는 SSL 인증서를 클라이언트에 보냅니다.

입증

인증서를 받은 클라이언트는 인증서의 진위 여부를 확인합니다. 이것은 매우 중요한 단계입니다. 보안 연결을 보장하려면 데이터를 암호화해야 할 뿐만 아니라 해당 데이터가 올바른 웹사이트로 전송되는지 확인해야 합니다. SSL/TLS 인증서는 이 인증을 제공하며 이를 수행하는 방법은 사용되는 암호화 제품군에 따라 다릅니다.

신뢰할 수 있는 모든 SSL 인증서는 인증 기관(CA)에서 발급됩니다. CA는 신뢰할 수 있는 인증서를 발급하고 검증하기 위한 엄격한 규칙을 따라야 합니다. CA를 공증인과 비슷하게 생각할 수 있습니다. CA의 서명은 인증서의 데이터가 실제라는 것을 의미합니다.

TLS 핸드셰이크의 인증 부분 동안 클라이언트는 서버에서 발급한 인증서가 유효한지 확인하기 위해 여러 암호화 보안 검사를 수행합니다. 이 프로세스에는 디지털 서명을 확인하고 인증서가 신뢰할 수 있는 CA에서 발급되었는지 여부가 포함됩니다.

이 시점에서 클라이언트는 서버가 인증서와 연결된 개인 키를 소유하고 있는지 간접적으로 확인합니다.

가장 널리 사용되는 공개 키 암호화 시스템인 RSA에서 클라이언트는 공개 키를 사용하여 세션 키를 생성하는 데 사용될 임의 데이터를 암호화합니다. 서버는 당사자의 신뢰성을 보장하는 개인 키가 있는 경우에만 이 데이터를 해독하고 사용할 수 있습니다.

다른 암호화 시스템을 사용하는 경우 알고리즘은 변경될 수 있지만 상대방의 진위 여부는 계속 확인됩니다.

키 교환

TLS 핸드셰이크의 마지막 부분에는 실제로 보안 통신에 사용될 "세션 키"를 생성하는 작업이 포함됩니다.

세션 키는 "대칭"입니다. 즉, 암호화 및 암호 해독에 동일한 키가 사용됩니다.

대칭 암호화는 비대칭 암호화보다 빠르므로 HTTPS 연결을 통해 데이터를 전송하는 데 더 적합합니다. 키 생성의 정확한 방법은 선택한 암호 제품군에 따라 달라지며, 가장 일반적인 두 가지는 RSA와 Diffie-Hellman입니다.

핸드셰이크를 완료하기 위해 각 당사자는 필요한 모든 작업을 완료했음을 상대방에게 알리고 체크섬을 확인하여 핸드셰이크가 간섭이나 손상 없이 발생했는지 확인합니다.

전체 SSL 핸드셰이크는 수백 밀리초 내에 발생합니다. 이는 웹페이지가 로드되기 전이라도 HTTPS 연결에서 가장 먼저 발생하는 일입니다. SSL 핸드셰이크 후에는 암호화되고 인증된 HTTPS 연결이 시작되고 클라이언트와 서버가 주고받는 모든 데이터가 보호됩니다.

TLS 1.3까지는 사이트를 방문할 때마다 핸드셰이크가 다시 발생했습니다. TLS 1.3 핸드셰이크는 0-RTT, 즉 왕복 재개 시간을 지원하지 않으므로 재방문자의 속도가 크게 향상됩니다.

TLS 1.2의 단계별 핸드셰이크 프로세스

RSA를 사용한 TLS 핸드셰이크를 자세히 살펴보겠습니다. Diffie-Hellman 알고리즘의 사용에 대해서는 아래에서 설명합니다.

첫 번째 메시지는 "Client Hello"입니다. 이 메시지에는 서버가 통신에 사용할 암호 제품군을 선택할 수 있도록 클라이언트의 기능이 나열되어 있습니다. 메시지에는 "클라이언트 난수"라고 하는 무작위로 선택된 큰 소수도 포함되어 있습니다.
서버는 “Server Hello” 메시지로 정중하게 응답합니다. 여기서 클라이언트에게 어떤 연결 매개변수가 선택되었는지 알려주고 "서버 난수"라고 하는 무작위로 선택된 소수를 반환합니다. 클라이언트와 서버가 동일한 암호화 제품군을 공유하지 않으면 연결이 실패합니다.
인증서 메시지에서 서버는 리프 및 중간 인증서를 포함하여 SSL 인증서 체인을 클라이언트에 보냅니다. 클라이언트가 인증서를 받으면 인증서를 확인하기 위해 여러 가지 검사를 수행합니다. 클라이언트는 또한 키 교환/생성 프로세스 중에 발생하는 인증서의 개인 키가 서버에 있는지 확인해야 합니다.
이는 서버의 추가 데이터가 필요한 특정 키 교환 방법(예: Diffie-Hellman)에만 필요한 선택적 메시지입니다.
"Server Hello Done" 메시지는 서버가 데이터 전송을 완료했음을 클라이언트에게 알립니다.
그런 다음 클라이언트는 세션 키 생성에 참여합니다. 이 단계의 세부 사항은 원본 Hello 메시지에서 선택한 키 교환 방법에 따라 다릅니다. RSA에 대해 이야기하고 있으므로 클라이언트는 사전 마스터 비밀이라는 임의의 바이트 문자열을 생성하고 이를 서버의 공개 키로 암호화한 후 다시 전달합니다.
"Change Cipher Spec" 메시지는 상대방에게 세션 키가 생성되었음을 알려 암호화된 연결로 전환할 수 있도록 해줍니다.
그런 다음 "Finished" 메시지가 전송되어 클라이언트 측에서 핸드셰이크가 완료되었음을 나타냅니다. 이 순간부터 연결은 세션 키로 보호됩니다. 메시지에는 핸드셰이크가 변조되지 않았는지 확인하는 데 사용할 수 있는 데이터(MAC)가 포함되어 있습니다.
이제 서버는 사전 마스터 비밀을 해독하고 세션 키를 계산합니다. 그런 다음 "Change Cipher Spec" 메시지를 보내 암호화된 연결로 전환 중임을 알립니다.
또한 서버는 새로 생성된 대칭 세션 키를 사용하여 "Finished" 메시지를 보내고 체크섬을 확인하여 전체 핸드셰이크의 무결성을 확인합니다.

이 단계를 마치면 SSL 핸드셰이크가 완료됩니다. 이제 두 당사자 모두 세션 키를 갖고 있으며 암호화되고 인증된 연결을 통해 통신할 수 있습니다.

이 시점에서 웹 애플리케이션의 첫 번째 바이트(실제 서비스와 관련된 데이터 - HTML, Javascript 등)를 보낼 수 있습니다.

TLS 1.3의 단계별 핸드셰이크 프로세스

TLS 1.3 핸드셰이크는 이전 버전보다 훨씬 짧습니다.

TLS 1.2와 마찬가지로 "Client Hello" 메시지는 핸드셰이크를 시작하지만 이번에는 훨씬 더 많은 정보를 포함합니다. TLS 1.3은 지원되는 암호 수를 37개에서 5개로 줄였습니다. 이는 클라이언트가 어떤 키 계약이나 교환 프로토콜이 사용될지 추측할 수 있음을 의미하므로 메시지 외에도 추측된 프로토콜에서 공개 키의 일부를 보냅니다.
서버는 "Server Hello" 메시지로 응답합니다. 1.2 핸드셰이크와 마찬가지로 이 단계에서는 인증서가 전송됩니다. 클라이언트가 첨부된 데이터를 사용하여 암호화 프로토콜을 올바르게 추측하고 서버가 이에 동의한 경우 서버는 공개 키의 일부를 보내고 세션 키를 계산한 후 "Server Finished" 메시지와 함께 전송을 완료합니다.
이제 클라이언트는 필요한 모든 정보를 얻었으므로 SSL 인증서를 확인하고 두 개의 공개 키를 사용하여 세션 키 복사본을 계산합니다. 이 작업이 완료되면 "클라이언트 완료" 메시지가 전송됩니다.

TLS 핸드셰이크의 오버헤드

역사적으로 SSL/TLS에 대한 불만 중 하나는 추가 오버헤드로 인해 서버에 과부하가 걸린다는 것이었습니다. 이는 HTTPS가 HTTP보다 느리다는 현재는 존재하지 않는 개념에 영향을 미쳤습니다.

TLS 1.2 이전의 핸드셰이크에는 많은 리소스가 필요했으며 대규모로 실행하면 서버에 심각한 로드가 발생할 수 있었습니다. TLS 1.2 핸드셰이크도 동시에 발생하는 경우 속도가 느려질 수 있습니다. 인증, 암호화 및 암호 해독은 비용이 많이 드는 프로세스입니다.

소규모 웹사이트에서는 이로 인해 눈에 띄는 속도 저하가 발생하지 않을 수 있지만 매일 수십만 명의 방문자를 받는 기업 시스템에서는 큰 문제가 될 수 있습니다. 각 새 버전의 핸드셰이크는 프로세스를 크게 단순화합니다. TLS 1.2는 두 단계를 수행하는 반면, TLS 1.3은 단 하나의 단계에 적합하며 0-RTT를 지원합니다.

TLS 1.2에 비해 TLS 1.3 핸드셰이크 개선

위의 설명에서 악수는 10단계로 구분됩니다. 실제로 이러한 일 중 많은 일이 동시에 발생하기 때문에 종종 함께 그룹화되어 단계라고 부릅니다.

TLS 1.2 핸드셰이크에는 두 단계가 있습니다. 때로는 추가가 필요할 수도 있지만 수량에 있어서는 기본값이 최적의 시나리오입니다.

1.2와 달리 TLS 1.3 핸드셰이크는 한 단계에 적합하지만 1.5단계라고 말하는 것이 더 정확하지만 여전히 TLS 1.2보다 훨씬 빠릅니다.

암호 제품군 감소

데이터를 암호화하기 위해 37개 제품군을 사용하려는 사람은 아무도 없었으며, 이것이 프로토콜이 발전한 방식입니다. 새로운 알고리즘이 추가될 때마다 새로운 조합이 추가되었고 곧 IANA는 37개의 서로 다른 암호화 제품군을 관리했습니다.

이는 두 가지 이유로 좋지 않습니다.

이러한 가변성으로 인해 잘못된 구성이 발생하여 인터넷 사용자가 알려진 악용에 취약해집니다.
이로 인해 SSL 설정이 더욱 혼란스러워졌습니다.

IETF는 TLS 1.3에서 가장 안전한 알고리즘을 제외한 모든 알고리즘에 대한 지원을 제거하여 선택을 제한함으로써 혼란을 제거했습니다. 특히, 키 교환 방법 선택이 제거되었습니다. 일시적인 Diffie-Hellman 체계는 클라이언트가 핸드셰이크의 첫 번째 부분에서 "클라이언트 안녕하세요"와 함께 주요 정보를 보내는 유일한 방법이 되었습니다. RSA 암호화는 다른 모든 정적 키 교환 체계와 함께 완전히 제거되었습니다.

즉, TLS 1.3에는 잠재적인 아킬레스건이 하나 있습니다.

제로 왕복 재개 시간 - 0-RTT

0-RTT는 전체 기술 세계가 갈망해 왔던 것이며 이제 TLS 1.3이 출시되었습니다. 앞서 언급했듯이 TLS 핸드셰이크는 역사적으로 느렸기 때문에 속도를 높이는 것이 중요했습니다. 0-RTT는 다음 연결에 사용할 수 있도록 클라이언트에 대한 일부 비밀 정보(일반적으로 세션 ID 또는 세션 티켓)를 저장하여 이를 수행합니다.

0-RTT의 모든 이점에도 불구하고 몇 가지 잠재적인 함정이 있습니다. 이 모드를 사용하면 클라이언트가 재생 공격에 취약해집니다. 암호화된 세션에 어떻게든 액세스할 수 있는 공격자가 클라이언트의 첫 번째 요청을 포함하여 0-RTT 데이터를 획득하여 서버로 다시 보낼 수 있습니다.

그러나 익스플로잇은 사용하기 쉽지 않습니다. 이러한 위험은 아마도 매우 유용한 기능에 대해 지불하는 작은 가격일 것입니다.

안전

처음부터 핸드셰이크 중에 일반 텍스트로 전송되는 정보의 양에 대한 우려가 있었습니다. 분명히 이것은 안전하지 않으므로 암호화된 핸드셰이크 단계가 많을수록 좋습니다.

TLS 1.2 핸드셰이크에서는 협상 단계가 보호되지 않고 대신 간단한 MAC 기능을 사용하여 누구도 전송을 방해하지 않도록 했습니다. 협상 단계에는 "클라이언트 Hello" 및 "서버 Hello" 메시지가 포함됩니다.

MAC 기능은 표시기 역할을 하지만 보안을 보장하지는 않습니다. 당사자들이 덜 안전한 프로토콜과 기능을 사용하도록 강요하는 공격(다운그레이드 공격)에 대해 들어보셨을 것입니다. 서버와 클라이언트가 모두 오래된 암호 제품군을 지원하는 경우(연결을 도청하여 이에 대한 정보를 쉽게 얻을 수 있음) 공격자는 서버에서 선택한 암호화를 더 약한 암호화로 변경할 수 있습니다. 이러한 공격은 그 자체로는 위험하지 않지만 원래 암호 제품군으로 변경된 다른 알려진 암호 제품군을 사용할 수 있는 가능성을 열어줍니다.

TLS 1.3 핸드셰이크는 연결 초기에 디지털 서명을 사용하여 보안을 강화하고 암호 해독 공격으로부터 보호합니다. 또한 서명을 사용하면 서버를 더 빠르고 효율적으로 인증할 수 있습니다.

이제 TLS 1.3 핸드셰이크에 대한 이러한 업데이트가 SSL/TLS 핸드셰이크 자체의 세 가지 주요 기능 모두에서 어떻게 구현되는지 살펴보겠습니다.

TLS 핸드셰이크 암호화 제품군

암호 제품군은 보안 연결의 매개변수를 결정하는 알고리즘 세트입니다.

연결이 시작될 때 첫 번째 상호 작용인 "클라이언트 안녕하세요"는 지원되는 암호화 제품군 목록입니다. 서버는 자신이 지원하고 요구 사항을 충족하는 가장 안전하고 안전한 옵션을 선택합니다. 암호 모음을 보고 모든 핸드셰이크 및 연결 매개변수를 파악할 수 있습니다.

TLS 1.2 암호화 제품군

TLS는 프로토콜입니다.
ECDHE는 키 교환 알고리즘입니다.
ECDSA는 인증 알고리즘입니다.
AES 128 GCM은 대칭 암호화 알고리즘입니다.
SHA256은 해싱 알고리즘입니다.

위의 예에서는 키 교환을 위해 임시 Elliptic Curve Diffie-Hellman(DH) 시스템을 사용하고 인증을 위해 Elliptic Curve 디지털 서명 알고리즘을 사용합니다. DH는 RSA(디지털 서명 알고리즘으로 작동)와 결합하여 인증을 수행할 수도 있습니다.

다음은 가장 널리 지원되는 TLS 1.2 암호화 제품군 목록입니다.

TLS 1.3 암호화 제품군

TLS는 프로토콜입니다.
AES 256 GCM은 데이터가 첨부된 인증된 암호화 알고리즘(AEAD)입니다.
SHA384는 HKFD(해시 키 생성 함수 알고리즘)입니다.

우리는 Diffie-Hellman 임시 키 교환의 일부 버전을 사용할 것이라는 것을 이미 알고 있지만 매개변수를 모르기 때문에 TLS 1.2 암호화 제품군의 처음 두 알고리즘은 더 이상 필요하지 않습니다. 이러한 기능은 여전히 작동하며 더 이상 핸드셰이크 중에 협상할 필요가 없습니다.

위의 예를 보면 대용량 데이터를 암호화하는데 AES(Advanced Encryption Standard)가 사용되는 것을 알 수 있다. 256비트 키를 사용하여 Galois 카운터 모드에서 작동합니다.

TLS 1.3에서 지원되는 5가지 암호화 제품군은 다음과 같습니다.

TLS_AES_256_GCM_SHA384;
TLS_CHACHA20_POLY1305_SHA256;
TLS_AES_128_GCM_SHA256;
TLS_AES_128_CCM_8_SHA256;
TLS_AES_128_CCM_SHA256.

TLS 1.2와 비교하여 TLS 1.3에서는 무엇이 변경되었나요?

버전 1.3은 보안 및 성능 향상을 염두에 두고 설계되었다는 점을 기억하는 것이 중요합니다. 이를 달성하기 위해 TLS 1.3에서는 키 생성 알고리즘이 재설계되었고 알려진 취약점이 수정되었습니다.

TLS 1.3 핸드셰이크는 메시지 인증 및 디지털 서명과 같은 일부 프로세스도 개선합니다.

마지막으로, TLS 1.3은 이전 키 생성 또는 교환 알고리즘을 단계적으로 폐지하는 것 외에도 이전 대칭 암호를 제거합니다. TLS 1.3은 블록 암호를 완전히 제거했습니다. TLS 1.3에서 허용되는 유일한 대칭 암호 유형은 AEAD(추가 데이터를 사용한 인증된 암호화)입니다. 암호화와 메시지 인증(MAC)을 하나의 기능으로 결합합니다.

TLS 핸드셰이크의 인증

역사적으로 두 가지 주요 키 교환 옵션은 RSA와 Diffie-Hellman(DH)입니다. 요즘 DH는 종종 ECDH(타원 곡선 키 교환)와 연결됩니다. 몇 가지 기본적인 유사점에도 불구하고 키 교환에 대한 이 두 가지 접근 방식에는 근본적인 차이점이 있습니다.

즉, RSA TLS 핸드셰이크는 ECDH TLS 핸드셰이크와 다릅니다.

RSA는 소인수분해와 모듈러 산술을 사용합니다. 큰 소수는 계산하는 데 많은 CPU 성능이 필요하며 찾기도 어렵습니다.

Diffie-Hellman은 지수화(모듈식 산술 외에도)를 나타내는 지수 키 교환이라고도 하지만 DH 자체는 실제로 어떤 것도 암호화하거나 해독하지 않습니다. 따라서 "수학적 추론" 대신 "암호화 방법"이라고 부르는 것은 약간 오해의 소지가 있을 수 있습니다.

역사에 대한 짧은 여행을 통해 이 점을 명확히 할 수 있습니다.

1976년에 Whitfield Diffie와 Martin Hellman은 Ralph Merkle의 작업을 기반으로 키 교환 프로토콜을 만들었습니다. 두 사람 모두에 따르면 그의 이름은 프로토콜 이름에도 나타나야 합니다.

그들은 공격자가 듣고 있더라도 안전하지 않은 채널을 통해 안전하게 키를 교환하는 문제를 해결하려고 노력했습니다. 성공했지만 한 가지 큰 결함이 있었습니다. DH 키 교환에는 인증이 포함되지 않았기 때문에 연결 반대편에서 당사자를 확인할 방법이 없었습니다.

이것이 공개키 암호학과 PKI의 탄생이라고 할 수 있습니다. Diffie와 Hellman이 키 교환 프로토콜을 도입한 직후 RSA 암호화 시스템의 초기 버전이 완성되었습니다. Diffie와 Hellman은 공개 키 암호화 개념을 창안했지만 아직 단방향 암호화 기능 자체를 생각해 내지 못했습니다.

결국 RSA 암호화 시스템이 된 개념을 창안한 사람은 Ron Rivest(RSA의 R)였습니다.

여러 면에서 RSA는 DH의 정신적 계승자입니다. 다음을 수행합니다.

키 생성;
키 교환;
암호화;
해독.

따라서 RSA는 키 교환과 디지털 서명, 즉 보안 키 교환 외에 인증을 모두 처리할 수 있는 보다 유능한 알고리즘입니다. 따라서 RSA에는 더 큰 키가 있습니다. 즉, 디지털 서명에 충분한 보안이 제공되어야 합니다.

RSA는 인증과 키 교환을 처리하지만 Diffie-Hellman은 키 교환만 용이하게 합니다. DH 제품군에는 네 가지 일반적인 변형이 있습니다.

디피-헬만(DH);
임시(단기) Diffie-Hellman(DHE);
타원 곡선 Diffie-Hellman(ECDH);
타원 곡선 임시 Diffie-Hellman(ECDHE).

다시 말하지만 Diffie-Hellman 자체는 아무것도 인증하지 않습니다. 디지털 서명 알고리즘과 함께 사용해야 합니다. 예를 들어 ECDH 또는 ECDHE를 사용한 경우 대부분의 암호화 제품군은 ECDSA(Elliptic Curve Digital Signature Algorithm) 또는 RSA와 쌍을 이룹니다.

TLS 1.2 핸드셰이크의 인증

방금 언급한 것처럼 디지털 서명을 사용한 인증을 위한 RSA의 추가 기능에는 무차별 대입 공격에 저항하는 대규모 키가 필요합니다. 이러한 키의 크기는 핸드셰이크 중에 키를 계산하고 암호화하고 해독하는 비용을 크게 증가시킵니다.

반면에 Diffie-Hellman이 인증을 수행하지 않으면 어떻게 됩니까? 위에서 언급했듯이 DH는 인증 및 키 교환을 제공하기 위해 타원 곡선 암호화와 함께 사용되는 경우가 많습니다.

ECC(타원 암호화)는 기반이 되는 타원 곡선에 맞는 키 크기가 훨씬 작습니다. 이 맥락에 적합한 다섯 가지 곡선이 있습니다.

192비트;
224비트;
256비트;
384비트;
521비트.

그러나 이것이 ECC 공개/개인 키와 RSA 키의 유일한 차이점은 아닙니다. TLS 핸드셰이크 중에 완전히 다른 두 가지 목적으로 사용됩니다.

RSA에서는 공개/개인 키 쌍이 서버 인증과 대칭 세션 키 교환에 모두 사용됩니다. 실제로 서버를 인증하는 것은 사전 마스터 비밀을 성공적으로 사용하는 것입니다.

Diffie-Hellman을 사용하면 공개/개인 키 쌍이 대칭 세션 키를 교환하는 데 사용되지 않습니다. Diffie-Hellman이 관련되면 개인 키는 실제로 함께 제공되는 서명 알고리즘(ECDSA 또는 RSA)과 연결됩니다.

RSA 인증

RSA 인증 프로세스는 키 교환 프로세스와 관련되어 있습니다. 보다 정확하게는 키 교환이 인증 프로세스의 일부입니다.

클라이언트에 서버의 SSL 인증서가 제공되면 클라이언트는 다음과 같은 여러 지표를 확인합니다.

공개 키를 사용한 디지털 서명;
인증서가 신뢰 저장소의 루트 인증서 중 하나에서 나오는지 확인하는 인증서 체인
만료되지 않았는지 확인하는 만료일
인증서 폐기 상태.

이러한 모든 검사가 통과되면 마지막 테스트가 수행됩니다. 클라이언트는 서버의 공개 키를 사용하여 사전 마스터 비밀을 암호화하여 보냅니다. 모든 서버는 SSL/TLS 인증서를 자체 인증서로 전달하려고 시도할 수 있습니다. 결국 이것은 공개 인증서입니다. 따라서 클라이언트는 "작동 중인" 개인 키를 확인하여 서버를 인증할 수 있습니다.

따라서 서버가 사전 마스터 비밀을 해독하고 이를 사용하여 세션 키를 계산할 수 있으면 액세스 권한을 얻습니다. 이는 서버가 사용 중인 공개/개인 키 쌍의 소유자인지 확인합니다.

DH 인증

Diffie-Hellman과 ECDSA/RSA를 사용하면 인증과 키 교환이 동시에 작동합니다. 그리고 이는 키와 그 용도로 다시 돌아갑니다. RSA 공개/개인 키는 키 교환과 인증에 모두 사용됩니다. DH+ECDSA/RSA에서 비대칭 키 쌍은 디지털 서명 또는 인증 단계에만 사용됩니다.

클라이언트가 인증서를 수신하면 여전히 표준 확인을 수행합니다.

인증서의 서명을 확인하고,
인증서 체인,
타당성,
상태를 검토합니다.

그러나 개인 키의 소유권은 다르게 확인됩니다. TLS 핸드셰이크 키 교환(4단계) 중에 서버는 개인 키를 사용하여 클라이언트 및 서버 난수와 DH 매개변수를 암호화합니다. 이는 서버의 디지털 서명 역할을 하며 클라이언트는 연결된 공개 키를 사용하여 서버가 키 쌍의 정당한 소유자인지 확인할 수 있습니다.

TLS 1.3 핸드셰이크의 인증

TLS 1.3에서는 인증과 디지털 서명이 여전히 중요한 역할을 하지만 협상을 단순화하기 위해 암호화 제품군에서 제거되었습니다. 이는 서버 측에서 구현되며 보안 및 편재성으로 인해 서버에서 지원하는 여러 알고리즘을 사용합니다. TLS 1.3에서는 세 가지 주요 서명 알고리즘을 허용합니다.

RSA(서명만),
타원 곡선 디지털 서명 알고리즘(ECDSA),
Edwards 디지털 서명 알고리즘(EdDSA).

TLS 1.2 핸드셰이크와 달리 TLS 1.3 핸드셰이크의 인증 부분은 키 교환 자체와 연결되지 않습니다. 오히려 키 교환 및 메시지 인증과 병행하여 처리됩니다.

핸드셰이크의 무결성을 확인하기 위해 대칭 MAC 회로를 실행하는 대신 서버는 공유 키의 일부와 함께 "Server Hello"를 반환할 때 전체 암호 해독 해시에 서명합니다.

클라이언트는 "Server Hello"에서 전달된 모든 정보를 수신하고 일련의 표준 SSL/TLS 인증서 인증 확인을 수행합니다. 여기에는 인증서의 서명을 확인한 다음 암호 해독 해시에 추가된 서명을 확인하는 작업이 포함됩니다.

일치하면 서버가 비밀 키를 소유하고 있음이 확인됩니다.

TLS 핸드셰이크의 키 교환

이 섹션의 주요 아이디어를 강조하면 다음과 같이 들릴 것입니다.

RSA는 클라이언트가 공유 비밀을 암호화하고 이를 서버로 보내 해당 세션 키를 계산하는 데 사용되도록 함으로써 키 교환을 용이하게 합니다. DH 키 교환에는 실제로 공개 키 교환이 전혀 필요하지 않으며 오히려 양 당사자가 함께 키를 생성합니다.

지금 이 내용이 다소 추상적으로 들리더라도 이 섹션이 끝날 때쯤이면 모든 것이 더 명확해질 것입니다.

RSA 키 교환

RSA 키 교환이라고 부르는 것은 사실 잘못된 명칭입니다. 이것은 실제로 RSA 암호화입니다. RSA는 비대칭 암호화를 사용하여 세션 키를 생성합니다. DH와 달리 공개/개인 키 쌍이 큰 역할을 합니다.

발생 방법은 다음과 같습니다.

엑스그리고 와이
클라이언트가 생성 사전 마스터 비밀(a) 그런 다음 서버의 공개 키를 사용하여 암호화하여 서버로 보냅니다.
서버 암호 해독 사전 마스터 비밀해당 개인 키를 사용합니다. 이제 양쪽에는 세 가지 입력 변수가 모두 있고 이를 의사 난수 함수(PRF)와 혼합하여 마스터 키를 만듭니다.
양 당사자는 마스터 키를 더 많은 PRF와 혼합하고 일치하는 세션 키를 얻습니다.

DH 키 교환

ECDH의 작동 방식은 다음과 같습니다.

클라이언트와 서버는 두 개의 소수( 엑스그리고 와이)를 난수라고 합니다.
한 당사자는 다음과 같은 비밀 번호를 선택합니다. 사전 마스터 비밀(a) 다음을 계산합니다. x 모드 y. 그런 다음 결과(A)를 다른 참가자에게 보냅니다.
상대방도 똑같이 선택하여 자신의 것을 선택합니다. 사전 마스터 비밀(b) 그리고 계산한다 xb 모드 y, 그 값(B)을 다시 보냅니다.
양측은 주어진 값을 받아들이고 작업을 반복함으로써 이 부분을 완성합니다. 하나는 계산 b 모드 y, 다른 하나는 계산 a b 모드 y.

양쪽이 연결 중에 대칭 암호화에 사용되는 키가 되는 동일한 값을 받게 된다는 모듈로 속성이 있습니다.

DH용 TLS 1.2 핸드셰이크

이제 DH가 RSA와 어떻게 다른지 알았으므로 DH 기반 TLS 1.2 핸드셰이크가 어떻게 생겼는지 살펴보겠습니다.

다시 말하지만, 두 접근 방식 사이에는 많은 유사점이 있습니다. 키 교환에는 ECDHE를 사용하고 인증에는 ECDSA를 사용합니다.

RSA와 마찬가지로 클라이언트는 암호 제품군 목록과 클라이언트의 난수를 포함하는 "Client Hello" 메시지로 시작합니다.
서버는 선택한 암호 제품군과 서버의 난수를 포함하는 "Server Hello" 메시지로 응답합니다.
서버가 SSL 인증서를 보냅니다. RSA TLS 핸드셰이크와 마찬가지로 클라이언트는 인증서의 신뢰성에 대해 일련의 검사를 수행하지만 DH 자체가 서버를 인증할 수 없으므로 추가 메커니즘이 필요합니다.
인증을 수행하기 위해 서버는 클라이언트 및 서버의 난수는 물론 세션 키를 계산하는 데 사용되는 DH 매개변수를 가져와 개인 키로 암호화합니다. 결과는 디지털 서명 역할을 합니다. 클라이언트는 공개 키를 사용하여 서명을 확인하고 서버가 키 쌍의 정당한 소유자인지 확인하고 자체 DH 매개변수로 응답합니다.
서버는 "Server Hello Done" 메시지로 이 단계를 종료합니다.
RSA와 달리 클라이언트는 비대칭 암호화를 사용하여 서버에 사전 마스터 암호를 보낼 필요가 없습니다. 대신 클라이언트와 서버는 사전 마스터 암호를 얻기 위해 이전에 교환한 DH 매개 변수를 사용합니다. 그런 다음 모든 사람은 방금 계산한 사전 마스터 비밀을 사용하여 동일한 세션 키를 얻습니다.
클라이언트는 암호화로 전환 중임을 상대방에게 알리기 위해 "Change Cipher Spec" 메시지를 보냅니다.
클라이언트는 핸드셰이크의 해당 부분이 완료되었음을 나타내기 위해 최종 "완료" 메시지를 보냅니다.
마찬가지로 서버는 “Change Cipher Spec” 메시지를 보냅니다.
핸드셰이크는 서버의 "Finished" 메시지로 끝납니다.

RSA에 비해 DHE의 장점

암호 작성자 커뮤니티가 RSA보다 DHE를 선호하는 두 가지 주요 이유는 완벽한 순방향 비밀성과 알려진 취약점입니다.

완벽한 순방향 비밀성

이전에는 DHE 및 ECDHE 끝에 있는 "임시"라는 단어가 무엇을 의미하는지 궁금했을 것입니다. 임시(Ephemeral)는 말 그대로 "단기"를 의미합니다. 이는 일부 키 교환 프로토콜의 기능인 PFS(Perfect Forward Secrecy)를 이해하는 데 도움이 될 수 있습니다. PFS는 인증서의 개인 키가 손상되더라도 당사자 간에 교환되는 세션 키가 손상되지 않도록 보장합니다. 즉, 이전 세션이 추출 및 복호화되지 않도록 보호합니다. Heartbleed 버그가 발견된 후 PFS가 최우선 순위로 지정되었습니다. 이는 TLS 1.3의 핵심 구성 요소입니다.

RSA 키 교환 취약점

패딩을 악용할 수 있는 취약점이 있습니다( 심), 이전 버전의 RSA(PKCS #1 1.5)에서 키 교환 중에 사용됩니다. 이것이 암호화의 한 측면입니다. RSA를 사용하면 사전 마스터 비밀 키를 공개 키로 암호화하고 개인 키로 해독해야 합니다. 그러나 이 작은 사전 마스터 비밀이 더 큰 공개 키에 배치되면 패딩되어야 합니다. 대부분의 경우 내용을 추측하여 서버에 가짜 요청을 보내면 오류가 발생하며 불일치를 인식하여 필터링합니다. 그러나 올바른 채우기를 추측하기 위해 서버에 충분한 요청을 보낼 수 있는 좋은 기회가 있습니다. 그런 다음 서버는 잘못 완료된 메시지를 보내며, 이로 인해 사전 마스터 비밀의 가능한 값이 좁아집니다. 이를 통해 공격자는 키를 계산하고 손상시킬 수 있습니다.

이것이 TLS 1.3에서 DHE를 위해 RSA가 제거된 이유입니다.

TLS 1.3 핸드셰이크의 키 교환

TLS 1.3 핸드셰이크에서는 제한된 키 교환 체계 선택으로 인해 클라이언트가 성공적으로 체계를 추측하고 핸드셰이크의 초기(Client Hello) 단계에서 공유 키 부분을 보낼 수 있습니다.

RSA는 TLS 1.3에서 제거된 유일한 키 교환 체계가 아니었습니다. 임시적이지 않은 Diffie-Hellman 체계도 제거되었으며 보안이 충분하지 않은 Diffie-Hellman 매개변수 목록도 제거되었습니다.

보안 설정이 충분하지 않다는 것은 무엇을 의미합니까? 수학에 들어가지 않고 Diffie-Hellman과 대부분의 공개 키 암호화 시스템의 복잡성은 이산 로그 문제를 해결하는 복잡성입니다. 암호화 시스템은 입력 매개변수(클라이언트 및 서버 난수)를 알 수 없는 경우 계산할 수 있을 만큼 복잡해야 합니다. 그렇지 않으면 전체 체계가 쓸모 없게 됩니다. 충분히 큰 매개변수를 제공할 수 없는 Diffie-Hellman 체계는 TLS 1.3에서 제거되었습니다.

TLS 1.3 핸드셰이크가 시작될 때 클라이언트는 DHE 키 계약 체계가 사용될 것임을 알고 "클라이언트 Hello" 메시지에 의도된 키 교환 체계를 기반으로 하는 공유 키 부분을 포함합니다.
서버는 이 정보를 수신하고 클라이언트가 올바른 경우 "Server Hello"에 공개 키의 일부를 반환합니다.
클라이언트와 서버는 세션 키를 계산합니다.

이는 TLS 1.3에서 키 교환이 더 일찍 발생한다는 점을 제외하면 TLS 1.2 핸드셰이크에서 DH에서 발생하는 것과 매우 유사합니다.

결론 대신

SSL/TLS 핸드셰이크는 안전한 인터넷의 핵심인 매혹적인 프로세스이지만 너무 빠르고 원활하게 발생하여 대부분의 사람들은 그것에 대해 생각조차 하지 않습니다.

적어도 뭔가 잘못될 때까지는 말이죠.