HTTPS & TLS handshake

사람들이 서로 악수를 하는 이유는 무엇일까요?

서로 인사를 하기 위해서입니다. 사람들은 악수를 하는 짧은 시간 내에 서로를 파악하기도 합니다.

이처럼 우리가 사용하고 있는 인터넷도, 서로 악수하는 것 처럼 통신을 주고 받습니다.

인터넷 통신을 주고 받는 주체는 “클라이언트"와 “서버”라고 부릅니다.

클라이언트에는 여러분이 네이버를 들어갈 때 사용하는 웹 브라우저인 크롬, 엗지, 파이어폭스.. 등이 있습니다.

쉽게 말해, 서비스를 받는 쪽이 클라이언트라고 생각하시면 됩니다. 네이버로 비유하면, 네이버 화면을 띄우고 있는 쪽이 클라이언트입니다.

서버에는 여러가지가 있습니다. 서비스를 제공하는 쪽이 서버 라고 생각하시면 됩니다. 네이버로 비유하자면, 네이버가 바로 서버라고 볼 수 있습니다.

그럼, 클라이언트와 서버 간에는 어떻게 통신을 하는걸까요?

저희가 네이버를 들어가서 뉴스를 본다고 가정해봅시다.

앞으로 클라이언트 = 브라우저, 서버 = 네이버 라고 하겠습니다.

뉴스를 클릭하면 우리는 바로 뉴스 화면을 볼 수 있습니다.

우리 눈에는 빠르게 뉴스 화면이 띄워지기 때문에, 아무 일이 발생하지 않는 것처럼 보입니다.

그저 클릭에 대한 응답으로 보일 뿐이죠.

하지만, 클라이언트(브라우저)와 서버(네이버) 간에는 아주 많은 일들이 발생합니다.

클라이언트가 서버의 뉴스 정보를 받아오려면,

먼저 네이버 홈 화면에 접속을 할 수 있도록 서로 연결이 되어야 하는데, 방식은 아래와 같습니다.

위와 같은 방식으로 서로 연결이 되는 것을 TCP 3 way handshake라고 합니다.

서로 악수하는 것 처럼 연결이 되어서 handshake라고 명명이 되었습니다.

1. 클라이언트가 서버로 접속 요청을 합니다.
2. 서버가 접속 요청을 승인하는 동시에, 클라이언트로의 접속 요청을 합니다.
3. 클라이언트가 접속 요청을 승인합니다.
4. 클라이언트 ↔ 서버 간 연결이 이루어지고, 데이터 통신이 시작됩니다.

자. 이제 클라이언트와 서버가 서로 연결이 되었습니다. 데이터를 주고받을 수 있는 상태가 되었습니다. 우리는 서버(네이버)에게 뉴스를 요청하고, 이를 받아볼 수 있게 되었습니다!

그런데, 뉴스와 같은 데이터는 클라이언트와 서버가 어떻게 주고받는걸까요?

연결을 한다고 다 주고받을 수 있는걸까요?

아닙니다. 여기서도 우리가 모르는 세계에서 많은 일들이 발생합니다.

클라이언트는 서버에 뉴스를 “요청" 하여 서버의 “응답"을 받아와야 뉴스를 볼 수 있습니다.

이렇게 요청을 보내고 응답을 받는 행위도 방법이 있는데, 이를 “HyperTextTransferProtocol” 즉, HTTP라고 합니다. 일종의 데이터 전송 방식입니다.

예를 들어, 우리가 네이버에서 뉴스를 보기 위해서는 https://news.naver.com/ 이라는 주소를 입력하여 들어갑니다.

우리가 브라우저에 https://news.naver.com/을 입력하고 엔터를 누르면, 서버(네이버)에 “요청"이 전송됩니다.

그러면, 서버에서는 요청에 대해 내부에서 처리를 한 후에, “응답"을 우리에게 전송해줍니다. 응답 받은 데이터는 브라우저가 렌더링을 하여 보여줍니다. (렌더링이란, 0과 1로 이루어진 데이터를, 이쁘게 만들어 사람이 보기 편하게 만들어주는 행위입니다. )

서버가 응답해준 데이터 + 브라우저가 렌더링을 해준 결과는 우리가 볼 수 있는 이 화면입니다.

응답을 해준 후엔, 연결이 끊어집니다. 우리가 만약 다른 정보를 보려고 다른걸 클릭하면, 다시 위 과정을 반복하여 응답을 해줍니다.

