TLS Handshake 좀 더 자세히 알아보기

목적: 네트워크 과정 중 TLS Handshake부분을 자세히 쉽게 설명한다. 

 

현재 브라우저가 화면을 표시하는 과정에 대한 글을 쓰고 있습니다. 

그중 https통신에 꼭 필요한 TLS 부분이 있습니다. TLS란 Transport Layer Secure의 약자로써 '전송계층보안'이라는 뜻입니다.

말 그대로 네트워크를 할 때 응용계층 아래, 전송계층 위에서 보안을 담당하는 부분입니다.

이 부분에서 보안이 된다면 데이터를 응용계층에서 보낼 때 암호화하고

받을 때는 전송계층을 통과후 응용계층에 도착하기 전에 복호화됩니다.

그래서 브라우저가 화면을 표시하는 과정1 에서 TCP handshake 가 끝나고 나서 TLS 부분이 진행되는 것 같습니다.

 

만약 https를 사용하지 않고 http통신을 하면 무슨 위험이 있을까요? 제가 은행에 비밀번호를 보내는 상황이라고 할게요.

쉽게 생각하면 해커가 총 3가지의 나쁜짓을 할 수 있습니다.

1. 데이터를 중간에 탈취해서 내 비밀번호를 몰래 본다.

2. 데이터를 중간에 탈취해서 내 비밀번호를 자기 마음대로 바꾼다.

3. 나에게 자기가 은행인 척 응답한다.

이런 상황을 방지하기 위해 https통신을 해야 합니다.

tls를 통해 클라이언트와 서버의 신원을 보증할 수 있으며,

왔다 갔다 하는 데이터를 암호화 함으로써 위의 나쁜 짓 3종세트를 방지할 수 있습니다.

 

https의 장점은 쉽게 알 수 있으니 이보다는 handsahake를 통해 무슨 일이 일어나고 어떤 방식으로 보안이 되는 건지 보겠습니다.

일단, 저도 잘은 모르지만 네트워크 보안에서 대칭키, 비대칭키(공개키, 개인키) 방식에 대해 간단히 차이점만 알아보겠습니다.

대칭키는 암호화, 복호화하는 키가 같습니다. 그래서 빠르고 쉽습니다. 하지만 암호화하는 대칭키만 탈취하면 얼마든 복호화할 수 있다는 뜻이기 때문에 보안성이 낮습니다.

비대칭키는 암호화, 복호화하는 키가 다릅니다. 그래서 느리고 어렵습니다. 하지만 암호화 키를 탈취해도 복호화는 할 수 없기 때문에 보안성이 더 좋고 안전합니다.

tls는 이 두 방식을 혼합해서 장점만 취하고 단점을 최소화합니다.

결국 목표는 '클라이언트와 서버가 대칭키로 암호화복호화'한다 는 겁니다. 대칭키의 단점인 '보안'을 '보완' 하기 위해 handshake를 합니다. 간단히 모델을 설명하자면.. 송신자가 대칭키를 수신자의 공개키로 암호화하고 이것을 수신자가 수신자의 개인키로 복호화한 후 대칭키를 get 하는 겁니다. 그러면 클라이언트가 수신자의 공개키가 내가 원한 수신자가 맞다는 것만 확신하면 되겠네요?

 

여기서 CA(Certificate Authority)의 역할이 등장합니다.

이 세상의 모든 브라우저는 CA의 공개키를 가지고 있습니다. (1번)

웹서버, 즉 우리가 유저에게 제공하고 싶은 서비스일 테니 아래로는 서비스라고 표현하겠습니다. 서비스는 https를 사용하려면 CA로부터 인증서를 발급받아야 합니다. CA에게 인증서를 받으려면 우리 서비스 정보와 서비스의 공개키를 줘야 합니다. 그러면 CA는 우리 서비스 정보를 확인하고 거기에 우리 공개키를 묶어서 자신의 개인키로 디지털서명을 합니다. 이 결과물이 인증서입니다. 이 인증서를 우리 서비스에 줍니다(2번). 클라이언트는 브라우저가 가지고 있는 CA의 공개키로 이 인증서, 즉 CA의 디지털서명으로 암호화된 인증서를 복호화할 수 있으면 상대방의 신원을 확인하게 되는 겁니다. 이것이 CA의 역할입니다.

 

그러면 handshake과정을 보면서 조금 더 자세히 이 과정을 보겠습니다.

한번 사용했던 이미지이기도 하고 단순하게 설명하기 좋아서 골라봤습니다.

tls도 버전에 따라 방식이 조금씩 다른 것 같습니다. 참고해 주세요

1. Client says hello. 클라이언트가 TLS handshake를 시작하는 첫 요청입니다. 이 시점에는 이미 TCP연결이 되어있습니다. ClientHello단계에는 브라우저가 사용가능한 TLS버전, 암호화 방식의 리스트가 포함되어 있고(나는 이런 걸 쓸 수 있으니 네가 이중에 골라봐~라는 느낌?) Client random이라는 랜덤한 스트링 데이터가 들어가 있습니다. 
2. Server hello message and certificate. ClientHello에 대한 응답으로써 클라이언트가 보냈던 메시지에서 앞으로 자신이 사용할 암호화 방식을 선택해서 보내줍니다. 그리고 서버도 랜덤한 스트링인 Server random을 보냅니다. 마지막으로 위에서 설명한 ca로부터 받은 인증서(이 시점에는 이미 인증서를 가지고 있겠죠)도 보내줍니다.
3. Authentication. 브라우저는 서버로부터 받은 인증서를 자신이 가지고 있는 CA의 공개키로 복호화합니다. 만약 제대로 복호화가 된다면 '나에게 응답한 이 서버가 내가 원했던 CA로부터 인증받은 제대로 된 상대'임을 확신할 수 있게 됩니다. 복호화가 제대로 되었으니 인증서를 만들 때 포함했던 서버의 공개키도 얻을 수 있습니다.
4. The premaster secret. 브라우저에서 premaster secret이라는 랜덤데이터를 한번 더 보내는데요, 이번에는 위 과정에서 얻은 서버의 공개키로 암호화합니다. 
5. Private key used. 서버가 이 premaster secret을 자신의 개인키로 복호화합니다.
6. Session keys created. 여기까지 완료하면 서버와 클라이언트는 각각 client random, server random, premaster secret을 가지고 있습니다. 이 세 개의 랜덤데이터를 가지고 드디어 각자 둘의 공통 대칭키를 만듭니다. 이것이 Session key입니다. 
7. Client finished. 브라우저가 모든 과정이 잘 끝났다고 알립니다.
8. Server finished. 서버도 모든 과정이 잘 끝났다고 알립니다.
9. Secure symmetric encryption achieved. 모든 핸드셰이크가 끝났고 앞으로는 session key를 사용해서 모든 데이터가 암호화됩니다. 

이렇게 핸드셰이크과정을 통해 네트워크로 서로의 대칭키는 보낸 적이 없지만 서로 같은 대칭키를 가지게 되며, CA를 통해 상대방을 확인하게 됩니다.