[패킷분석] http 웹통신과 tls 암호통신 / 3way-HandShake / Transport Layer Security / TLS HandShake

 

Wireshark를 활용한 네트워크 패킷 분석 실습: HTTP와 TLS 통신 이해

 

네트워크 보안과 트래픽 분석을 배우기 위해 Wireshark를 활용해서 HTTP 요청/응답과 TLS 암호화 통신 과정을 실습해 봤다. 사이트 접속 시 발생하는 다양한 패킷을 캡처하고 분석한 과정을 정리한다.

---

1. 실습 개요

• 목적: 웹사이트 접속 시 발생하는 네트워크 패킷을 Wireshark로 캡처하고, HTTP 요청/응답과 TLS 통신의 구조를 이해하는 것.
• 도구: Wireshark
• 분석 대상: gms.ahnlab.com에 대한 HTTP 및 TLS 트래픽

---

2. 실습 과정

1) Wireshark로 패킷 캡처

1. Wireshark를 실행한 후, 인터넷 연결이 이루어지는 네트워크 인터페이스 중 이더넷 선택.
2. 상단의 Start 버튼을 눌러 패킷 캡처를 시작했다.
3. Ahnlab Safe Transaction이라는 보안프로그램이 안랩 서버(LG)와 http접속을 통한 분석
4. 하나은행(39.112.118.89) https 접속을 통한 tls 분석.

---

2) HTTP 트래픽 분석

1. 필터창에 http와 tls를 입력해 HTTP 및 tls 트래픽만 남도록 필터링했다.

1.  GET 요청이 포함된 패킷을 확인했는데, 요청 URI와 Host가 아래와 같이 나타났다.

• Request URI: /jk?... (일부 리소스 요청 경로)
• Host: gms.ahnlab.com >> Ahnlab Safe Transaction 프로그램이 깔려있는데 웹에 접속할 때 이 보안 프로그램도 같이 통신을 하는 듯하다.

PC가 211.115.106.206(안랩 서버 = gms.ahnlab.com/jk...)에게 연결 요청을 하는 상황이다.

 

2. 서버 응답 패킷에서는 HTTP 상태 코드 200 OK가 반환된 것을 확인했다.

• 이는 클라이언트가 서버에 정상적으로 접속했고, 요청에 성공적으로 응답했음을 의미한다.

---

3) TLS 트래픽 분석

 

 

패킷 분석에 앞서 TLS 핸드셰이크에 대해서 알아보도록 하자.

 

 

TLS HandShake먼저 3-way HandShake가 진행된다.

이유는 TLS 핸드셰이크에 앞서 클라이언트와 서버가 신뢰성 있는 연결을 보장해야 하기 때문에 TCP연결을

먼저 시도한다. 길을 내주는 작업이라고 생각하면 편할 것 같다.

 

3-Way HandShake

 

출처 : https://www.encryptionconsulting.com/what-is-a-tls-handshake-and-how-does-it-work/

• 1. 클라이언트가 서버에 연결 요청을 보냄 (SYN: Synchronize)
  • 클라이언트는 자신이 데이터를 보내고 싶다는 요청과 함께 초기 순서 번호(Sequence Number)를 포함한           SYN 패킷을 서버로 전송.
• 2. 서버가 클라이언트로부터 SYN 패킷을 받았음을 확인하고,                                                                                              연결을 승인한다는 응답을 보냄 (SYN-ACK: Synchronize-Acknowledge)
  • 서버는 클라이언트의 요청을 확인했다는 의미로 SYN-ACK 패킷을 보냄.
  • 이 패킷에는 서버의 초기 순서 번호와 함께 클라이언트의 요청(SYN)에 대한 응답이 포함됨.
• 3. 클라이언트가 서버의 응답(SYN-ACK)을 확인하고 최종 ACK 패킷을 보냄 (ACK: Acknowledge)
  • 클라이언트는 서버로부터 SYN-ACK 패킷을 받았음을 확인하고, 이제 연결이 설정되었음을 의미하는                 ACK 패킷을 전송.
  • 이 단계가 완료되면, 클라이언트와 서버 간의 TCP 연결이 성공적으로 설정됨.

 

TLS(Transport Layer Security) HandShake

 

• 1. Client Hello - 클라이언트가 서버에 연결 요청을 한다.
  • 클라이언트가 지원하는 TLS 버전(TLS 1.2, 1.3 등)을 포함.
  • 사용 가능한 암호 스위트(Cipher Suites) 목록을 제안.
  • 서버 이름(SNI: Server Name Indication)을 명시해 어떤 서버와 통신하려는지 알림.
  • 세션 키 생성을 위한 랜덤 데이터(Random Value)를 포함.

 

 

• 2. Server Hello - 서버가 클라이언트의 요청을 수락하고, 세션 설정에 필요한 정보를 회신한다.
  
  • 클라이언트가 제안한 암호 스위트(암호화 방식) 중 하나를 선택.
  • TLS 버전을 확정.
  • 세션 키 생성을 위한 랜덤 데이터(Random Value)를 추가로 제공.
  • 서버 인증서를 클라이언트에게 전달. << Certificate (공개 키 값 포함)
    • 클라이언트는 이를 통해 서버의 신뢰성을 확인합니다(CA 서명 확인).
  • Server Hello Done(Server Hello 완료)

 

 

• 3. Client Key Exchange - 특정 알고리즘을 통하여 Premaster Secret값을 전송하거나 이 값을 생성하기 위해 필요한 값들을 이 메세지에 담아서 보낸다.
  
  • RSA 방식은 클라이언트가 직접  Premaster Secret 값을 생성해서 Client Key Exchange 메세지에 담아 보내는     형태.
  • Diffie-Hellman 방식은 클라이언트와 서버가 각각 비밀 값을 가지며 또 각각 공개 키를 가지는데 Client Key Exchange를 통해 서로 교환하여, 교환한 공개 키와 비밀 값을 이용해 동일한 Premaster Secret값을 생성해낸다.

 

 

