개요
이번 블로그 포스트에서는 Wireshark를 사용하여 pc 에서 www.naver.com으로의 네트워크 트래픽 캡처를 통해 TCP와 TLS 통신 시퀀스를 상세히 분석해보겠습니다.
DNS 쿼리와 응답
TCP 3way handshake (open)
TLS client hello & handshake
TCP 4way handshake (close)
DNS 쿼리
프레임 541
클라이언트 A가 DNS 서버 B에 www.naver.com의 A 레코드를 요청
www.naver.com에 대한 IPv4 주소를 얻기 위함
프레임 542
클라이언트 A가 DNS 서버 B에 www.naver.com의 HTTPS 레코드를 요청
도메인 이름에 대한 HTTPS 서비스 정보를 얻기 위함
프레임 543
DNS 서버 B가 HTTPS 레코드 요청에 대해 응답
응답에는 www.naver.com이 www.naver.com.nheos.com의 CNAME임을 알려주고, SOA 레코드도 포함되어 있다.
- CNAME 레코드란?
요청된 도메인이 다른 도메인으로 매핑될 때 사용되며, DNS 서버가 이를 통해 정확한 IP 주소를 찾도록 도와준다.
프레임 544
DNS 서버 B가 A 레코드 요청에 대해 응답
www.naver.com의 여러 A 레코드가 포함
- A 레코드란?
도메인 이름을 실제로 접근할 수 있는 IP 주소로 변환하는 역할, 모두 도메인으로의 접속이 가능하기 때문에 하나의 경로가 다운되더라도 다른 경로를 통해 접근이 가능하다.
추가적으로 해당 dns로의 접속 목적지는 현재 내가 사용하고 있는 인터넷제공자인 LG 사의 네임서버였고 출발지는 내 pc의 ip 가 아닌 홈라우터(wifi 공유기)의 ip 가 할당되어있었다.
TCP 3 - way handshake (open)
프레임 545
클라이언트 A가 서버 B에 TCP SYN 패킷을 보냄
TCP 연결을 시작하기 위함 (3-way 핸드셰이크의 첫 단계)
- 목적지 포트: 443 (HTTPS)
- 플래그: SYN
- 순서 번호: 0
- MSS: 1460 (Maximum Segment Size)
해당 연결에서 각 세그먼트가 가질 수 있는 최대 바이트 수를 정의하는 MSS 를 보내주어 패킷 손실 가능성을 줄인다.
이로 인해서 해당 포스트에 IP 단편화도 넣고 싶었지만 일어나는걸 모니터링 하지는 못했다.
https://www.ietf.org/rfc/rfc793.txt
프레임 546
서버 B가 클라이언트 A에 TCP SYN-ACK 패킷을 보냄
클라이언트의 연결 요청을 수락하고 응답을 확인하기 위함
- 출발지 포트: 443 (HTTPS)
- 목적지 포트: 50409
- 플래그: SYN, ACK
프레임 547
클라이언트 A가 서버 B에 TCP ACK 패킷을 보냄
서버의 SYN-ACK 패킷에 응답하여 3-way 핸드셰이크를 완료하기 위함
- 출발지 포트: 50409
- 목적지 포트: 443 (HTTPS)
- 플래그: ACK
TLS handshake (open)
프레임 549
클라이언트 A가 서버 B에 TLS 클라이언트 헬로 패킷을 보냄
TLS 핸드셰이크를 시작하여 보안 연결을 설정하기 위함
- 출발지 포트: 50409
- 목적지 포트: 443 (HTTPS)
- 프로토콜: TLSv1.3
- 메시지: Client Hello (SNI=www.naver.com)
프레임 551
서버 B가 클라이언트 A에 TLS 서버 헬로 및 초기 데이터 패킷을 보냄
TLS 핸드셰이크를 계속 진행하여 보안 연결을 설정하기 위함
- 출발지 포트: 443 (HTTPS)
- 목적지 포트: 50409
- 프로토콜: TLSv1.3
- 메시지: Server Hello, Change Cipher Spec, Application Data
- Change Cipher Spec란?
TLS(Transport Layer Security) 프로토콜의 일부로, 클라이언트와 서버가 암호화 설정을 변경할 준비가 되었음을 상호 통보하는 데 사용한다.
프레임 556
클라이언트 A가 서버 B에 TLS 변경 암호 사양 및 애플리케이션 데이터 패킷을 보냄
변경된 암호 사양을 통보하고 애플리케이션 데이터를 전송하기 위함
- 출발지 포트: 50409
- 목적지 포트: 443 (HTTPS)
- 프로토콜: TLSv1.3
- 메시지: Change Cipher Spec, Application Data
TCP 4-way handshake (close)
프레임 12121, 12122(재전송)
클라이언트 A가 서버 B에 TCP FIN-ACK 패킷을 보냄
TCP 연결을 종료하기 위함
- 출발지 포트: 443 (HTTPS)
- 목적지 포트: 50409
- 플래그: FIN, ACK
프레임 12123,12124(재전송),12125(재전송)
클라이언트 A가 서버 B에 TCP ACK 패킷을 보냄
서버의 FIN-ACK 패킷에 대한 응답
- 출발지 포트: 50409
- 목적지 포트: 443 (HTTPS)
- 플래그: ACK
프레임 12126
클라이언트 A가 서버 B에 TCP FIN-ACK 패킷을 보냄
클라이언트가 연결을 종료하려는 시도
- 출발지 포트: 50409
- 목적지 포트: 443 (HTTPS)
- 플래그: FIN, ACK
프레임 12127
서버 B가 클라이언트 A에 TCP ACK 패킷을 보냄
클라이언트의 FIN-ACK 패킷에 대한 응답 및 연결 종료 완료
- 출발지 포트: 443 (HTTPS)
- 목적지 포트: 50409
- 플래그: ACK
마무리
예로 들어 tcp가 닫히는 경우 4번의 요청/응답만 있을줄 알았는데 예시로 사용한 프레임 12---번대 뿐만 아니라 대부분의 과정에서 여러번의 재전송이 발생함을 알수 있었다.
대부분의 과정은 0.01초만에 이루어지는 것을 보고 상당히 빠른속도로 정보가 만들어지고 프레임으로 캡슐화가 되어서 여러 라우터를 거쳐서 다시 나에게 돌아오는게 당연하지만 눈으로 수치를 확인하니 놀라웠던것 같다.
네트워크를 공부하면서 한번쯤은 해봐야지 생각만 하다가 이제야 하게되었는데 밀린 숙제를 한 기분이다ㅋㅋ
이외에도 포스팅이 길어질까 추가를 하지 않았지만 분석해준 TCP 내부를 확인하면
실제로 ISN으로 보낸 값에 +1을 해서 이를 ACK로 돌려보내는 과정도 확인할 수 있었다.