그런데 뭔가 이상합니다.

저는 HTTP를 설명해주고 있고, 네이버 주소에는 HTTPS라고 써져있습니다.

이 두 개의 차이는 뭘까요?

HTTP가 HTTPS보다 더 먼저 나온 개념입니다.

HTTP는 암호화가 되지 않은 평문 형태의 데이터를 전송하는 프로토콜(규칙)입니다. 하지만, HTTP는 큰 문제가 하나 있는데, 제 3자가 정보를 조회할 수도 있다는 것입니다. 암호화가 되지 않은 데이터를 주고받기 때문입니다.

만약 우리가 개인 블로그에 글을 쓰기 위해 로그인을 시도한다고 가정해봅시다.

우리는 로그인을 하기 위해 ID와 비밀번호를 입력 후, 로그인 버튼을 누릅니다. 이 때, 로그인을 하겠다는 “요청"이 우리의 ID와 비밀번호 정보를 가진 채로 서버에 전송됩니다. 이 때의 전송방식이 HTTP라면, 암호화가 되지 않은 데이터가 그대로 전송되기 때문에, 제 3자가 우리의 비밀번호 정보를 채갈 수 있습니다. 이러한 문제는 아주 큰 문제였기 때문에, 데이터 전송 방식에 대한 해결책이 필요했으며, 이에 대한 해결방안으로 나온 것이 HTTPS 입니다.

HTTPS는 HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불립니다. 이름이 다양하고 복잡하지만, 간단하게 표현하자면 HTTP에 “데이터 암호화 방식(보안)”이 추가된 전송 방식입니다. 즉, 클라이언트와 서버가 데이터를 주고받을 때, 암호화하여 제3자가 조회하기 어렵도록 만들어줍니다.

그렇다면, 암호화는 어떻게 하고 암호를 푸는 것(복호화 라고 합니다.)은 어떻게 하는 것일까요?

클라이언트와 서버 간에는 암호화 및 복호화에 대한 일종의 규칙이 있습니다.

클라이언트가 서버로 암호화한 데이터를 보내면, 서버가 이를 복호화 합니다.

반대로, 서버가 클라이언트로 암호화된 데이터를 보내면, 클라이언트가 이를 복호화 합니다.

서로 암호화 데이터를 보내고, 이를 복호화 하여 통신을 하려면 “키”가 필요합니다. 군대에서 적군이 알아듣지 못 할 암구호를 지정하여 통신하듯이, 클라이언트와 서버 사이에도 암구호와 같은 역할을 하는 “키”를 지정합니다.

데이터를 암호화하고, 암호를 해제(복호화)하는 “키”를 지정하는 방식은 두 가지가 있는데, 두 방식의 특징은 다음과 같습니다.

1. 대칭키 암호화
   

   대칭키 암호화 방식은 비교적 간단한 방식이며, 특징은 다음과 같습니다.

   • 클라이언트와 서버가 동일한 키를 사용하여 암호화 및 복호화를 진행합니다.
     • 클라이언트가 특정 키로 암호화를 해서 데이터를 송신하면
     • 서버에서 같은 키로 복호화를 해서 데이터의 암호를 풀고, 그에 대한 응답을 전송합니다.
   • 연산 속도가 빠릅니다.
   • 키가 제 3자에게 노출될 수 있기 때문에 매우 위험한 방식입니다.

2. 비대칭키 암호화

   

   비대칭키 암호화는 더 복잡한 방식입니다. 하지만, 보안성이 더 높기 때문에 로그인이 필요한 곳에서는 대부분 비대칭키 암호화 방식을 사용합니다. 특징은 다음과 같습니다.

   • 1개의 쌍으로 구성된 공개 키와 개인 키를 암호화 및 복호화 하는 데 사용합니다.

     • 공개 키 : 모두에게 공개 가능한 키

     • 개인 키 : 나만 알고있는 키

       ⇒ 암호화를 공개 키로 하는지, 개인 키로 하는지에 따라 사용 목적이 달라집니다. (그림 참고)

   • 연산 속도가 느립니다.
   • 키가 노출되어도 비교적 안전합니다.

우리는 로그인을 위한 암호화 및 복호화 방식을 알게되었습니다.

그럼, 암호화 및 복호화를 이용한 데이터 전송은 어떻게 이루어지는 것일까요?

암호화 및 복호화를 이용한 데이터 전송은 위에서 간단히 언급드렸던 HTTPS 방식으로 이루어집니다.

