개발을 하다 보면 client와 serve간의 패킷을 캡쳐할 일이 종종 있다. 보안을 위해 대부분 HTTPS 통신을 하는데 나는 보통 Fiddler를 이용한다. 왜? Fiddler는 SSL 복호화 키를 따로 설정하지 않아도 되거든. wireshark에서 https 패킷을 복호화 하기 위해서는 SSL 키를 따로 설정해줘야 하며 일반적인 상황에서 Fiddler 는 설정없어도 HTTPS 트래픽을 복호화 할 수 있다. 왜? 무엇이 다른 걸까? 이 둘의 동작원리에 대해 알아보자. wireshark의 패킷 캡쳐 원리는 패킷 스니핑이다. NIC(네트워크 인터페이스 카드)에 들어오는 패킷을 수집하는데, HTTPS 패킷은 이미 암호화 되어있으므로 따로 복호화 할 수 있는 key를 설정해야 하는 것.  Client Hello : 클라이언트측에서 생성한 랜덤 데이터, 클라이언트가 지원하는 암호화 방식들(chipher suites), 세션 ID 등 포함한 패킷을 Client -> Server로 전송한다.
Sever Hello : 서버측에서 생성한 랜덤 데이터, 서버가 선택한 클라이언트의 암호화 방식(chipher suites) 등 포함한 패킷을 Server -> Client로 전송한다. - 세션 ID를 통해 재연결 세션인지 신규 세션인지도 확인한다. Certificate : SSL 인증서(선택된 인증/해쉬 알고리즘 CA 비공개키로 암호화, 브라우저의 CA 공개키로 복호화할 경우 전자 서명)를 세션키로 암호화한 패킷을 Server -> Client로 전송한다.
Server Key Exchange/Server Hello Done : 서버 공개키 포함한 패킷을 Server -> Client로 전송한다. (서버 공개키는 Ceritificate에 포함되기도 하고 포함되지 않을 수도 있음)
Client Key Exchange/Change Cipher Spec/Encryted Handshake Message : 클라이언트 공개키를 포함한 패킷을 Client -> Server로 전송한다. 여기서는 어떤 키 교환 알고리즘을 사용했느냐에 따라서 세션키를 생성하는 과정이 조금 다릅니다 🤔 (일반적으로는 DHE 알고리즘을 사용할 경우 Params(재료)를 보내어 Client/Server가 동일한 Params로 세션키를 생성합니다) - 키 교환 알고리즘 방식으로 클라이언트 공개키 + 서버 비공개키 = 클라이언트 비공개키 + 서버 공개키 = 세션키를 생성한다.
Change Cipher Spec/Encryted Handshake Message : 세션키를 대칭키로 사용할 것을 정의하여 Server -> Client로 전송한다.
https://eunhyee.tistory.com/199
HTTP and TLS(SSL) 1. HTTP vs HTTPS - HTTP(Hypertext Transfer Protocol) : 전송중 암호화 X, 80 Port - HTTPS(HTTP Secure) : 전송중 암호화 O, 443 Port - 해커가 HTTP 패킷을 갈취하게 될 경우 평문의 정보들이 보이지만 HTTPS.. eunhyee.tistory.com
④ Application Data Application Data : 결정된 암호화 알고리즘으로 데이터를 세션키를 대칭키로 암호화하여 Client -> Server로 전달한다.
2. TLS 1.3① DNS를 통하여 URL으로 IP 확인
② TCP Handshaking(1 Round Trip Time) - 3 Way Hanshaking
③ TLS Handshaking(1 Round Trip Time) - 2 Round Trip Time이 1 Round Trip Time으로 바뀌면서 패킷에 포함되는 정보가 많아짐
Client Hello : 클라이언트 공개키들(extension : key share), 클라이언트가 지원하는 인증/해쉬 알고리즘 방식들(extension : signature algorithms), 클라이언트가 지원하는 암호화 방식들(chipher suites), 세션 ID 등 포함한 패킷을 Client -> Server로 전송한다. - TLS 1.3은 가능한 인증/해쉬 알고리즘 리스트들을 extension : signature algorithms에 보낸다. - TLS 1.3은 키 교환 알고리즘으로 PSK(Pre Shared Key)와 (EC)DHE만 사용 가능하기 때문에 키 교환 알고리즘 협상 없이 Client Hello의 extension : key share에 (EC)DHE keys을 모두 함께 보낸다. - PSK에 대한 정보를 extension : pre shared key, psk key exchange modes에 보내어 TLS 1.3을 맺을 경우 다음 통신에서는 0 Round Trip Time로 통신 가능하다. - Extension은 TLS 1.3을 위한 필드로 TLS 1.2의 경우 무시한다. - TLS 1.3인데 Version에 1.2가 나오는 이유는?! Server Hello/Change Cipher Spec : 서버가 선택한 클라이언트의 암호화 방식(chipher suites), 서버 비공개키(extension : key share)등 포함한 패킷을 Server -> Client로 전송한다. - 세션 ID를 통해 재연결 세션인지 신규 세션인지도 확인한다. - 키 교환 알고리즘 방식으로 클라이언트 공개키 + 서버 비공개키 = 클라이언트 비공개키 + 서버 공개키 = 세션키를 생성한다. Application Data(Certificate) : SSL 인증서(선택된 인증/해쉬 알고리즘 CA 비공개키로 암호화, 브라우저의 CA 공개키로 복호화할 경우 전자 서명)를 세션키로 암호화한 패킷을 Server -> Client로 전송한다.
④ Application Data Change Cipher Spec/Application Data : 결정된 암호화 알고리즘으로 데이터를 세션키를 대칭키로 암호화하여 Client -> Server로 전달한다. - 브라우저의 CA 공개키로 SSL 인증서(선택된 인증/해쉬 알고리즘 CA 비공개키로 암호화)를 복호화 후 SSL 인증서를 신뢰한다.(전자서명) - 키 교환 알고리즘 방식으로 클라이언트 공개키 + 서버 비공개키 = 클라이언트 비공개키 + 서버 공개키 = 세션키를 생성한다.
3. TLS 1.3 의 장점보안 강화 - 다운그레이드 공격(Handshake 단계에서 암호화 알고리즘 및 SSL/TLS 버전 등을 협상하는 과정에 공격자가 개입하여 협상 내용을 보안에 취약한 것으로 변경하는 방식) 방어가 가능 - 취약한 알고리즘 지원 중단
성능 강화 - TLS 1.2 - 2 Round Trip Time > 1 Round Trip Time으로 줄어들게 되며 통신 속도가 빨라짐 - TLS 1.3 - 0 Round Trip Time를 적용하게 되면 HTTP와 통신 속도가 동일해짐
프라이버시 강화 - SNI 필드 암호화 가능(Encrypted Server Name Indication) - TCP Handshaking 과정에서 Client Hello의 SNI는 TLS Handshaking 과정 전이라 암호화할 수 없는데 암호화를 가능하게 하여 사용자가 어떤 도메인으로 접속하는지도 알 수 없게 됨
4. Cipher SuiteTLS_{키 교환 알고리즘}_{인증 알고리즘}_WITH_{암호화 알고리즘}_{해쉬 알고리즘}
- 키 교환 알고리즘 : Client/Server Key Exchange에 사용하는 알고리즘 - 인증 알고리즘(비대칭키 암호화) : Certificate에 사용되는 알고리즘 - 암호화 알고리즘(대칭키 암호화) : 세션키에 사용하는 알고리즘 - 해쉬 알고리즘 : Certificate 무결성 검증에 사용되는 알고리즘
- TLS 1.3에서는 Client Hello에 extension : key share로 (EC)DHE의 키 값을 사전에 전달, extension : signature algorithms로 사용 가능한 인증/해쉬 알고리즘 전달하여 TLS 1.3 Cipher Suite는 TLS_{암호화 알고리즘}_{해쉬 알고리즘}로 나타냅니다. - TLS 1.3 Cipher Suite List : TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, TLS_AES_128_CCM_8_SHA256
참고 : https://blog.naver.com/n_privacy/221412043898
SSL/TLS 알아보기 – TLS 1.3과 프라이버시 SSL/TLS는 네트워크 통신 시 데이터 암호화를 제공하는 프로토콜입니다. 1995년에 Netscape사에서 ... blog.naver.com https://msm8994.tistory.com/38
SNI 차단이 뭐야? TLS 1.3은 해결책이 될 수 있을까. 지난 5월 정부는 통신사와 함께 저작권 침해 사이트를 차단하기 위해 DNS 단계에서 해당 웹사이트의 서버 주소를 변조하는 차단을 시행했습니다. 사람들은 검열이라는 양날의 칼에 대해 중국처 msm8994.tistory.com https://aws-hyoh.tistory.com/entry/HTTPS-%ED%86%B5%EC%8B%A0%EA%B3%BC%EC%A0%95-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3SSL-Handshake?category=768734
HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상) 고대 그리스에서는 타인에게 노출되어서는 안 될 중요한 정보를 보낼 때, 전달하는 이(사자)의 머리를 빡빡 깎아서 중요한 정보를 적은 후 머리가 자라서 글이 보이지 않으면 그제야 상대방에게 aws-hyoh.tistory.com https://blog.devgenius.io/added-security-measures-and-changes-in-tls-1-3-fd93bbfecb8f
Added Security Measures and Changes in TLS 1.3 A look at the newer version of TLS protocol and updates to its predecessor blog.devgenius.io https://cabulous.medium.com/tls-1-2-andtls-1-3-handshake-walkthrough-4cfd0a798164
TLS 1.2 andTLS 1.3 Handshake Walkthrough The ultimate goal of the TLS handshake is safely exchanging the master secret for future secure communication. |
HTTPS 패킷 캡쳐 - HTTPS paekis kaebchyeo
저작권 © 2024 nguoilontuoi Inc.
