끝까지 파보는 HTTPS

HTTPS 누구냐 넌!

HTTPS == HTTP + SECURE

말 그대로, HTTPS는 보안이 되는 HTTP 프로토콜이다.

(영문으로, HyperText Transfer Protocol Secured)

 

HTTPS가 생긴 것을 보면 기존 HTTP는 보안이 취약했는가?

 

맞다.

 

기존의 HTTP 프로토콜 예하에서 진행된 통신들은 보안 측면에서 문제가 있었기 때문에 이것을 보완하기 위해서 HTTPS 프로토콜이 만들어졌다.

 

그렇다면 HTTPS 프로토콜은 어떤 장점들이 있을까?

---

HTTPS 프로토콜이 필요한 이유 3가지

1. 개인정보를 보호받을 수 있다.

   - 개인정보가 보호받을 수 없으면, 내가 서버로 보내는 내용을 누군가가 가로채서 읽을 수 있다.

   - 네트워크단에서 내가 보내는 HTTP패킷을 누군가가 읽을 수 있는 위험으로부터 안전하다.

 

2. 무결성이 유지된다.

   - 누군가가 내 패킷을 가로챌 수 없기 때문에, 내가 보내는 패킷이 변형되지 않음을 보장받는다.

   - 내 Client와 서버간의 통신이 변형되지 않는다.

 

3. 서버를 식별할 수 있다.

   - 내가 제대로 된 사람과 통신하고 있는 것인지 확인할 수 있다.

   - 메시지에 포함되어있는 TLS(구 : SSL)을 통해 해당 사이트가 내가 의도한 곳이 맞음을 보장받는다.

 

이런 3가지 이유로 HTTPS는 선택이 아닌 필수가 되었다.

(HTTPS가 대중화 된 이유는 브라우저가 HTTP사이트 들어가면 경고를 보내서 그렇다)

 

그러면 이제 어떻게 HTTPS는 HTTP와 다르게 이런 장점을 가질 수 있었는지 알아보자

---

암호화 매커니즘 2가지

들어가기에 앞서, HTTPS가 사용하는 암호화 메커니즘 2가지를 알아보고 가자.

2 매커니즘은 각각 대칭키 암호화 그리고 비대칭키 암호화라고 불린다. 

 

대칭키 암호화

내용을 특정한 키를 통해 암호화한다. 이렇게 암호화된 내용은 동일한 키로만 열 수 있다.

 

이 대칭키 암호화는 발신자와 수신자가 동일한 키를 가지고 있어야 내용을 통신할 수 있다. 이 방법은 이 특정한 키를 공유할 때 문제가 발생한다. 키를 보내는 과정은 암호화하기 힘들기 때문에, 그 과정에서 키를 탈취당하게 되면 암호화된 내용을 제삼자가 읽을 수 있기 때문이다.

 

비대칭키 암호화

대칭키는 키를 공유할 때 너무나도 위험하기 때문에 똑똑한 사람들은 비대칭키 암호화라는 방법을 만들어넀다.

 

이 방법에서 키는 2가지가 있는데 하나는 공개키(Public Key) 나머지는 개인키(Private Key)이다. 공개키는 내용을 암호화하는 것에 사용되며, 특정 공개키로 암호화된 내용은 짝이 되는 개인키로만 복호화가 가능하다.

 

이 중에 공개키는 공유해도 되지만, 개인키만은 공유하면 안 되는 내용이다. 비대칭키 암호화 방식은 발신자에게 공개키를 제공, 내용을 공개키로 암호화하도록 한다. 이후, 수신자는 개인키로 해당 내용을 복호화 해서 통신을 진행한다.

 

이렇게 되면 한 쌍의 일방향 통신밖에 안되는 것이라 너무 비효율적이지 않냐고 생각하는 사람도 있을 것이다. 조금만 기다리시라 HTTPS는 이 두 암호화 기법을 이용하여 매우 효율적인 신뢰구조를 만들어냈다.

---

핸드쉐이크!

이제 위에서 본 두 암호화 메커니즘을 사용하는 방법을 보여주겠다.

서버와 브라우저 간에 신뢰가 구축하는 과정을 우리는 핸드쉐이크라고 부른다.  그 과정을 한번 찬찬히 살펴 가보자

 

1. 웹 브라우저는 서버에게 자신이 가지고 있는 SSL 그리고 TLS 버전과 암호화 알고리즘 목록을 보낸다.

 

