전송 계층 보안

3. 개발 역사

넷스케이프가 SSL 규약을 처음 개발했다. SSL 1.0 버전은 공개되지 않았고, 1995년 2월에 SSL 2.0 버전이 출시되었다. 그러나 SSL 2.0 버전은 여러 보안 결함이 발견되어, 1996년에 출시된 SSL 3.0 버전으로 대체되었다. SSL 3.0은 IETF에서 1999년 1월에 RFC 2246 표준 규약으로 정의된 TLS 1.0의 기반이 되었다.^[40][19][20]

TLS는 1986년 8월에 시작된 국립안보국, 국립표준국, 국방통신국, 그리고 12개의 통신 및 컴퓨터 회사 간의 공동 이니셔티브인 보안 데이터 네트워크 시스템(SDNS) 프로젝트를 통해 개발되었다.^[23] 이 프로토콜은 원래 SP4 프로토콜로 알려졌으나, TLS로 이름이 변경되었고, 1995년에 국제 표준 ITU-T X.274|ISO/IEC 10736:1995로 발표되었다.

TLS는 대부분 연결 지향형 전송 계층 프로토콜(일반적으로 TCP)과 응용 계층 사이에서 사용되도록 설계되었다. TLS 1.1 이후를 기반으로 한 프로토콜은 UDP나 DCCP와 같은 데이터그램형 프로토콜에서도 구현되었으며, 이는 DTLS로 독립적으로 표준화되었다.

4. 보안부분 약점

패킷이 암호화되어 송수신되므로 스니핑 공격에서는 뛰어난 보안성을 보인다. 그러나 암호화된 패킷이 클라이언트 PC 또는 서버로 전송되기 때문에 송수신 간 데이터 교환 자체는 막을 수 없다. 따라서 개인정보 유출, DDoS, APT, 악성코드 공격에는 취약하다.^[478]

TLS는 공개 키 인증서를 사용하여 인증을 수행하고 사칭을 최대한 막으려 한다. 그러나 시스템의 자동적인 대응에는 한계가 있어 모든 사칭을 탐지할 수 있는 것은 아니다. 공개 키 인증서에는 인증 기관의 전자 서명이 주어지는데, 이 서명의 정당성을 평가하려면 인증 기관의 인증서, 최종적으로는 루트 인증서가 필요하다. 각 시스템은 신뢰할 수 있는 루트 인증서를 미리 가지고 있다. 인증 기관은 비밀 키를 엄중히 비밀로 하고, 인증서 발행 시 정당한 서버 관리자인지 확인해야 한다. 이러한 점들이 보장되지 않으면 TLS 인증 기능이 무너질 수 있다.

TLS로 인증을 수행하려면 인증 기관의 서명 외에도 인증서 발행처를 확인해야 한다. 확인하지 않으면 서버 A의 관리 권한이 없는 자가 서버 B로서 정당한 인증서를 취득해 서버 A를 사칭할 수 있다. TLS용 서버 인증서에는 발행처 서버의 호스트명이 기록되어 있으며, 클라이언트는 자신이 접속하려는 서버의 호스트명과 일치하는지 확인해야 한다.

현실에서는 "정당한" 서버라도 검증 결과 "문제가 있다"고 판단되는 인증서를 사용하는 경우가 많다. 보안 연구자 다카기 히로미츠는 이러한 인증서를 오레오레 인증서라고 부르며 비판한다.^[192]

이 검증은 시스템에 지정된 접속처의 호스트명과 실제로 접속한 곳의 호스트명이 일치하는지를 확인하는 것이며, 이용자가 의도하는 접속처와 반드시 일치하는 것은 아니다.

예를 들어, 이용자가 접속하려는 서버 A가 호스트명 www.example.'''com'''으로 서비스를 제공하고, 공격자가 서버 B 및 호스트명 www.example.'''org'''를 취득한 경우를 생각해 보자. 공격자가 DNS 스푸핑에 성공하여 www.example.com으로의 접속을 서버 B로 유도할 수 있어도, www.example.com의 서버 인증서를 입수할 수 없기 때문에 TLS 접속을 제공할 수 없다. 그러나 공격자는 www.example.org의 서버 인증서를 입수할 수 있다. 따라서 서버 A에 접속하려는 이용자를 www.example.com이 아닌 www.example.org로 접속시킬 수 있다면, 클라이언트에서는 정당한 인증서를 가진 서버로밖에 보이지 않는다.

