[네트워크] 얕게 Wireshark 로 TCP, TLSv1.3 연결 확인해보기 (with ChatGPT)

 

 

HTML 문서가 있을 때, HTTP는 HTML을 나르는 프로토콜이고, 이때 TCP라는 인프라를 활용한다.
- 널널한 개발자 강의 중

 

 

인프런 강의 중 "외워서 끝내는 네트워크 핵심이론 - 기초"를 듣게 되었다. 평소 유튜브 채널 "널널한 개발자"를 잘 보고 있었는데, 왠지 들어야 할 거같은 느낌에 들었는데 TCP와 TLS에 대해 좀 더 알아보게 되었고 정리해보았다.  강의 링크

외워서 끝내는 네트워크 핵심이론 - 기초 - 인프런 | 강의

 

이 강의 덕분에 이론으로만 알고 있던 지식들이 하나로 이어지는 듯한 느낌을 받았습니다. 

---

Wireshark 설치 방법 (2가지)

1. GUI 버전

$ sudo apt install -y wireshark 

$ sudo usermod -aG wireshark $(whoami)

$ wireshark       // 실행

 

오류. Couldn't run /usr/bin/dumpcap in child process: 허가 거부

$ sudo chmod +x /usr/bin/dumpcap

+x : 실행 권한 추가

 

 

2. Command Line 버전

$ sudo apt install -y tshark

---

HTTP로 구글 접속시 Wireshark 분석

 

터미널 명령어로 확인해보도록 하였다

$ sudo tshark -i eno1 -f "tcp port 80"

// 다른 터미널에서 입력
$ curl www.google.com

 

참고1. 'eno1'는 네트워크 인터페이스로 ifconfig 명령어로 본인에게 맞는 명칭 사용하기

참고2. HTTP는 80포트가 wellknown포트로 알려져 있다

 

 

TCP 3-way handshake, 그리고 HTTP REQUEST GET

① Client가 임의 Sequence Number(0) 생성 후 Server에게 SYN(연결 초기화) 패킷 보냄 

 

②  SYN 패킷을 받은 Server는 연결 요청 수락, 그리고 Sequence Number(0) 생성하여 SYN, ACK 설정하여 Client에게 보낸 후  SYN_RCVD 상태에 들어감

SYN_RCVD(SYN_RECEIVED) : Client로부터 SYN 연결 요청 받은 후, Client 응답 ACK를 대기하는 상태

 

③ Client는 SYN + ACK를 받고 응답 ACK 보냄으로써 연결 설정완료, 그리고 서버는 Client의 ACK를 받은 후 연결 설정완료 (논리적 연결)

 

 

이론과 마찬가지로 TCP 연결(3-way handshake) 후 HTTP REQUEST GET 요청하는 것을 확인

Win : Window size , Buffer의 남은 용량(사이즈) 뜻함
MSS : Maximum Segment Size (중요**)

 

TCP 3-way handshake 연결 이후 

HTTP GET 요청시 아래 [TCP segment of a reassembled PDU] 메시지와 함께 계속 통신하는 모습을 보이는데, 요청 데이터를  Segment로 받아 재조립하는 것을 wireshark가 추적하여 표기하는 것으로 확인된다.

 

그리고 Client와 Server(구글, 172.217.25.164)가 통신하면서 각 세그먼트가 전송될 때 ACK 번호가 해당 세그먼트에 포함된 데이터 크기(1400)만큼 증가하는 모습을 보인다. - MSS (Maximum Segment Size) 

 

이는 곧 다음 Segment 위치를 나타내는 용도로 Ack가 사용되는 것으로 확인된다( ChatGPT 참고 )

 

 

 

4way-handshake(연결 종료)

① Client에서 먼저 연결 종료 요청하기 위해 FIN 보냄

② Server에서는 FIN 수신 후 연결 종료 동의하며 ACK를 보냄

③ Server에서 데이터를 모두 보냈으면 FIN + ACK를 보냄

④ Client에서 FIN을 수신 후 ACK를 보내면 Server는 바로 CLOSE가 되고, Client 는 TIME_WAIT 후 CLOST된다

이때 TIME_WAIT는 2 * MSL(Maximum Segment Lifetime, 세그먼트가 네트워크에서 유효한 시간, 120초) 이고, 잔여 데이터 처리 후 Socket 자원 반환

 

