앵하니의 더 나은 보안
TLS 1.3 본문
서론
HTTPS(SSL/TLS)-세션-성립-과정을 통해 HTTPS 세션이 어떻게 맺어지는지, 어떻게 핸드쉐이킹을 하는지 대략적으로 알아봤다. 근데, 막상 와이어샤크로 HTTPS 핸드쉐이킹 과정의 패킷을 잡으려니 Client Hello, Server Hello 이후 Certificate 과정부터는 볼 수가 없었다.
그래서 왜 이와 같은 문제가 생기는지 확인하고, 어떻게해야 Certificate 패킷을 확인할 수 있는지 한번 알아보겠다.
본론
TLS 1.3
결론부터 말하자면 Certificate 과정을 와이어샤크에서 확인할 수 없는 이유는, TLS 1.3 통신때문이다.
TLS 1.3부터는 Client Hello, Server Hello 이후의 모든 패킷은 암호화되어, 와이어샤크에서 Application Data로 밖에 확인이 안된단다.
근데 TLS 1.3부터는 암호화때문에 Certificate 과정을 평문으로 확인 불가
Client Hello, Server Hello 과정에서의 키교환은 도대체 언제?
단순히 Client Hello, Server Hello만 했을 뿐인데 대체 언제 암호화에 사용할 키를 교환한걸까??
그 답은 바로 Deffi Hellman 키 교환/합의 알고리즘에 있다.
Deffi Hellman 키 교환은 서로 키를 직접적으로 교환하지 않고, 키를 만들 수 있는 재료를 교환함으로써 재료가 외부에 노출되더라도 제 3자는 키를 만들어 낼 수 없는 방식으로 키를 생성해 낸다.
그러니까 Client Hello와 Server Hello 과정 동안 키교환에 사용되는 재료들을 교환하는거다.
직접 Deffi Hellman의 기술적/수학적 원리를 설명하면 우리같은 일반인은 어지럽기때문에, 간단히 원리정도만 설명하겠다.(그래도 궁금하다면 여기 참고)
일단 위 그림에서 앨리스와 밥의 최종 목표는 안전하지 않은 통신으로 공통의 색(공통의 키)을 만드는 것이다. 색의 혼합이 발생하면, 혼합된 색은 혼합 전에 사용했던 원래의 색 두개로 분리하는 것은 어렵다는 것을 인지하고 위 과정을 이해해보자.
- 우선 앨리스와 밥은 이번 통신에 사용할 기저 색을 공개적으로 정한다.(위 그림에서는 노란색)
- 그 후 앨리스는 빨간색, 밥은 청록색을 비밀 색으로 정하곤 둘 다 직접 비밀 색을 전송하지 않고, 기저 색인 노란색과 각자의 비밀 색을 섞은 결과인 오렌지색과 파란색을 전송한다.
- 앨리스와 밥은 각자 받은 것을 자신의 비밀 색과 섞으면 공통의 색을 만들 수 있다. 하지만 외부에서 스니핑중인 이브는 기저 색과 주황색, 파란색을 가지고도 공통의 색을 만들어낼 수 없다.
- 이브가 훗날 어느 쪽이든 비밀 색을 알아내면 공통 색을 만들 수 있기 때문에, 앨리스와 밥은 더는 필요 없는 비밀 색인 빨간색과 청록색을 버린다.
이 과정을 통해 서버와 클라이언트는 키를 교환하는것이 아닌, 각자 키를 생성해 통신에 사용한다.
그래서 키교환 없이, 키 재료 교환만으로 암호화 통신이 가능해진다.
TLS 1.3에서의 Certificate 확인
그럼 TLS 1.3 통신에서의 Certificate 과정은 어떻게해야 볼 수 있을까?
클라이언트와 서버가 생성한 키를 와이어샤크에 밀어 넣어서 암호화 내용을 복호화 시켜 패킷을 알아볼 수 있게해야한다.
그러기 위해선 HTTPS에 사용한 대칭키를 먼저 획득해야하는데, 획득하는 방법은 아래와 같다.
1. 환경 변수 설정 진입
2. 시스템 변수 새로 만들기
3. 변수 이름으로 SSLKEYLOGFILE 입력, 경로는 바탕화면의 임의의 파일명으로 설정(경로는 어디든 상관없다.) 후 확인
4. 켜져있는 브라우저 모두 종료 후 다시 실행, https를 사용하는 사이트에 접근해 sslkey.log파일 생성
5. 와이어샤크에서 Edit > Preferences 진입
6. Preferences에서 protocol > TLS로 진입, (Pre)-Master-Secret log filename 파일 설정
7. 생성했던 sslkey.log 파일로 설정
8. 이후 발생하는 HTTPS 관련 패킷 복호화된 상태로 확인 가능
단, 위 키 로그 파일은 SSLKEYLOGFILE환경 변수가 설정되어 있는 Google Chrome, Firefox 및 Opera 브라우저에 의해서만 생성되고, SSLKEYLOGFILE세션 키에 대해서는 RSA 및 DH 키 형식만 지원된다고 한다.
그래 어쩐지 옛날에 HTS SSL 통신하는거 복호화할려고 똑같이했었는데 안되더라
결론
갓피헬만; 갓갓 tls 1.3;
참고
https://datatracker.ietf.org/doc/html/rfc8446#page-11
https://eunhyee.tistory.com/205
https://livvy.byb.kr/posts/hello-tls-1-3/
'보안 기술 > WEB' 카테고리의 다른 글
| CSRF 취약점의 현태 (0) | 2024.05.10 |
|---|---|
| REST API 환경 웹 서버에서의 기존 취약점 탐구 (1) | 2024.02.06 |
| restAPI 환경에서 XSS는 왜 동작하지 않는걸까? (0) | 2023.11.05 |
| HTTP 보안헤더 (0) | 2023.10.12 |
| HTTPS(SSL/TLS) 세션 성립 과정 (0) | 2023.10.08 |