이용자가 의도하는 접속처인지 판단하려면 다음 두 가지 조건을 만족해야 한다.

# 이용자는 의도하는 접속처의 올바른 호스트명을 알고 있다.

# 이용자는 현재 시스템에 지정된 접속처가 자신이 알고 있는 올바른 호스트명과 일치하는지 확인할 수 있다.

두 번째 조건은 정보 처리 추진 기구(IPA)가 공개한 "안전한 웹사이트 만드는 방법"^[193]의 "[피싱] 사기를 조장하지 않기 위한 대책"에 해당한다.

5. 주요 특징

전송 계층 보안(TLS) 프로토콜은 1986년 8월, 미국 국립안보국(NSA), 국립표준국(NIST), 국방통신국(DCA) 및 12개 통신/컴퓨터 회사 간의 공동 이니셔티브인 보안 데이터 네트워크 시스템(SDNS) 프로젝트에서 시작되었다.^[23] 1987년 9월 제10회 전국 컴퓨터 보안 컨퍼런스에서 발표된 이 연구는 공공 및 사설 인터넷 애플리케이션을 위한 차세대 보안 컴퓨터 통신 네트워크 및 제품 설계를 목표로 했다.

원래 SP4 프로토콜로 알려졌던 이 프로토콜은 TLS로 이름이 변경되었고, 1995년에 국제 표준 ITU-T X.274|ISO/IEC 10736:1995로 발표되었다.

TLS/SSL 프로토콜의 주요 특징은 다음과 같다.

• 암호화: SSL 인증서는 웹 서버와 사용자 브라우저 간에 전송되는 데이터를 암호화하여 전송 과정에서 민감한 정보를 보호한다.
• 인증: SSL 인증서는 웹사이트의 무결성을 보장하고 방문자가 악의적인 사칭자가 아닌 올바른 서버에 연결되도록 돕는다.
• 무결성: SSL은 암호화 기술을 사용하여 서버와 브라우저 간에 통신되는 데이터가 전송 중에 변경되지 않고 온전하게 유지되도록 검증한다.

5. 1. 알고리즘

• 키 교환: RSA, Diffie-Hellman, ECDH, SRP, PSK
• 인증: RSA, DSA, ECDSA
• 대칭키 암호: RC4, 트리플 DES, AES, IDEA, DES, 아리아, ChaCha20, Camellia. (옛날 버전 SSL에서는 RC2가 쓰임)
• 해시 함수: TLS에서는 HMAC-MD5 또는 HMAC-SHA. (SSL에서는 MD5와 SHA. 옛날 버전 SSL에서는 MD2와 MD4가 쓰임)^{[31][32][33][34]}

• 키 공유 방식으로 DSS 서명을 사용한 EDH(Ephemeral Diffie-Hellman)를 사용한다.
• 인증 암호로 평문에 MAC을 붙인 후 공통키 암호화하는 MAC-then-Encrypt(MtE)형을 사용한다.
• 공통키 암호로 CBC 모드의 256비트 키 AES를 사용한다.
• MAC으로는 SHA256 해시 함수를 기반으로 한 HMAC을 사용한다.

• '''DH-ANON''' (Anonymous DH), '''ECDH-ANON''' (Anonymous ECDH): 전송 데이터에 서명하지 않고 DH 키 공유, ECDH 키 공유를 수행한다.
• '''DHE-*''' ('''Ephemeral DH'''): 키 공유 시 클라이언트, 서버가 임의의 값을 선택하고, 지수승을 계산하여 서명문을 첨부하여 교환한다. "'''*'''" 부분에는 서명 방식이 기재된다. '''ECDHE-***'''는 DHE의 타원 DH 버전이다.
• '''DH-*''' ('''Fixed DH''' 또는 '''non-interactive DH'''): 디피-헬만 키 교환에서 사용하는 매개변수(클라이언트, 서버의 지수승 값)가 클라이언트나 서버의 공개키로 인증 기관으로부터 공개키 인증서를 수신한 경우이다. "'''*'''" 부분에는 공개키 인증서 내의 서명 방식을 기재한다. '''ECDH-***''' ('''Fixed ECDH''')는 Fixed DH의 타원 DH 버전이다.
• '''RSA-***''': 임의로 선택한 공유키를 서버의 공개키로 RSA 암호화하고, 암호문에 지정된 서명 방식으로 서명하여 ClientKeyExchange에서 서버로 보낸다. (ServerKeyExchange에서는 아무것도 보내지 않음).