실제로 아래와 같이 200 OK 받은 이후 Client가 먼저 FIN 던져 종료하는 것을 확인 가능했다

- 클라이언트 Seq = 79, Ack = 25037
- 서버 : Seq=25037, Ack = 80

---

HTTPS로 구글 접속시 Wireshark 분석 - 대칭키(비밀키) 방식

- 2023.09.30 기준으로 ChatGPT 참고하여 공부한 내용 기록
- 대칭키(비밀키) 생성 알고리즘과 같이 현재 단계에서 이해하기 어려운 부분은 생략하고 흐름에 대해서만 기록

 

TLSv1.3 handShake 되는 과정은 아래와 그림과 같았다

① Client가 Server에게 연결을 요청하고, 지원하는 암호화 알고리즘 목록 및 Key Share Extension을 포함한 Diffie-Hellman 공유 값을 제시합니다. 

② Server는 Client가 제공한 암호화 알고리즘 선택 및 활성화(Change Cipher Spec), Server의 Diffie-Hellman 공유 값(=Key Share에 Key Exchange)을 제공합니다. 

③ Client는 Server에서 전달받은 Diffie-Hellman 공유 값을 사용하여 대칭키(비밀키) 생성, 그리고 암호화 활성화(Change Cipher Spec) 메시지와 암호화된 데이터 통신 수행

 

Key Exchange 과정은 애매해서 생략했는데, 결국 클라이언트와 서버가 상호 협의된 암호화 알고리즘과 데이터 값을 활용해 대칭키(비밀키)를 생성한다는 것으로 보였다. 

인증서(server's certificate)를 사용할 경우 공유키로 암호화한 대칭키(비밀키)를 교환하는데, PSK mode는 교환하지 않고 협의된 정보와 교환 데이터 가지고 대칭키(비밀키)를 각각 생성해서 사용하는 것으로 파악된다.

 

 

터미널에서 아래 명령어 수행하거나 wireshark 실행 후 구글 접속

$ sudo tshark -i eno1 -f "tcp port 443"

// 다른 터미널에서 입력
$ curl -tlsv1.3 https://www.google.com

참고. HTTPS 는 443포트가 well-Known포트로 알려져 있다

 

 

①단계. Client Hello

Random

- 서버와 클라이언트 간의 세션 식별하기 위한 용도

- 대칭키 생성하기 위해 활용

- 데이터 변경 감지 확인 용도(무결성 검증)

 

Seesion ID 

- Client와 Server가 처음 TLS handshake 연결시 서버는 Session id를 생성하여 Client에게 제공한다.

- Client는 Session id 정보를 저장하고, 재접속(연결) 시도시 해당 정보를 서버에 보냄 

- Server는 해당 Session id를 사용하여 Client를 식별하고 이전 Session 재개 

Session ID와 Connection ID는 다른 것으로 확인
Connection ID 가 HTTP 3.0 의 0-RTT 실현하는데 활용하는 것으로 기억

 

Cipher Suites

- 클라이언트가 사용가능한 암호 알고리즘 집합(목록)을 서버에게 보냄

- 서버에서는 "Server Hello" 보낼 때 암호 알고리즘 하나 선택해서 클라리언트에게 알려줌

- 선택된 알고리즘은 대칭키/서명/키 교환 알고리즘 등에 활용되는 것으로 파악 (ChatGPT)

서버에서 TLS_AES_256_GCM_SHA384 선택 후 client에게 알려준다

 

Extension : signature_algorithms

- Client가 지원하는 signature hash algorithms 목록을 Server에 보내면 이 중 하나 선택하여 SSL/TLS 인증서 서명한다.

- Server에서 인증서를 받아 클라이언트는 서명 유효성과 공개키를 확인하고, 안정성 검증되면 통신을 시작한다.

 

SHA-256이 클라이언트가 보낸 signature_algorithms 에서 선택된 알고리즘이 아닌가 추측

 

 

Extension : psk_key_exchange_modes

TLSv1.3에서 클라이언트가 대칭키(비밀키) 생성시 사용할 알고리즘 방식을 서버에게도 알려주는 역할

psk_dhe_ke (PSK with DHE Key Exchange)	PSK와 Diffie-Hellman Ephemeral (DHE)를 조합하여 대칭 키를 생성
psk_dh_ke (PSK with DH Key Exchange)	PSK와 Diffie-Hellman (DH)를 조합하여 대칭 키를 생성
psk_ecdhe_ke (PSK with ECDHE Key Exchange)	PSK와 Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)를 조합하여 대칭 키를 생성

 