2. 서버는 브라우저가 보낸 SSL, TLS 버전과 암호화 알고리즘 중 서버의 선호에 맞는 녀석을 선택한다. 그리고 그에 맞춰 서버가 가지고 있는 공개키와 인증서(SSL 혹은 TLS)를 보낸다.

 

3. 웹 브라우저는 서버가 보낸 인증서가 믿을만한지 확인한다. 만약, 서버가 보낸 인증서가 믿을 수 있는 종류라면 브라우저는 PreMaster Key를 생성한 후 서버가 보낸 공개키로 이를 암호화한다.

 

4. 서버는 클라이언트가 보낸 PreMaster Key를 개인 키를 이용하여 복고화한다.

 

이렇게 함으로써! 서버와 웹 브라우저는 동일한 키를 안전하게 소유할 수 있게 되었다. 이제부터 진행되는 통신은 이 대칭키를 기반으로 암호화될 예정이다! 이렇게 함으로써, 서버와 브라우저 간 쌍방향 소통을 편안하게 실시할 수 있게 된다.

---

SSL? TLS?

위의 과정은 정말 신기하지 않은가?

비대칭 방식을 이용하여 대칭키 암호화 방식을 가능하게 하는 HTTPS 프로토콜 방식은 정말 명석한 방법이라고 생각된다.

 

그런데, 계속 나오는 저 SSL 혹은 TLS은 도대체 뭐하는 녀석들일까?

 

SSL TLS 둘 다 보안을 위해 태어난 프로토콜이며 꼭 HTTPS이 아닌 다른 프로토콜에서도 사용할 수 있는 녀석들이다. 이렇게만 말하면 이 녀석들이 왜 생겨났는지 잘 이해할 수 없으니까, 이 둘을 태어난 순으로 한번 살펴보자

 

SSL의 시작

SSL이 세상에 공개된 것은 1995년 2.0 버전부터이다. 1.0은 만들어졌으나 보안적인 문제 때문에 세상에 공개되지 않고 업데이트되어버렸다. 이 SSL들은 넷스케이프 1.1 브라우저에 탑재되면서 세상에 알려졌는데, 이 인증서는 해당 존재가 믿을만한지를 알기 위해서 제작되었다.

 

인증서의 3가지 종류

인증서는 총 3가지 종류로 이루어져 있는데, 각각은 보장하는 범주에서만 차이를 보인다.

첫 번째 인증서는 도메인만 확인하는 인증서이다. 이 인증서는 해당 도메인을 소유하고 있는 존재가 맞는지만 확인한다.

두 번째 인증서는 도메인을 확인한 후 실제로 해당 사이트를 운영하는 조직이 있는지 확인한다.

마지막 인증서는 앞의 인증서가 한 인증을 진행한 후 해당 사업의 비즈니스까지 확인하는 인증서이다.

 

이 인증서를 가지고 있고, 보내는 사이트는 제대로 된 녀석이라는 것을 따로 말하지 않아도 인증받을 수 있다.

 

그러면 TLS는 무엇인가?

TLS는 SSL의 새로운 이름이다. SSL을 만들어낸 넷 스케이프는 3.0 버전을 마지막으로 ITEF로 SSL 프로토콜 제어권을 남겼는데, 제어권을 넘겨받은 ITEF는 SSL의 이름을 TLS로 변경했다. 이렇게 이름을 변경했지만, 모든 사람의 기억에서 바꿀 수는 없는 법. 아직도 SSL이라고 기억하는 사람들이 많아 현재까지도 TLS와 SSL는 같이 사용되고 있다.

 

TLS의 역사

TLS는 1999년 발표된 이후, 2006년 1.1 버전 그리고 2008년에 1.2 버전이 배포되었다. 하지만, 2013년이 되어서야 브라우저들이 1.2 버전을 적용하기 시작했고, 현재는 2018년에 발표된 1.3 버전이 최신 버전으로 사용되고 있다.

 

TLS는 위에서도 밝혔듯, 꼭 HTTPS 프로토콜뿐만 아니라 FTP, SMTP와 같은 다른 프로토콜에서도 적용할 수 있다.

---

Thank You HTTPS

HTTPS가 있기에 내 블로그를 들어오기 위해 입력한 링크가 다른 곳으로 가지 않았음을 보장받을 수 있다.

또, 내가 비밀스럽게 나누고 싶은 이야기들도 가능한 한 보장받으며 나눌 수 있게 되었다.

 

Thank You!