5. 1. 1. 키 교환 또는 키 합의

• RSA: RSA로 생성된 공개 키와 개인 키를 사용한다. (TLS 핸드셰이크 프로토콜에서 TLS_RSA로 표시)
• 디피-헬만 (TLS_DH)
• 타원 곡선 디피-헬만 (TLS_ECDH)
• 익명 디피-헬만 (TLS_DH_anon): 서버나 사용자를 인증하지 않으므로 중간자 공격에 취약하여 거의 사용되지 않는다.
• 사전 공유 키 (TLS_PSK)
• 보안 원격 암호 (TLS_SRP)

교환/합의 중에 사용되는 공개 키 인증서도 교환 중에 사용되는 공개/개인 암호화 키의 크기가 다르며, 이에 따라 제공되는 보안의 견고함도 다르다. 2013년 7월 구글(Google)은 사용자가 제공하는 TLS 암호화의 보안을 강화하기 위해 1024비트 공개 키를 더 이상 사용하지 않고 2048비트 키로 전환할 것이라고 발표했다. 이는 암호화 강도가 키 크기와 직접적인 관련이 있기 때문이다.^[72][73]

5. 1. 2. 인증

5. 1. 3. 대칭키 암호

AES CBC는 TLS 1.0에 포함되어 있지 않지만, RFC 3268에서 추가되었다. TLS 1.1에서는 RFC 3268을 참조하며, TLS 1.2에서는 정의에 AES CBC에 관한 기술이 포함되었다. 또한, 인증 암호에 의한 AES GCM (RFC 5288, RFC 5289), AES CCM (RFC 6655, RFC 7251)이 추가되었다. IDEA CBC, DES CBC는 TLS 1.2에서 폐지되었다. (RFC 5469에 해설이 있다.)

블록 암호의 CBC 모드에서의 이용에 대해서는, TLS 1.0 이전에서 BEAST 공격이 가능하다는 것이 밝혀졌으며, 대응이 필요하다. TLS 1.1 이후에서는 이 공격에 대한 근본적인 대처로서 초기화 벡터를 명시적으로 지정하고, 패딩 처리가 개선되었다. 블록 암호여도 GCM, CCM 등의 인증 암호를 사용하는 경우에는 이러한 공격을 받지 않는다.

스트림 암호인 RC4는 BEAST 공격을 받지 않지만, RC4에는 사양상의 취약성이 존재한다. (RC4 공격). 2015년 2월, TLS의 모든 버전에서 RC4의 이용을 금지하는 RFC 7465가 공개되었다. 스트림 암호인 ChaCha20과 인증을 위한 Poly1305를 조합한 ChaCha20+Poly1305가 RFC 7905로 표준화되었다.

몇몇 국가 표준에 기반한 암호화 알고리즘도 TLS에서 사용할 수 있으며, 일본의 CRYPTREC에 의한 권장 암호인 카멜리아 (CBC 모드：RFC 4132, RFC 5932, RFC 6367, GCM：RFC 6367), 한국의 정보 통신 표준 규격에 채용된 SEED (CBC 모드：RFC 4162), ARIA (CBC 모드 및 GCM：RFC 6209)가 추가되었다. 또한, 독립 국가 연합의 GOST 규격에 의해 규정된 암호화 알고리즘인 GOST 28147-89도 제안되고 있다.^[216]

5. 1. 4. 암호화 해시 함수

5. 2. 디지털 인증서

• '''암호화''': SSL 인증서는 웹 서버와 사용자의 브라우저 간에 전송되는 데이터를 암호화하여 전송 과정에서 민감한 정보가 보호되도록 한다.
• '''인증''': SSL 인증서는 웹사이트의 무결성을 보장하고 방문자가 악의적인 사칭자가 아닌 올바른 서버에 연결되도록 돕는다.
• '''무결성''': SSL 인증서는 데이터 무결성을 보장한다. SSL은 암호화 기술을 사용하여 서버와 브라우저 간에 통신되는 데이터가 전송 중에 변경되지 않고 온전하게 유지되도록 검증한다.

5. 2. 1. 인증 기관

5. 3. Forward Secrecy

6. 프로토콜 상세 정보