Extension : key_share

- Server와 Client는 각각 Key Exchange 교환하고, 임의 Random과 Key Exchange값 등을 사용하여 대칭키(비밀키) 파생시킴

- Server와 Client는 생성된 대칭키(비밀키)를 통해 데이터의 무결성과 기밀성을 보장함

- 대칭키(비밀키)는 교환하지 x

- "Group : x25519"은 Elliptic Curve Diffie-Hellman (ECDH) 키 교환 알고리즘 중 하나를 나타냄 

Client에서 Server로 대칭키(비밀키) 생성에 필요한 정보 보냄

 

**서버와 클라이언트는 key_share, psk_key_exchange_mode, random 등과 같은 대칭키(비밀키) 생성을 위한 정보 교환하고, 특정 알고리즘 통해 동일한 대칭키(비밀키) 생성 하여 사용하게 된다는 걸로 이해

 

 

②단계. Server Hello, Change Cipher Spec

 

Cipher Suite

Client가 보낸 목록에서 선택한 암호 알고리즘에 대한 정보를 알려준다

 

Random 

마찬가지로 Client에서 대칭키(비밀키) 만들기 위한 데이터

 

Session ID 

Client의 식별자, 재접속 여부 판단

 

Extension : key_share

- Client가 보낸 x25519( Elliptic Curve Diffie-Hellman (ECDH) 키 교환 알고리즘) 사용

- Client에서 대칭키(비밀키) 파생하기 위한 Key Exchange 데이터 보냄

 

그리고 Change Chipher Spec 메시지 보내게 되는데, 이는 상호 협의된 암호화 방식으로 통신이 시작됨을 나타내는 것으로 확인됨

 

질문1. 서버에서 인증서(certificate) 보내고, Client는 이를 검증하는 과정이 필요한 걸로 아는데 wireshark에서는 확인불가인가요?

Wireshark에서 TLS 핸드셰이크 중 "Server Hello" 메시지에 인증서가 표시되지 않는 경우, 이는 TLS 1.3와 같은 최신 버전에서 표준 동작입니다. TLS 1.3에서는 인증서 교환 과정이 다른 버전과는 다르게 이루어집니다.

 

TLS 1.3에서의 주요 변경 사항 중 하나는 인증서 교환 과정을 최소화하고 단순화한 것입니다. 클라이언트와 서버는 인증서를 보내지 않거나 받지 않아도 대칭 키를 안전하게 협상할 수 있도록 설계되었습니다. 이를 통해 더 간단하고 효율적인 핸드셰이

크가 가능하며, 빠른 연결 설정을 제공할 수 있습니다.

 

따라서 "Server Hello" 메시지에 인증서가 표시되지 않는 경우가 있으며, 이것이 TLS 1.3의 표준 동작입니다. 인증서가 교환되지 않는다고 해서 보안이 떨어지는 것은 아닙니다. 대신, 다른 기술적인 메커니즘을 사용하여 보안성을 유지하고 있으며, 이러한 기술적인 세부사항은 핸드셰이크 프로세스 내부에 있습니다.

 

인증서의 유효성을 확인하려면 브라우저 또는 클라이언트 측에서 수행되며, 일반적으로 Wireshark와 같은 네트워크 패킷 캡처 도구에서는 이러한 인증서 확인 과정을 직접 확인하기 어렵습니다. 브라우저 또는 클라이언트에서 인증서를 검증하고 확인하므로 인증서의 유효성 여부를 확인하려면 해당 클라이언트에서 검사를 수행하십시오.

 

질문2. 이미 인증서를 가지고 있기 때문에 TLSv1.3 handshake에서 certificate(인증서)가 안 보이는게 아닌가요?

TLSv1.3에서는 클라이언트와 서버가 이미 공유한 사전 공유된 키 (PSK)를 사용하여 핸드셰이크를 수행할 수 있습니다. 이런 경우에는 인증서 교환 과정을 생략할 수 있으며, 따라서 TLSv1.3 핸드셰이크에서 "Certificate" 메시지가 표시되지 않을 수 있습니다. 이것은 TLSv1.3의 핵심 특징 중 하나입니다.

일반적으로 다음 두 가지 시나리오 중 하나가 발생합니다:

1. 사전 공유된 키 (PSK)를 사용하는 경우: 클라이언트와 서버가 이전 세션에서 공유한 PSK를 사용하여 연결을 재개할 때, 핸드셰이크에서 인증서 교환을 생략할 수 있습니다. PSK 모드에서는 핸드셰이크의 주요 목적은 대칭 키를 협상하고 연결을 보호하는 것이므로, 인증서를 교환할 필요가 없습니다.

2. 새로운 연결을 설정하는 경우: 새로운 연결을 설정하는 경우에는 클라이언트와 서버가 핸드셰이크를 통해 서로의 인증서를 교환할 수 있습니다. 이 경우에는 "Certificate" 메시지가 포함될 수 있습니다.

따라서 이미 인증서를 가지고 있는 경우에는 PSK 모드를 사용하여 핸드셰이크를 진행할 때 인증서 교환 과정이 생략될 수 있습니다. 이는 보안 및 성능을 향상시키는 데 도움이 됩니다.

 

질문3. PSK모드가 아닌 SSL/TLS 인증서를 사용할 경우 인증서를 검증하고, 서버의 공개키를 활용하여 임의 데이터를 암호화 후 서버에게 보내 대칭키(비밀키) 방식을 활성화 하나요?

네, SSL/TLS 인증서를 사용하는 경우 핸드셰이크에서 다음과 같은 단계가 일어납니다:

1. 서버 인증서 교환: 핸드셰이크 시작 시, 서버는 자신의 디지털 인증서를 클라이언트에게 제공합니다. 클라이언트는 이 인증서를 검증하여 서버의 신원을 확인합니다. 이것은 클라이언트가 서버가 실제로 원하는 서버인지를 확인하는 과정입니다.
2. 클라이언트 키 교환: 클라이언트는 서버의 인증서를 검증한 후, 공개 키를 추출하고 이 공개 키를 사용하여 임의 데이터를 암호화합니다. 이 데이터는 대칭 키를 안전하게 교환하기 위한 역할을 합니다. 이러한 방식은 전체 핸드셰이크 과정을 보호하는 역할을 합니다.
3. 서버 키 교환: 서버는 클라이언트로부터 받은 데이터를 자신의 비밀 키를 사용하여 복호화하고 대칭 키를 얻습니다.
4. 대칭 키를 사용한 통신: 이제 양측은 안전하게 대칭 키를 공유하고 대칭 키를 사용하여 애플리케이션 데이터를 암호화하고 해독할 수 있습니다.
   
   따라서 SSL/TLS 인증서를 사용하는 경우, 핸드셰이크 과정에서 서버 인증서의 검증과 공개 키를 사용한 대칭 키 교환이 이루어집니다. 이것은 클라이언트와 서버 간의 대칭 키를 안전하게 교환하는 데 사용됩니다. 이러한 방식은 통신의 기밀성과 무결성을 보호합니다.

 

 

참고. https://dev-ljw1126.tistory.com/76

[네트워크] 대칭키, 비대칭키 그리고 Https

개인적인 생각으로

- 최초 접속 시에는 인증서 받고, 검증 후 얻은 공개키로 암호화한 데이터를 비밀키(대칭키)로 활용하는 방식 사용

- 이후에는 합의 하에 PSK mode 사용하는게 아닌가 싶다

 

 

③단계. Change Cipher Spec, Application Data

Client에서는 상호 협의된 암호화 설정 활성화하고("Change Cipher Spec"), 암호화 통신으로 실제 데이터를 전송(Applcation Data) 하게 된다.

Encrypted Application Data가 암호화된 데이터

 

---

참고 

TCP 통신에 대해서 알아보자 - 이동욱 CTO

TCP 통신에 대해서 알아보자... | 개발자 이동욱

https://eunhyee.tistory.com/205

HTTPS 패킷 분석(TLS 1.2와 TLS 1.3)

 

https://m.blog.naver.com/PostView.naver?blogId=ucert&logNo=221234082080&categoryNo=37&proxyReferer= 

TLS 1.3 handskake

 

Decoding TLS 1.3 Protocol Handshake With Wireshark

 

https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=cr0sscert&logNo=221706613801 

TLS 1.3 특징, 기존 TLS 버전과의 차이점

 

https://thesecmaster.com/decoding-tls-1-3-protocol-handshake-with-wireshark/#Step_3_Change_Cipher_Spec_Client_Finished_and_Encrypted_Application_data

Decoding TLS 1.3 Protocol Handshake With Wireshark