• 4. Change Cipher Spec(Client -> Server)
  • 앞서 획득한 Premaster Secret, 클라이언트 난수, 서버 난수를 통해 세션 키(Session Key)를 생성한다.
  • Change Cipher Spec 메세지를 서버로 보낸다("다음부터는 암호화된 데이터를 사용하겠다")
  • 클라이언트는 지금까지 진행된 핸드셰이크 과정을 해싱한 값을 계산한다.
    • 해싱된 값은 HandShake Hash로 불리며, 이전 단계(Client Hello, Server Hello 등)를 모두 포함한다.
  • 이 해싱된 값을 세션 키를 사용해 암호화하여 Finished 메시지로 서버에 전송한다.

 

 

• 5. Change Cipher Spec(Server -> Client)
  • 서버는 Premaster Secret, 클라이언트 난수, 서버 난수를 사용해 동일한 세션 키(Session Key)를 생성한다.
  • 클라이언트로부터 Change Cipher Spec 메시지를 받으면, 서버도 Change Cipher Spec 메시지를 클라이언트에게 보낸다.
    • 서버도 "이제부터 암호화된 데이터를 사용하겠다"고 선언한다.

 

*해싱 : 핸드셰이크의 무결성을 검증하기 위해 핸드셰이크 과정에서 주고받은 모든메시지(Client Hello, Server Hello 등)을 특정 해시 함수를 사용해 요약한 값이다. 이 해싱 값을 Finished 메시지를 통해 암호화 시켜서 전송한다. 이후 받은 Finished 메시지를 통해 복호화 시켜 자신의 계산 값과 비교한다. 값이 일치하지 않을 시 핸드셰이크는 실패한다.

 

 

• 6. Finished
  • 서버도 동일하게 핸드셰이크 과정을 해싱한 값을 계산한다.
  • 클라이언트로부터 받은 Finished 메시지를 복호화하여 해싱 값이 일치하는지 확인한다.

 

---

 

Client Hello는 클라이언트(TLS를 시작하려는 쪽, 보통 브라우저나 프로그램)가 서버에 핸드셰이크 요청을 보내는 첫 번째 단계 

 

여기서 클라이언트는 자신이 지원하는 암호화 방식(암호 스위트) 목록을 서버에 제공한다.

 

암호 스위트란?

암호 스위트는 TLS 통신에서 사용할 암호화 알고리즘들의 조합을 나타냄. 하나의 암호 스위트는 보통 다음 요소들로 구성됨.

1. 키 교환 알고리즘: 클라이언트와 서버가 세션 키를 안전하게 교환하기 위한 방법.
   • 예: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
2. 대칭 암호화 알고리즘: 데이터 암호화에 사용.
   • 예: AES (Advanced Encryption Standard)
3. 메시지 인증 코드(MAC) 알고리즘: 데이터 무결성을 확인.
   • 예: SHA256, SHA384

 

 

 

1. 클라이언트와 서버 간 Client Hello와 Server Hello 패킷이 교환되었고, 서버가 인증서를 제공한 것을 확인했다.
2. 이후, 데이터가 암호화되어 Application Data로 전송된 것을 확인했다.
   • 이는 TLS 세션이 성공적으로 설정되었고, HTTPS 통신이 암호화된 상태로 진행되었음을 보여준다.

 

Server Hello는 서버가 클라이언트의 Client Hello 요청에 응답하는 단계이다.

클라이언트가 제안한 암호 스위트 중 하나를 선택하고, 이를 명시하여 핸드셰이크 과정을 계속 진행한다.

 

Server Hello에서 확인할 수 있는 정보

• 선택된 암호 스위트: 서버가 클라이언트의 목록 중 하나를 선택함.
  • 예: TLS_AES_128_GCM_SHA256 (128비트 AES 대칭 암호화 + GCM 모드 + SHA256 해시)
• TLS 버전: 서버가 사용할 TLS 버전을 명시함.
  • 예: TLSv1.3, TLSv1.2 등.  (프로토콜란에 적혀있는 것을 볼 수 있다.)

 

그리고 Server Hello 옆에 Change Cipher Spec이라고 적혀있는데 

클라이언트와 서버가 암호화 방식을 설정하고, 세션 키를 바탕으로 암호화 준비를 완료한다는 의미이다.

 

 

 

---

 

3. 분석 결과

이번 실습을 통해 다음과 같은 내용을 확인할 수 있었다:

1. 클라이언트는 HTTP GET 요청을 통해 gms.ahnlab.com 서버와 정상적으로 통신을 완료했다.
2. TLS 핸드셰이크 과정을 통해 클라이언트와 서버 간 암호화된 통신 세션이 성공적으로 설정되었다.
3. 이후, 서버도 동일한 방법으로 Finished 메시지를 클라이언트에 보다.

 

 

 

---

 

 

4. 후기?

 

1. 아 TLS HandShake에서 'Client Key Exchange' 메세지를 전송할 때 'Premaster Secret'값의 생성에 대한 이해를 하는데 굉장히 오랜 시간이 들었다. 물론 지금도 완벽하게 이해하지는 못했지만... 

 

2. 많은 패킷들이 있었는데 일단 특정 부분만 알아봤다.

아직 와이어샤크 사용에 능숙하지 않아서 분석이 어려운 것 같다.

 

 

 

 

 

★ 혹시 틀린정보가 있다면 꼭 정정 댓글 달아주시면 감사하겠습니다!