넷스케이프는 최초의 SSL 프로토콜을 개발했으며, 1995년부터 1998년까지 넷스케이프의 수석 과학자였던 타헤르 엘가말은 "SSL의 아버지"로 묘사된다.^{[31][32][33][34]} SSL 1.0은 심각한 보안 결함으로 공개되지 않았고, 1995년 2월에 출시된 SSL 2.0 역시 여러 보안 및 사용성 결함이 있었다.

이러한 결함으로 인해 1996년 SSL 3.0이 출시되었다.^[35][33] SSL 2.0은 2011년에, SSL 3.0은 2014년 POODLE 공격에 취약점이 발견되어 2015년에 더 이상 사용되지 않게 되었다.

넷스케이프 커뮤니케이션즈가 설계한 SSL 첫 번째 버전은 설계 검토 단계에서 큰 취약점이 발견되어 폐기되었다. 넷스케이프는 SSL 1.0의 문제를 수정, 재설계하여 1994년에 SSL 2.0을 발표했고, Netscape Navigator 1.1에 구현했다. 이후 SSL 2.0의 취약점이 발견되어 SSL 3.0에서 수정되었다. SSL 3.0은 SSL 2.0과의 호환을 위해 난수 영역을 사용한 트릭을 추가, 공격 탐지 메커니즘을 내장했다. 2011년 3월, SSL 2.0 사용이 금지되었다.

TLS는 핸드셰이크 프로토콜의 ClientHello, ServerHello에서 사용할 암호 스위트(ciphersuite)를 결정한다. TLS 1.2에서 암호 스위트는 다음과 같은 형식으로 표현한다.

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

이는 다음을 의미한다.

• 키 공유 방식: EDH(Ephemeral Diffie-Hellman) 통신에 DSS 서명 사용
• 인증 암호: 평문에 MAC을 붙인 후 공통 키 암호화(MAC-then-Encrypt(MtE)형)
• 공통 키 암호: CBC 모드의 256비트 키 AES 사용
• MAC: SHA256 해시 함수 기반 HMAC 사용

• '''DH-ANON''' (Anonymous DH), '''ECDH-ANON''' (Anonymous ECDH): 서명 없이 DH 키 공유, ECDH 키 공유 수행
• '''DHE-*''' ('''Ephemeral DH'''): 키 공유 시 클라이언트, 서버가 임의 값을 선택, 계산 값에 서명문을 첨부하여 교환. 서명 방식은 "'''*'''" 부분에 기재. '''ECDHE-***'''는 DHE의 타원 DH 버전
• '''DH-*''' ('''Fixed DH''' 또는 '''non-interactive DH'''): 디피-헬만 매개변수(클라이언트와 서버 특정 값)가 클라이언트나 서버 공개 키로 인증 기관에서 공개 키 인증서를 수신한 경우의 디피-헬만 키 공유. 공개 키 인증서 내 서명문 작성 서명 방식은 "'''*'''" 부분에 기재. '''ECDH-***''' ('''Fixed ECDH''')는 Fixed DH의 타원 DH 버전
• '''RSA-*''': 임의 선택 공유 키를 서버 공개 키로 RSA 암호화, 암호문을 "'''*'''"로 지정된 서명 방식으로 서명하여 ClientKeyExchange에서 클라이언트가 서버로 전송 (ServerKeyExchange에서는 아무것도 보내지 않음)

TLS_PSK, TLS_SRP, Kerberos를 사용한 KRB5도 존재한다.

독립 국가 연합의 GOST 표준에 의해 규정된 키 공유 알고리즘인 GOST R 34.10도 제안되었다.^[216]

6. 1. TLS 핸드셰이크

• 키 교환: RSA, Diffie-Hellman, ECDH, SRP, PSK
• 인증: RSA, DSA, ECDSA
• 대칭키 암호: RC4, 트리플 DES, AES, IDEA, DES, 아리아, ChaCha20, Camellia. (SSL 구 버전에서는 RC2 사용)
• 해시 함수: TLS에서는 HMAC-MD5 또는 HMAC-SHA. (SSL에서는 MD5와 SHA, SSL 구 버전에서는 MD2와 MD4 사용)

