[Network]와이어 샤크를 이용한 SSL 핸드쉐이크(handhake)의 이해

이 글의 저작권은 아리밤 님에게 있습니다. 

"암호화 통신" 뭔가 할리우드 블록버스터 산업 스파이 액션 영화에서나 나올법한 단어죠

하지만 생각 외로 우리 일상생활에서 많이 사용하고 있어요. 그 대표적인 예가 https 죠

 

https 란 기존에 인터넷 방식(http)에 보안을 결합한 것이고, 오늘은 그 "보안" 이 어떻게 이루어지는지에 대해 공부할 거예요.

 

 

1. 그 "보안"이 뭔데 암호화 통신이 가능한 것일까?

 

암호화 통신은 SSL(또는 TLS)라는 프로토콜을 사용해서 세션 데이터를 암호화하는 것을 의미해요.

 

우리가 처음 만난 사람과 인사하 듯 

사용자와 웹서버가 암호화 통신을 할 땐 인사하며 어떤 암호화를 사용 할 것인지 얘기를 나누죠. 이러한 과정을 SSL Handshake라고 칭해요. 

 

번외적인 얘기로 handshake 어디서 들어본거 같지 않나요 ?

 

들어봤다면 TCP 통신 얘기 중에 나왔던 3 way handshake 가 아닐까 싶네요 ~

참고로 SSL handshake는 3 way handshake 가 끝난 뒤에 이루어지는 인사예요

(인사를 2번이나 하네요 ㅎㅎ)

 

 SSL 핸드쉐이크는 여러 단계를 거쳐 암호화 통신에 대한 협의를 진행해요

(참고로 그림에서 나눈 기준은 설명을 위함일 뿐 절대적이진 않아요)

 

 

 

그럼 실제로 이런 내용들이 어떻게 왔다갔다 하는지 확인해볼까요?

 

 

2. 무엇을 ? 어떻게? 확인할 것인가?

 

날라다니는 패킷을 손으로 잡을 수 없지요. 

그렇기 때문에 Wireshark 의 도움을 받도록 할거예요.

 