HTTP 데이터 전송방식과는 달리, TLS handshake라는 암호화 및 복호화 과정이 추가되며, 대칭키 암호화 방식과 비대칭키 암호화 방식 둘 다 사용합니다.

💡 참고: TLS(Transport Layer Security)란, 인터넷 통신을 위한 암호화 프로토콜입니다.

출처 : 클라우드페어

1. 먼저, 클라이언트와 서버가 TCP handshake 방식으로 서로 연결됩니다.
2. 그 후, TLS handshake 방식으로 데이터를 주고 받습니다.

그럼, TLS handshake의 자세한 원리를 알아볼까요?

TLS handshake 방식은 비대칭키 암호화와 대칭키 암호화 방식을 모두 사용합니다.

먼저, 비대칭키 암호화 방식을 이용하여 서로가 데이터를 주고 받을 수 있는 환경을 만들어줍니다.

그 후, 대칭 키 암호화 방식을 이용하여 빠르게 데이터를 주고 받습니다.

네이버를 예로 들겠습니다. (클라이언트 = 브라우저, 서버 = 네이버)

1. 우리가 브라우저에 https://www.naver.com/ 라는 네이버 주소를 입력하여 네이버에 최초로 접속을 시도합니다. (이 때, TCP handshake가 진행되고, 이후 TLS handshake가 개시됩니다.)
2. 네이버가 본인들이 가지고있는 공개 키를 우리에게 전송해줍니다.
3. 우리의 브라우저는 이 공개 키를 검사합니다.
   • 안전한지, 사용해도 되는지, 만료가 되지는 않았는지 “유효성"을 검사합니다.
4. 공개 키가 멀쩡하면, 우리의 브라우저는 “세션 키"라는 것을 만듭니다. (이를 발급한다고 표현합니다.)
5. 이 “세션 키"를 2번에서 네이버가 준 “공개 키"로 암호화 합니다.
   • 이 때, 우리의 브라우저에는 “암호화가 되지 않은 세션 키"가 저장됩니다.
6. “공개 키"로 암호화한 “암호화된 세션 키" 가 생성됩니다.
7. 이 “암호화된 세션 키"를 네이버에 전송해줍니다.
8. 네이버는 “개인 키"를 이용해서 “암호화된 세션 키"를 복호화 합니다.
9. 네이버도 우리와 같은 “암호화가 되지 않은 세션 키"를 가지게 됩니다.
10. 그 후, 브라우저와 네이버는 동일한 “암호화가 되지 않은 세션 키"를 가지고, 대칭 키 암호화 방식으로 데이터를 빠르게 주고 받습니다.

이와 같이, 우리가 네이버에서 뉴스를 보고, 로그인 해서 블로그에 글을 쓰는 등, 아주 간편하게 누릴 수 있는 서비스의 뒷단에서는 아주 복잡한 작업들이 발생합니다.

끝으로, 우리가 네이버에 접속할 때 어떤 일이 발생하는지에 대한 총 내용을 간단히 정리하고 마무리하겠습니다.

(클라이언트 = 브라우저, 서버 = 네이버)

1. 브라우저와 네이버가 TCP handshake를 통해 연결된다.

   1. 브라우저가 네이버로 접속 요청
   2. 네이버가 브라우저로 요청 수락 및 접속 요청
   3. 브라우저가 네이버로 요청 수락

   ⇒ 연결!

2. 브라우저와 네이버가 TLS handshake를 통해 통신한다

   1. 브라우저가 네이버로 TLS handshake 개시
   2. 네이버가 브라우저로 자신들이 가진 공개 키 전송
   3. 브라우저가 공개 키의 유효성을 검사
   4. 브라우저가 세션 키를 생성(발급)
   5. 네이버가 보내준 공개 키로 세션 키를 암호화 → 암호화된 세션 키 생성
   6. 암호화된 세션 키를 네이버로 전송
   7. 네이버가 자신의 개인 키로 암호화된 세션 키를 복호화 → 브라우저와 똑같은 세션 키 보유
   8. 같은 세션 키를 이용하여, 대칭 키 암호화 방식으로 데이터 교환

REFERENCE
https://mangkyu.tistory.com/98
https://coconuts.tistory.com/773
https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/
https://ansohxxn.github.io/bitcoin/cryptography/
https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/
https://www.inflearn.com/course/http-웹-네트워크