• 클라이언트는 보안 연결을 요청하며 TLS를 지원하는 서버에 연결하고, 지원하는 암호화 제품군 목록(암호 및 해시 함수)을 제시한다.
• 서버는 지원하는 암호 및 해시 함수를 선택하고 클라이언트에 알린다.
• 서버는 디지털 인증서 형태로 신원을 제공한다. ( 서버 이름, 인증서의 진위 여부를 보증하는 신뢰할 수 있는 인증 기관(CA), 서버의 공개 암호화 키 포함)
• 클라이언트는 인증서의 유효성을 확인한다.
• 보안 연결에 사용되는 세션 키를 생성하기 위해 클라이언트는 다음 중 하나를 수행한다.
• 서버의 공개 키로 난수(''PreMasterSecret'')를 암호화하여 서버에 보낸다. (서버만 개인 키로 해독 가능) 이후 양측은 난수를 사용하여 세션 동안 데이터 암호화 및 해독을 위한 고유한 세션 키를 생성한다.
• 디피-헬만 키 교환 (또는 타원 곡선 DH)을 사용하여 전방 보안 속성을 갖는 암호화 및 해독을 위한 무작위하고 고유한 세션 키를 안전하게 생성한다. (서버의 개인 키가 나중에 공개되어도 제3자가 현재 세션을 해독할 수 없다.)

;메시지 유형: 핸드셰이크 메시지 유형을 식별한다.

;핸드셰이크 메시지 데이터 길이

: 헤더를 제외한 핸드셰이크 데이터의 길이를 나타내는 3바이트 필드이다.

하나의 레코드 내에 여러 핸드셰이크 메시지가 결합될 수 있다.

넷스케이프 커뮤니케이션즈가 SSL의 첫 번째 버전을 설계했지만, 설계 검토 단계에서 프로토콜 자체에 큰 취약점이 발견되어 폐기되었다.

넷스케이프는 SSL 1.0의 문제를 수정하고 재설계하여 1994년에 SSL 2.0을 발표했다. Netscape Navigator 1.1에 SSL 2.0을 구현했다.

이후, SSL 2.0에도 몇 가지 취약점이 발견되어 SSL 3.0에서 수정되었다. SSL 2.0의 취약점 중 하나는 협상 정보를 위조하면 제시된 선택지 중 가장 약한 알고리즘을 사용하게 할 수 있고(다운그레이드 공격), 위조된 것을 탐지할 수 없다는 것이다. 더욱 심각한 것은 이 취약점을 이용하면 양쪽 모두 SSL 3.0을 지원하더라도 SSL 2.0으로 연결되게 하는 것조차 가능하다.

SSL 3.0에서는 SSL 2.0과의 호환성을 위해 난수 영역을 사용한 트릭을 추가하여 이러한 공격을 탐지하는 메커니즘을 내장했다. 하지만 이 트릭이 비활성화된 서버 환경도 존재하며, 클라이언트 입장에서 보면 SSL 2.0을 비활성화하지 않는 한 이 취약점의 영향을 받을 가능성을 부정할 수 없다^[204] . SSL 3.0 이후를 지원하는 구현이 충분히 보급된 것으로, Internet Explorer 7이나 Mozilla Firefox 2, Opera 9 등은 초기 상태에서 SSL 2.0을 비활성화하고 있다^{[205][206][207]} .

SSL 2.0에는 체인 인증서가 없으며, 루트 CA에서 발급한 SSL 서버 인증서만 사용할 수 있다.

2011년 3월, SSL 2.0의 사용은 금지되었다.

TLS에서는 핸드셰이크 프로토콜의 ClientHello, ServerHello에서 이후 통신에 사용할 암호 스위트(ciphersuite)를 결정한다. TLS 1.2에서는 암호 스위트를 다음과 같은 형식으로 표현한다.

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

이는 다음과 같은 의미이다.

• 키 공유 방식으로 다음을 사용한다.
• EDH(Ephemeral Diffie-Hellman) 통신에
• DSS 서명한 것
• 인증 암호로 평문에 MAC을 붙인 후에 공통 키 암호화하는 것(MAC-then-Encrypt(MtE)형)으로
• 공통 키 암호로 CBC 모드의 256비트 키 AES를 사용하고,
• MAC으로는 SHA256 해시 함수를 기반으로 한 HMAC을 사용한다.

