[Wireshark로 SSL/TLS 통신 과정 살펴보기]
1) [Handshake Protocol] Client Hello
- 클라이언트가 서버에 처음으로 연결을 요청할 때 보낸다.
- Client SSL 버전 / Cipher Suites / Session ID / Random Number 등의 정보를 전달한다.
- 서버가 클라이언트의 기능과 기본 설정에 따라 적절한 보안 설정을 결정할 수 있다.
- 이를 통해 클라이언트와 서버 간의 통신 중 호환성과 보안을 보장할 수 있다.
- 정말로 클라이언트가 보낸 정보 중 Cipher Suite를 서버가 선택하는지 확인해보기 위해 16개의 Suite를 캡쳐했다.
- 초록색 박스를 눈여겨두고 다음으로 넘어가서 확인해보자.
2) [Handshake Protocol] Server Hello / ServerCertificate / ServerKeyExchange / ServerHelloDone
2.1) Server Hello
- ServerHello 메시지는 보안 매개 변수 협상의 핵심 구성 요소로, 클라이언트와 서버가 모두 보안 연결의 세부 사항에 대해 합의하도록 보장한다.
- 클라이언트가 ServerHello 메시지를 수신하면 양측은 SSL/TLS Handshake 프로세스를 진행하며, 여기에는 서버 인증서 확인, 키 교환 및 세션 키 설정 등의 단계가 포함된다.
- 이러한 초기 메시지를 교환함으로써 클라이언트와 서버는 안전한 통신 세션을 위한 기반을 구축한다.
- SSL/TLS Handshake는 후속 단계를 계속 진행하여 암호화 키를 생성하고 양 당사자 간의 안전한 암호화 통신을 구축한다.
- 클라이언트가 보냈던 것과 똑같이 Client SSL 버전 / Cipher Suites / Session ID / Random Number 등의 정보를 전달한다.
- 초록색 박스에 보는 것과 같이, 서버는 클라이언트가 보낸 Cipher Suite 중에서 하나를 선택하고, 선택된 Cipher Suite는 클라이언트와 서버 간의 보안 통신에 사용되는 암호 알고리즘, 키 교환 방법 및 기타 암호 매개 변수를 결정한다.
2.2) Server Certificate
- "Server Certificate" 메시지는 클라이언트에게 서버의 디지털 인증서를 제공함으로써 SSL/TLS Handshake에서 중추적인 역할을 수행한다.
- 이 메시지는 클라이언트가 서버의 신원을 확인하고 신뢰를 확립하며 안전하게 암호화 키를 교환할 수 있도록 하여 클라이언트와 서버 간의 안전하고 암호화된 통신 기반을 형성한다.
- 서버의 인증이 필요한 경우, 서버의 Certificate 정보를 전송한다.
- 상호 협상을 통하여 생성된 인증서에서 살펴본 결과로 그대로 값이 포함되어 있다.
- 인증서를 생성할 때 입력했던 정보들이 실제로 포함되어 있는 것을 확인할 수 있다.
TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 999
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length: 995
Certificates Length: 992
Certificates (992 bytes)
Certificates (992 bytes)
Certificate Length: 989
Certificate: 308203d9308202c1a003020102020900f20653bfd60f1652300d06092a864886f70d0101… (pkcs-9-at-emailAddress=agyuuu@tistory.com,id-at-commonName=TIENE,id-at-organizationalUnitName=TIENE,id-at-organizationName=TIENE,id-at-localityName=G
''' 중략 '''
rdnSequence: 7 items (pkcs-9-at-emailAddress=agyuuu@tistory.com,id-at-commonName=TIENE,id-at-organizationalUnitName=TIENE,id-at-organizationName=TIENE,id-at-localityName=Gangnam,id-at-stateOrProvinceName=Seoul,id-at-countryName=KR)
RDNSequence item: 1 item (id-at-countryName=KR)
RDNSequence item: 1 item (id-at-stateOrProvinceName=Seoul)
RDNSequence item: 1 item (id-at-localityName=Gangnam)
RDNSequence item: 1 item (id-at-organizationName=TIENE)
RDNSequence item: 1 item (id-at-organizationalUnitName=TIENE)
RDNSequence item: 1 item (id-at-commonName=TIENE)
RDNSequence item: 1 item (pkcs-9-at-emailAddress=agyuuu@tistory.com)
subjectPublicKeyInfo
extensions: 3 items
algorithmIdentifier (sha256WithRSAEncryption)
Padding: 0
encrypted: 7f1077c23782b850728da673dd98a46a3b0114b9dc1e44638d270053e4cd342d54b4034d…
2.3) Server Key Exchange
- "ServerKeyExchange" 메시지는 키 교환을 위해 서버의 인증서를 넘어서는 추가 데이터가 필요할 때 요청하는 메시지다.
- 키 교환에 필요한 정보를 교환하기 위해 전송하는 메시지다.
- 이는 클라이언트와 서버 모두 공유 비밀 키를 계산하는 데 필요한 정보를 보유하도록 보장하며, 이는 두 당사자 간의 안전하고 암호화된 통신을 위한 기반을 형성한다.
2.4) Server Hello Done
- "Server Hello Done" 메시지는 SSL/TLS 핸드셰이크의 단순하지만 중요한 부분이다.
- 이는 Handshake 프로세스에서 서버의 역할이 완료되었음을 나타내고 클라이언트가 추가 확인 및 암호화 키 생성을 포함하여 단계를 계속 진행하도록 요청한다.
- 서버가 보낼 메시지는 다 보냈다는 메시지로 보면 된다.
3) [Handshake Protocol] ClientKeyExchange / ChangeCihperSpec / EncryptedHandshake
3.1) Client Key Exchange
- "Client Key Exchange" 메시지는 SSL/TLS Handshake 프로세스의 중추적인 단계다.
- 이는 클라이언트가 서버와 키 자료를 공유할 수 있도록 하여 암호화 키 도출의 기초가 되는 공유 비밀 키(a shared secret)의 생성을 가능하게 한다.
- 그런 다음, 이러한 키는 세션 전체에서 클라이언트와 서버 간의 안전하고 기밀하며 인증된 통신에 사용된다.
- 클라이언트가 세션키를 생성하기 위해 임의의 pre master secret을 생성한다.
- RSA / DH / ECDH에 따라서 암호화된다.
3.1) Change Cipher Spec
- 클라이언트에 의해 전달된 "Change Cipher Spec" 메시지는 SSL/TLS 핸드셰이크 프로세스의 중추적인 단계다.
- 이는 Handshake 협상에서 보안 통신으로의 전환을 알리는 신호로, 후속 메시지가 암호화되고 보안 매개 변수를 사용하여 무결성이 보호됨을 나타낸다.
- 이후에 전송되는 메시지는 새롭게 협상된 알고리즘과 키를 이용할 것임을 알리는 신호다.
- 이 메시지는 클라이언트와 서버 간에 교환되는 데이터의 기밀성과 무결성을 보장하는 핵심 부분이다.
4.3) Encrypted Handshake
- Wireshark의 "Encrypted Handshake"라는 용어는 현재 표시되는 Handshake가 설정된 보안 세션의 일부로 암호화되었다는 것을 알려준다.
- 이는 Handshake 메시지가 암호화되었음을 나타내기 위해 사용되는 레이블이다.
- Wireshark는 암호화된 Handshake 메시지를 초기 일반 텍스트 Handshake 메시지와 구별하기 위해 이 레이블을 사용한다.
4) [Handshake Protocol] New Session Ticket / Change Cihper Spec / Encrypted Handshake
4.1) New Session Ticket
- "New Session Ticket" 메시지는 효율적인 세션 재개 및 세션 관리를 가능하게 하는 TLS 프로토콜의 기능이다.
- 클라이언트가 향후 연결 시 빠른 세션 재개를 위해 세션 티켓을 저장할 수 있도록 하여 전체 핸드셰이크의 필요성을 감소한다.
- 세션 재개 메커니즘의 일부로, 클라이언트가 이전에 설정된 세션을 더 빨리 다시 설정할 수 있도록 세션 티켓을 저장할 수 있다.
- 이는 TLS 보안 통신에서 연결 속도 향상, 서버 부하 감소 및 전반적인 성능 향상에 기여한다.
4.2) Change Cipher Spec
- 서버에 의해 전달된 "Change Cipher Spec" 메시지는 SSL/TLS 핸드셰이크 프로세스의 중추적인 단계다.
- 이는 Handshake 협상에서 보안 통신으로의 전환을 알리는 신호다.
- 후속 메시지가 암호화되고 보안 매개 변수를 사용하여 무결성이 보호됨을 나타낸다.
- 이 메시지는 클라이언트와 서버 간에 교환되는 데이터의 기밀성과 무결성을 보장하기 위한 핵심 부분이다.
4.3) Encrypted Handshake
- Wireshark에서 SSL/TLS 트래픽을 분석할 때 "Encrypted Handshake" 레이블이 나타나면 기본적으로 관찰 중인 핸드셰이크 메시지가 이제 클라이언트와 서버 간에 설정된 보안 통신의 일부로 암호화되었음을 나타낸다.
5) [Record Protocol] Application Data
- "ApplicationData" 메시지는 SSL/TLS 핸드셰이크 프로세스의 마지막 단계이다.
- 실제 응용 프로그램 데이터가 클라이언트와 서버 간에 안전하게 전송되는 수단이다.
- 이 메시지는 SSL/TLS의 핵심 목적인 기밀 및 인증된 통신을 위한 안전한 채널을 제공한다.
- 안전한 채널을 제공함으로써 데이터를 안전하게 교환할 수 있도록 한다.
참조 : ChatGPT
ChatGPT
A conversational AI system that listens, learns, and challenges
chat.openai.com
How TLS/SSL Works: Logon and Authentication
Table of contents How TLS/SSL Works Article 01/08/2015 In this article --> Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2 How TLS/SSL Works In this section Schannel SSP Architecture TLS/S
learn.microsoft.com
'IT > Network' 카테고리의 다른 글
| [CentOS] SMTP Command 알아보기 [Wireshark / ChatGPT] (0) | 2023.09.13 |
|---|---|
| [Network] DMZ를 구성하는 이유는? (0) | 2023.09.07 |
| [Network] Wireshark로 IPSec 통신 과정 살펴보기 [GNS3 / Wireshark] (0) | 2023.08.14 |
| [Network] IPSec 알아보기 (0) | 2023.08.14 |
| [Network] SSL/TLS Handshake 알아보기 [Wireshark / ChatGPT] (0) | 2023.08.11 |