와이어샤크 SSL/TLS 복호화와 SSL 핸드쉐이킹

클라우드 환경에서 구현한 웹 애플리케이션은 SSL/TLS 통신을 설정해 암호화된 패킷을 주고받는다.

클라이언트가 전송하는 로그인 정보를 암호화 시켜 서버로 전송하는데, 나는 해당 패킷을 눈으로 직접 확인하고 싶어 Wireshark를 사용했다.

그러나 로그인 시 자동으로 API 호출이 일어나 수 많은 패킷 중에 원하는 패킷을 찾기가 힘들었다.
SSL 핸드쉐이킹을 확인한 후에, 다시 해당 패킷을 Wireshark에서 탐색했다.

1) 환경 변수에서 sslkey를 추가
2) 와이어샤크에서 TLS PMS filename 지정

2) 브라우저와 와이어샤크 재실행
3) 와이어샤크에서 복호화된 SSL/TLS 통신 전송 값 확인.

참고 블로그 : https://betterinvesting.tistory.com/287

SSL 핸드쉐이킹

TCP 핸드쉐이킹이 아래와 같은 순서로 SSL 핸드쉐이킹이 발생한다.

1. 클라이언트 Hello

• 클라이언트 지원 SSL/TLS 버전, 암호 알고리즘, 랜덤 무작위 바이트 문자열 전송

2. 서버 Hello

   • 클라이언트 지원 알고리즘 확인
   • 서버 SSL 인증서를 클라이언트에게 전송
   • 무작위 바이트 문자열 전송

3. 클라이언트 인증 및 예비 마스터 번호 생성

   • 서버로부터 받은 SSL 인증서를 클라이언트 내장 CA 리스트에서 검증(이때 없다면 경고 메시지를 알려준다)
     

   • 무작위 바이트 문자열로부터PMS(pre-master-secret)값을 생성

   • 서버 공개키로 PMS암호화

4. 서버는 자신의 공개키로 암호화한 PMS를 서버 개인키로 복호화 한다

   • 이로써 클라이언트, 서버는 동일한 PMS를 보유하게 된다.

5. 클라이언트와 서버는 PMS로 Master Secret 값을 생성하며 다시 이로써 Session Key를 생성한다. (대칭키)
   
   위 사진은 ssl key log 파일에서 Session Key 파생된 키와 트래픽 키이다.

6. 이제 클라이언트와 서버는 동일한 대칭키(세션 키)로 인해 암호화 된 메시지를 사용 가능하다. 여기까지가 SSL 핸드쉐이킹단계이다.

결과적으로 클라이언트와 서버간의 대칭키를 이용하기 위해 CA기관에 SSL인증서를 등록함을 알 수 있다.

대칭키를 생성시키지 않고, 매 전송마다 CA기관에 SSL인증서를 조회 및 비교해 대칭키를 사용하는 것은 비 효율적인 방식이다.