• '''DH-ANON''' (Anonymous DH), '''ECDH-ANON''' (Anonymous ECDH)은 각각 전송 데이터에 서명하지 않고 DH 키 공유, ECDH 키 공유를 수행하는 방식이다.
• '''DHE-*'''는 '''Ephemeral DH'''라고 불리며, 키 공유 시 클라이언트, 서버가 임의의 값을 선택하고, 각 값을 이용해 계산한 값에 서명문을 첨부하여 교환하는 방식이다. 서명 방식은 "'''*'''" 부분에 기재된 것을 사용한다. '''ECDHE-***'''는 DHE의 타원 DH 버전이다.
• '''DH-*'''는 '''Fixed DH''' 또는 '''non-interactive DH'''라고 불리며, 디피-헬만에서 사용하는 매개변수(클라이언트와 서버의 특정 값)가 클라이언트나 서버의 공개 키로 인증 기관으로부터 공개 키 인증서를 수신한 경우의 디피-헬만 키 공유이다. 공개 키 인증서 내의 서명문을 작성하는 서명 방식은 "'''*'''" 부분에 기재된 것을 사용한다. '''ECDH-***''' ('''Fixed ECDH''')는 Fixed DH의 타원 DH 버전이다.
• '''RSA-*'''는 임의로 선택한 공유 키를 서버의 공개 키로 RSA 암호화하고, 암호문을 "'''*'''"로 지정된 서명 방식으로 서명한 것을 ClientKeyExchange에서 클라이언트가 서버로 보내는 방식이다. (ServerKeyExchange에서는 아무것도 보내지 않음).

를 사용한 TLS_PSK, 을 사용한 TLS_SRP, Kerberos를 사용한 KRB5도 존재한다.

독립 국가 연합의 GOST 표준에 의해 규정된 키 공유 알고리즘인 GOST R 34.10도 제안되었다^[216]。

6. 1. 1. 기본 TLS 핸드셰이크

• 클라이언트는 지원하는 가장 높은 TLS 프로토콜 버전, 임의의 숫자, 제안된 암호화 제품군 목록 및 제안된 압축 방법을 지정하는 '''ClientHello''' 메시지를 보낸다.
• 서버는 클라이언트가 제공한 선택 사항에서 선택한 프로토콜 버전, 임의의 숫자, 암호 제품군 및 압축 방법을 포함하는 '''ServerHello''' 메시지로 응답한다. 선택한 프로토콜 버전은 클라이언트와 서버 모두가 지원하는 가장 높은 버전이어야 한다.
• 서버는 '''Certificate''' 메시지를 보낸다(선택한 암호 제품군에 따라 서버에서 이 메시지를 생략할 수 있다).^[175]
• 서버는 '''ServerKeyExchange''' 메시지를 보낸다(선택한 암호 제품군에 따라 서버에서 이 메시지를 생략할 수 있다).
• 서버는 핸드셰이크 협상이 완료되었음을 나타내는 '''ServerHelloDone''' 메시지를 보낸다.
• 클라이언트는 ''PreMasterSecret''을 포함할 수 있는 '''ClientKeyExchange''' 메시지로 응답한다. 이 ''PreMasterSecret''은 서버 인증서의 공개 키를 사용하여 암호화된다.
• 클라이언트와 서버는 임의의 숫자와 ''PreMasterSecret''을 사용하여 "마스터 시크릿"이라는 공통 비밀을 계산한다. 이 연결에 대한 다른 모든 키 데이터(세션 키, IV, 대칭 암호화 키, MAC 키^[176])는 이 마스터 시크릿에서 파생된다.
• 클라이언트는 '''ChangeCipherSpec''' 레코드를 보내 서버에게 "지금부터 내가 말하는 모든 것은 인증됩니다(그리고 서버 인증서에 암호화 매개변수가 있는 경우 암호화됨)"라고 알린다.
• 클라이언트는 이전 핸드셰이크 메시지에 대한 해시 및 MAC을 포함하는 인증되고 암호화된 '''Finished''' 메시지를 보낸다.
• 서버는 클라이언트의 ''Finished'' 메시지를 해독하고 해시 및 MAC을 확인한다. 해독 또는 확인에 실패하면 핸드셰이크가 실패한 것으로 간주하고 연결을 종료해야 한다.
• 마지막으로 서버는 '''ChangeCipherSpec'''을 보내 클라이언트에게 "지금부터 내가 말하는 모든 것은 인증됩니다(그리고 암호화가 협상된 경우 암호화됨)"라고 알린다.
• 서버는 인증되고 암호화된 '''Finished''' 메시지를 보낸다.
• 클라이언트는 이전 단계에서 서버가 수행한 것과 동일한 해독 및 확인 절차를 수행한다.

