HTTPS는 HTTP의 암호화된 버전이다. 두 프로토콜의 차이점은 HTTPS는 TLS/SSL을 사용하여 HTTP 요청과 응답을 암호화하는 것, 그리고 이 요청과 응답에 디지털 서명을 한다는 것이다. 그 결과로 HTTPS는 HTTP보다 훨씬 더 보안이 강화되어있다.
HTTP란?
HTTP는 네트워크 위에서 데이터를 전송하는데 사용되는 프로토콜이다. 웹사이트 컨텐트나 API를 포함한 인터넷 상에서 전송되는 모든 정보는 HTTP 프로토콜을 사용한다. HTTP 메시지의 두가지 메인 종류는 요청과 응답이다.
HTTP 요청은 유저가 웹에서 인터랙트하는 웹브라우저에서 생성된다. 예를 들어 유저가 링크를 클릭하면 브라우저는 해당 컨텐츠에 대한 일련의 HTT GET 요청을 전송한다.
이러한 HTTP 요청은 모두 원본서버 혹은 프록시 캐시 서버로 가고, 서버는 HTTP 응답을 생성한다.
HTTP 요청은 HTTP 프로토콜을 따르는 일련의 텍스트 라인이다. GET 요청은 아래와 같다.
GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en유저의 브라우저에 의해 생성된 이 텍스트들은 인터넷을 거쳐 보내진다. 문제는 이 텍스트가 보이는 그대로 평문이라, 누구든지 '읽을 수 있다'는 점이다.
특히 이는 유저가 민감한 데이터를 제출할 때 이슈가 된다. 패스워드가 됐든, 신용카드 번호가 됐든 폼에 입력된 데이터는 HTTP 프로토콜로 해당 데이터가 전송된다면 누구든지 읽을 수 있다.
HTTP 응답은 아래와 같다.
HTTP/1.1 200 OK
Date: Wed, 30 Jan 2019 12:14:39 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2019 11:17:01 GMT
Accept-Ranges: bytes
Content-Length: 12
Vary: Accept-Encoding
Content-Type: text/plain
Hello World!만약 웹사이트가 HTTPS 대신 HTTP를 사용한다면 모든 요청과 응답은 이를 모니터링하고 있는 누군가에 의해 읽혀질 수 있다.
악의적인 유저는 이러한 요청이나 응답에 있는 텍스트를 읽고 누군가가 요청하거나 보내거나 받는 정보가 무엇인지 정확히 알 수 있다는 것이다.
HTTPS란?
HTTP는 위에서 말했듯 평문으로 통신하기에 안전하지 않다. 통신을 하려면 필연적으로 민감한 정보, 예를 들면 패스워드 정보 같은 것이 왔다갔다할 수 밖에 없는데 HTTP로서는 이러한 민감한 정보를 보호하는데 취약하다.
HTTPS는 이러한 HTTP 내 보안적인 문제를 해결하기 위해 나타났다. HTTPS를 통해 클라이언트와 서버는 서로 암호화된 형식의 데이터를 주고 받게 된다.
HTTPS는 어떻게 동작하는가
HTTPS는 서버와 클라이언트가 데이터를 암호화해서 주고 받는다.
(출처: https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/)
그럼 데이터를 어떻게 암호화할까? 서버와 클라이언트 양 측이 갖고 있는 암호화키를 통해서 암호화 하게 된다. 이러한 암호화키를 대칭키라 부른다. 그러면, 대칭키는 어떻게 서버와 클라이언트 간 공유가 될까? TLS 핸드쉐이크 과정을 통해 공유가 된다.
사실 대칭키를 공유한다고 했는데 그리 단순한 과정은 아니다. 이를 알기 위해서는 먼저 대칭키 암호화 방식과 비대칭키 암호화 방식에 대해 살펴보아야 한다.
대칭키 암호화
대칭키 암호화 방식은 단일 암호화키를 사용하여 데이터를 암호화 및 복호화 한다. 즉 발신자 측에서 암호키를 사용해 데이터를 암호화 하고, 그 다음 수신자 측에서 같은 키를 갖고 복호화를 하는 방식이다.
(출처: https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/)
그림에서 보듯이 대칭키 암호화 방식은 데이터를 암호화/복호화 하기 위해 서버와 클라이언트 양 측이 키를 공유하고 있어야 한다. 이로인해 대칭키 암호화 방식은 몇 가지 약점을 갖게 된다.
첫 번째는 암호화 키를 공유하는 방식이 반드시 안전해야 한다는 것이다. 서버와 클라이언트 사이에 앉아 데이터를 탈취하려는 해커의 눈을 피해 안전히 키를 교환할 방법을 강구해야 한다는 뜻이다.
또한 서버, 클라이언트 모두 키를 안전히 보관해야 하는 책임이 있다. 한 쪽에서 열심히 키를 안전하게 보관하기 위해 애써도 다른 측에서 똑같이 애를 쓰지 않는다면 허사인 셈이다.
비대칭키 암호화
비대칭키 암호화는 한 쌍의 서로 다른, 하지만 수학적으로 연결된, 키를 사용한다. 그 중 하나는 바로 공개키이다. 주로 데이터를 암호화하는데 쓰이며 이름과 같이 공개되어있다.
두 번째 키는 개인키이다. 주로 데이터를 복호화 하는데 쓰인다. 개인키는 반드시 안전히 보관되어야 하며 다른 곳에 전송되어서는 안된다.
(출처: https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/)
이러한 비대칭키 암호화 방식은 대칭키 암호화 방식의 약점을 보완할 수 있다.
데이터를 복호화 하는 개인키는 어디로든 전송되지 않는다. 그러므로 오직 수신자, 즉 서버만이 개인키에 대한 안전을 책임지면 된다. 이러한 속성으로 인해 키가 유출되어 메시지가 복호화될 가능성을 현격히 감소시켜 준다. 더불어 비대칭키 암호화 방식은 디지털 서명에 널리 쓰이는 방식이기도 하다.
이러한 비대칭키 암호화 방식은 대칭키 암호화 방식보다 훨씬 더 보안의 수준이 높지만, 대신 느리다. 이러한 이유로 이 두가지 방식을 혼합하여 사용하곤 한다. 즉 데이터를 암호화 하는 것은 대칭키를 사용하여 암호화 하고, 대신 대칭키를 교환할 때 비대칭키 암호화 방식을 사용하는 것이다. 데이터 송수신에 있어 느린 비대칭키 암호화 방식을 사용하는 것에는 한계가 있기 때문이다.
TLS handshake
서버와 클라이언트간 대칭키를 공유하는 과정은 TLS handshake를 통해 이루어진다.
(출처: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/)
위 사진처럼 TLS handshake는 TCP 연결이 TCP 3-way handshake를 통해 열린 후에 발생한다.
각 단계별로 자세히 살펴보기전에 간단히 SSL인증서에 대해 설명하고자 한다.
SSL인증서
클라이언트가 접속한 서버가 실제 해당 서버가 맞는지 보장하기 위해 SSL 인증서가 쓰인다. 해당 인증서는 CA(Certificate authority)라 불리우는 인증된 기관에서 발급받을 수 있다. 서버를 운영하는 웹사이트 측에서 해당 기관으로부터 인증서를 구입해야 한다. CA기업은 CA기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고 CA 기업의 개인키를 이용하여 암호화하여 구입하려는 측에 제공한다.
그리고 서버는 이 인증서를 클라이언트에게 제공하게 되어있다. 클라이언트는 해당 인증서를 어떻게 복호화할까? 우리가 사용하는 브라우저들에는 이러한 신뢰할 수 있는 CA 기관의 공개키를 이미 갖고 있다. 이를 통해 인증서를 복호화하고 거기서 서버의 공개키를 얻어낼 수 있다.
TLS handshake의 각 단계
(출처: https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/)
위의 그림은 단순화된 handshake의 과정이다. 아래에서 좀 더 자세히 살펴보자.
-
'클라이언트 헬로' 메시지
- 클라이언트가 서버로 '헬로' 메시지를 전송하며 동시에 지원되는 TLS 프로토콜 버전, client random이라 하는 랜덤 바이트 문자열을 보낸다.
-
'서버 헬로' 메시지
- 클라이언트 헬로 메시지에 대한 응답으로 서버측의 '헬로'메시지와 더불어 서버에서 선택한 TLS 프로토콜 버전, 서버측의 server random, 그리고 공개키가 포함된 SSL 인증서를 보낸다.
-
인증
- 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증한다. 위에서 말했듯 각 브라우저는 CA 기관의 공개키를 이미 갖고 있다. 이 공개키를 갖고 서버로부터의 인증서를 복호화해낼 수 있다면 이 인증서는 공인된 것임을 검증할 수 있다.
-
premaster secret key
- 클라이언트가 premaster secret라고 하는 랜덤 바이트 문자열을 만든다. 이 premaster secret은 서버의 공개키로 암호화된 후 서버측으로 전송된다. 해당 문자열은 서버의 개인키로만 해독할 수 있다.
-
개인키로 복호화
- 클라이언트로부터 받은 premaster secret 키를 서버의 개인키로 복호화한다.
-
세션키 생성
- 서버와 클라이언트가 premaster secret키, client random, server random을 사용하여 세션키를 생성한다. 이 세션키가 바로 앞으로 주고받을 데이터를 암호화할 대칭키이다.
-
클라이언트 준비 완료
- 클라이언트가 세션키로 암호화한 '완료' 메시지를 전송한다.
-
서버 준비 완료
- 서버가 세션키로 암호화된 '완료' 메시지를 전송한다.
이렇게 TLS handshake가 완료되면 이 과정에서 생성한 세션키로 데이터를 암호화하여 통신한다.
참조
https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
https://www.baeldung.com/cs/ssl-vs-tls
https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/
https://steady-coding.tistory.com/512