(설치 사이트: https://www.wireshark.org/download.html)

 

네이버와의 악수과정을 한번 살펴볼까요?

방법은 매우 간단합니다.

 

첫 째. Wireshark를 실행한다.

둘 째. 캡처를 시작한다

셋 째. 인터넷 브라우저를 켠다

넷 째. 네이버에 들어간다

마지막. 캡처를 끄고 패킷을 본다.

 

 

3. 캡처 한 패킷엔 어떤 내용이 있는가?

자 그럼 캡처한 결과물을 한번 볼까요?

 

 

실제 네이버에 접속하는 과정에서 캡처되는 ssl 패킷입니다.

아까 위에서 소개한 단계와 비슷한 단어들이 많이 보이죠?

비교하기 위해 함께 손가락으로 하나하나 짚어가며 세어보아요

 

 

 

<패킷캡처 내용>

 

 

 

<체크 리스트>

 

 

어 ??

 

뭔가 이상함을 느끼셨나요 ?

 

4, 6, 8 번은 없고

Finished 란 단어도 안 보이죠?

 

자, 이상함을 마음속 깊이 세기고 우선은 캡처 된 내용을 읽어볼게요

그러면 궁금증이 해결될거예요

 

 

4. 한줄한줄 어떤 의미가 들어가있을까요? 

 

(1) Client hello (클라이언트 -> 서버)

 사용자(client)가 네이버에 접속하기 위해 네이버 서버쪽에 통신을 요청하는거예요.

이 때, 클라이언트는 통신하고자 하는 TLS 버전, 자신이 지원하는 cipher 리스트, 클라이언트가 생성한 난수 정보를 보냅니다.

 

(상황극)

클라이언트는 서버가 믿을 수 있는 녀석인지 모릅니다. "서버야 너를 내가 믿어도 될까?"

 

 

 

 

 

(2) Server hello (클라이언트 <- 서버)

 인사를 받았으면 같이 인사를 해야겠지요 ? 

서버는 자신의 SSL버전, 자신이 만든 임의의 난수와 클라이언트의 cipher 리스트 중 하나의 선택하여 그 정보를 클라이언트에게 보냅니다. 

 

(상황극)

그럼 서버는 클라이언트에게 말합니다. "그럼 그럼 믿어도 되지!! 여기 나를 증명할수 있는 증명서(CA기관에서 제공해준 SSL/TSL 인증서)도 있는걸?"

 

 

 

(3) Server certificate or Server key Exchanges (클라이언트 <- 서버)

아직 안 끝났어요

서버는 거기에 더불어 자신이 갖고있는 인증서정보를 전송합니다.

 

(상황극)

클라이언트는 서버가 보내준 증명서(SSL/TSL 인증서)를 봅니다. 그리곤 이게 위조된 증명서인지 아니면 진짜 증명서인지 확인을 해봐야 합니다. 그래서 클라이언트는 CA기관에게 전화를 걸어 이 증명서가 맞는지 물어봅니다. 그럼 CA기관은 증명서가 진짜인지 판단하고 맞다면, 클라이언트에게 서버를 믿어도 된다고 알려줍니다.

 

 

 

 

(4) Certificate Request (클라이언트 <- 서버)

번외로 클라이언트랑 마찬가지로 서버 또한 클라이언트에게 너 정상적인애니 ? 라며 인증서를 요청할 수 있어요

요 단계는 선택적으로 동작하는데, 이번 과정에는 없네요 

 

 

 

(5) Server hello done (클라이언트 <- 서버)

드디어 서버의 말이 끝났습니다.

 

 

 

(6) Client Certificate (클라이언트 -> 서버)

자 이제 클라이언트가 말할 차례네요

우선은 아까 클라이언트에게 요청한 인증서. Client 인증서 없으니 할말이 없어요. 

넘어갈게요 

 

 

(7) Client key exchange (클라이언트 -> 서버)

클라이언트는 자신이 만든 난수와 서버가 만든난수를 통해 pre-master-secret를 생성합니다. 그리고 서버의 공개키를 통해 암호화 하여 서버로 전송합니다.

즉, 해당과정을 통해 실질적으로 암호화에 사용하는 대칭키가 생성됩니다.

 

(상황극)

이제 클라이언트는 서버를 완전히 신뢰할 수 있게 되었습니다. 클라이언트를 서버와 관계를 비밀리에 유지하고자 비밀친구가 되자고 합니다. 그래서 자신만의 암호(pre-master-secret)로 바탕으로 키(대칭키)를 만들어 서버에게 전달해줍니다.

 

 

 

(8) Client verify (클라이언트 -> 서버)

클라이언트 인증서의 무결성에 대해 검증하는부분인데, client 인증서 없으니 넘어갈게요 !!

 

 

(9) Change cipher spec / finished  (클라이언트 -> 서버)

클라이언트의 마지막 말은 협상 된 알고리즘과 키를 이용하고, 바로 (finished)메세지를 전송합니다.

즉, Finished 메시지가 협상된 알고리즘 및 키가 처음으로 적용되는 것이죠

 

(상황극)

서버는 클라이언트에게 키(대칭키)를 받았고, 앞으로 클라이언트와 메시지를 주고 받을때 키를 이용해서 읽어야합니다. 왜나하면 메시지는 키(대칭키)로 암호화가 되어있기 때문이죠.

 

(10) Change cipher spec / finished (클라이언트 <- 서버)

서버 또한 클라이언트의 메세지를 확인하고 동일하게 Change Cipher Specs 메시지 전송 후 (Finished)메세지를 통해 암호화 된 통신을 사용합니다.

 

 

자 이로써 SSL 핸드쉐이킹이 끝났습니다.

 

결국 SSL 핸드쉐이킹은 https:// 에 접속하는 과정입니다.

주소 치고 엔터한번 눌렀을 뿐인데 알고보니 굉장히 많은 패킷들이 왔다갔다 하고 있었죠?