6. 1. 2. 클라이언트 인증 TLS 핸드셰이크

• 클라이언트가 자신이 지원하는 가장 높은 TLS 프로토콜 버전, 난수, 제안된 암호 제품군 및 압축 방식 목록을 지정하는 '''ClientHello''' 메시지를 서버에 보낸다.
• 서버는 '''ServerHello''' 메시지로 응답한다. 이 메시지에는 클라이언트가 제공한 선택 항목에서 서버가 선택한 프로토콜 버전, 난수, 암호 제품군 및 압축 방식이 포함된다. 서버는 재개된 핸드셰이크를 수행하기 위해 ''세션 ID''를 메시지의 일부로 보낼 수도 있다.
• 서버는 자체 '''Certificate''' 메시지를 보낸다. (선택한 암호 제품군에 따라 서버는 이 메시지를 생략할 수 있다.)^[175]
• 서버는 자체 '''ServerKeyExchange''' 메시지를 보낸다. (선택한 암호 제품군에 따라 서버는 이 메시지를 생략할 수 있다.) 이 메시지는 모든 DHE, ECDHE 및 DH_anon 암호 제품군에 대해 전송된다.
• 서버는 클라이언트에게 인증서를 요청하기 위해 '''CertificateRequest''' 메시지를 보낸다.
• 서버는 핸드셰이크 협상이 완료되었음을 알리는 '''ServerHelloDone''' 메시지를 보낸다.
• 클라이언트는 클라이언트의 인증서를 포함하지만 개인 키는 포함하지 않는 '''Certificate''' 메시지로 응답한다.
• 클라이언트는 ''PreMasterSecret'', 공개 키 또는 아무것도 포함하지 않을 수 있는 '''ClientKeyExchange''' 메시지를 보낸다. (이 또한 선택한 암호에 따라 다릅니다.) 이 ''PreMasterSecret''는 서버 인증서의 공개 키를 사용하여 암호화된다.
• 클라이언트는 '''CertificateVerify''' 메시지를 보낸다. 이 메시지는 클라이언트 인증서의 개인 키를 사용하여 이전 핸드셰이크 메시지에 대한 서명이다. 이 서명은 클라이언트 인증서의 공개 키를 사용하여 확인할 수 있다. 이를 통해 서버는 클라이언트가 인증서의 개인 키에 접근할 수 있고, 따라서 인증서를 소유하고 있음을 알 수 있다.
• 클라이언트와 서버는 난수와 ''PreMasterSecret''를 사용하여 "마스터 비밀"이라고 하는 공통 비밀을 계산한다. 이 연결에 대한 다른 모든 키 데이터("세션 키")는 신중하게 설계된 의사 난수 함수를 통해 전달되는 이 마스터 비밀(및 클라이언트 및 서버에서 생성된 임의 값)에서 파생된다.
• 클라이언트는 '''ChangeCipherSpec''' 레코드를 보낸다. ChangeCipherSpec 자체는 레코드 수준 프로토콜이며 유형 20이다. 이것은 "지금부터 내가 알려주는 모든 것은 인증됩니다(그리고 암호화가 협상된 경우 암호화됩니다)."라고 서버에게 알리는 것이다.
• 마지막으로, 클라이언트는 이전 핸드셰이크 메시지에 대한 해시 및 MAC을 포함하는 암호화된 '''Finished''' 메시지를 보낸다.
• 서버는 클라이언트의 ''Finished'' 메시지를 해독하고 해시 및 MAC을 확인하려고 시도한다. 해독 또는 확인에 실패하면 핸드셰이크가 실패한 것으로 간주되고 연결이 끊어진다.
• 마지막으로 서버는 '''ChangeCipherSpec'''을 보내어 "지금부터 내가 알려주는 모든 것은 인증됩니다(그리고 암호화가 협상된 경우 암호화됩니다)."라고 클라이언트에게 알린다.
• 서버는 자체 암호화된 '''Finished''' 메시지를 보낸다.
• 클라이언트는 이전 단계에서 서버가 수행한 것과 동일한 해독 및 확인 절차를 수행한다.

6. 1. 3. 재개된 TLS 핸드셰이크

6. 2. TLS 레코드