HTTPS는 왜 안전한가?

최근에 https에 대해서 공부하면서 알게 된 내용을 정리해보려고 합니다.

https가 제공하는 기능은 아래와 같습니다.

• data privacy

• data integrity

• identification

그럼 위의 기능들을 https가 어떻게 제공하는지 살펴보겠습니다.

HTTPS의 필요성

https는 http의 보안이 강화된 버전입니다. https라는 이름도 http에 secure를 의미하는 s가 붙어 만들어진 단어입니다. http는 통신을 할 때 데이터가 text로 전달이 되기 때문에 보안에 매우 취약합니다. 예를 들어, 인터넷에서 물건을 구입하기 위해 카드번호를 입력해야 하는 경우 https가 아닌 http를 사용한다면 request body의 내용이 아래와 같이 입력값 그대로 서버에 전달됩니다.

request_body: { 
  card_number: 1234–5678–9012–3456
}

만약 공공 와이파이에 연결되어 있는 상황이라면 제 3자에 의해 카드번호가 쉽게 노출될 수 있습니다.

이런 일을 방지하기 위해 https는 데이터를 암호화해서 서버로 보냅니다. 데이터를 암호화하면 누군가가 서버로 전송되는 데이터를 탈취해서 내용을 확인한다고 해도 유의미한 정보를 얻을 수 없게 됩니다.

대칭키 암호화와 비대칭키 암호화

https가 데이터를 어떻게 암호화 하는지 알아보기 전에 데이터 암호화에 대해 간략하게 알아봅시다.

데이터를 암호화하는 방법은 대칭키 암호화와 비대칭키 암호화 이렇게 두 가지로 나뉩니다.

먼저, 대칭키 암호화 입니다. 대칭키 암호화는 그림과 같이 암호화와 복호화에 같은 키가 사용됩니다. 대칭키 암호화는 비대칭키 암호화에 비해 빠른 암/복호화 속도를 보여주지만 키를 가지고 있다면 누구든지 암호문을 해독할 수 있기 때문에 키를 안전하게 공유할 수 있는 방법이 있어야 합니다.

대칭키 암호화 방식의 암 / 복호화 과정

다음은 비대칭키 암호화 입니다. 비대칭키 암호화는 대칭키 암호화의 단점인 키 공유 문제를 해결한 암호화 방법입니다. 비대칭키 암호화는 대칭키 암호화와 다르게 암호화에 사용되는 키와 복호화에 사용되는 키가 다릅니다. 이 키의 쌍을 공개키/개인키 라고 부릅니다(그래서 비대칭키 암호화를 공개키 암호화라고도 부릅니다). 공개키로 암호화하면 개인키로만 복호화할 수 있고, 개인키로 암호화하면 공개키로만 복호화할 수 있습니다. 공개키는 누구나 알 수 있는 키이고 개인키는 키의 소유자만 알 수 있습니다. 따라서 A의 공개키로 암호화된 암호문은 A의 개인키를 소유하고 있는 A만 열어볼 수 있습니다.

다음은 비대칭키 암호화의 암/복호화 과정입니다. A가 B에게 B의 공개키로 암호화된 암호문을 보내면 B의 개인키를 가지고 있는 B만이 암호문을 복호화 할 수 있습니다.

비대칭키 암호화 방식의 암 / 복호화 과정

비대칭키 암호화에는 재미있는 특징이 있습니다. 만약 A가 B에게 A의 개인키로 암호화된 암호문을 보내면 어떻게 될까요?

A의 개인키로 암호화 된 암호문은 A의 공개키로 복호화할 수 있는데 공개키는 모두에게 공개되어 있습니다. 그럼 이 암호문은 의미 없는 암호문일까요?

아닙니다.

A의 개인키로 암호화된 암호문은 그 암호문이 A로부터 왔다는 사실을 인증 해줍니다. A의 공개키로 복호화된다는 것은 그 암호문이 A만 소유하고 있는 A의 개인키로 암호화되었다는 뜻이기 때문에 암호문이 A로부터 왔다는 것을 의미합니다. 따라서 개인키로 암호화하는 것을 전자서명이라고 합니다.

---

TLS handshake

https의 네트워크 계층구조

https는 http와 TCP 계층 사이에 데이터 암호화를 담당하는 TLS 계층이 추가된 것입니다. 즉, https가 어떤 과정을 거쳐 데이터 암호화를 하는지 알려면 TLS계층이 어떻게 데이터를 암호화 하는지 알면 됩니다.

TCP 계층의 3 way-handshake 과정이 끝나면 데이터 암호화를 위한 TLS 계층의 handshake가 시작됩니다. TLS 계층의 handshake 과정은 총 4단계로 이루어집니다.

TLS handshake 과정

1. client가 먼저 server에게 client가 random으로 생성한 문자열(client random)과 client측에서 사용 가능한 암호화 알고리즘의 목록을 보냅니다. server는 client에게 받은 암호화 알고리즘의 목록에서 하나를 선택합니다.

2. server는 client에게 선택된 암호화 알고리즘, server의 인증서, server의 공개키, server가 random으로 생성한 문자열(server random)을 보냅니다. client는 server에게 받은 인증서가 유효한 인증서인지 확인합니다. 유효한 인증서인지 확인하는 방법에 대해서는 밑에서 설명하겠습니다.

3. client는 server에게 다시 한번 random으로 생성한 문자열을 보냅니다. 이 random 문자열을 pre-master secret이라고 부르고 1번에서 보냈던 client random과는 다른 문자열입니다. pre-master secret은 client random과 다르게 2번 과정에서 받은 server의 공개키로 암호화해서 server로 보냅니다. server는 server의 개인키로 암호문을 복호화 해 pre-master secret의 내용을 확인합니다.

4. server는 마지막으로 handshake 과정의 종료를 알리는 신호를 client로 보내고 handshake를 종료합니다.

TLS handshake의 목적은 server의 신원확인과 통신 데이터 암호화에 사용할 대칭키 공유입니다. 그럼 어떻게 이 목적을 달성하는지 알아보겠습니다.

Server의 신원 확인

먼저 server의 신원 확인입니다. server의 신원확인은 왜 필요할까요? 우리가 온라인 쇼핑몰에 접속해서 상품 주문을 위해 카드번호를 입력한다고 했을 때 우리가 입력한 카드번호가 정말로 온라인 쇼핑몰의 서버로 전달되는 것인지 확인할 수 있어야 합니다. 즉, 통신하려는 대상이 정말 그 대상인지를 확인해야합니다.

client는 server의 신원을 확인하기 위해 2번 과정을 통해 server로부터 정말 그 server가 맞다는 내용의 인증서를 전달받고 그 인증서가 유효한 인증서인지 확인합니다.

그럼 client에서는 server에게 받은 인증서가 유효한지 어떻게 확인할까요?

우선 server의 인증서는 CA라고 불리는 인증기관에서 발급해줍니다. 아주 엄격한 보안 인증절차와 감사를 통과해야만 CA로 등록될 수 있기 때문에 CA가 발급한 인증서는 믿을 수 있다고 여겨집니다. 그리고 그 인증서는 CA의 개인키로 암호화되어 있습니다.

client에는 CA의 공개키가 저장되어있습니다. server로부터 받은 인증서를 CA의 공개키로 복호화해보고 복호화가 된다면 그 인증서가 CA에서 발급한 유효한 인증서라는 것을 확인할 수 있습니다.

대칭키 암호화에 사용될 키 공유

다음은 대칭키 공유입니다. TLS handshake 과정이 종료되면 client와 server는 각각 client random, server random, pre-master secret 이렇게 세 가지의 random 문자열을 공유하게 됩니다. 이 문자열들을 조합해 client와 server는 각각 대칭키 암호화에 사용할 대칭키를 만들게 됩니다.

client random과 server random은 암호화 상태로 통신을 하지 않았기 때문에 외부에 노출이 될 수 있지만 pre-master secret은 server의 공개키로 암호화하여 server에 전달했기 때문에 client와 server만 그 값을 알 수 있습니다. 따라서 client와 server는 서로만 알 수 있는 대칭키를 안전하게 공유하게 되었습니다.

---

데이터 암호화와 메시지 인증

TLS handshake 과정을 통해 server의 신원확인과 대칭키 공유를 하고 나면 안전하게 통신을 시작할 수 있습니다. 이제 client와 server가 데이터를 주고받을 때 대칭키로 암호화해서 주고받기 때문에 제 3자가 중간에서 데이터를 탈취한다 하더라도 그 내용을 알 수 없게 됩니다.

TLS 계층은 데이터를 암호화할 뿐만 아니라 데이터가 통신 도중 제 3자에 의해 변경되지 않았다는 사실을 보장하기 위해 MAC(Message Authentication Code)라고 불리는 메시지 인증코드를 같이 보냅니다. MAC는 데이터의 해시값입니다. 아래는 데이터의 변조 여부를 확인하는 과정입니다.

데이터 변조여부 확인과정

수신자는 송신자로부터 받은 데이터를 대칭키로 복호화하여 데이터와 MAC 값을 추출합니다. 그다음 데이터의 해시값을 계산하고 송신자로부터 받은 MAC와 그 값이 같은지 확인합니다. 만약 MAC와 수신자가 계산한 해시값이 다르다면 데이터가 중간에 변조되었다는 사실을 알 수 있습니다.

https를 이용해 한 번의 request와 response를 주고받는 동안 이렇게 많은 과정이 일어나는 것입니다.

하지만 이 과정들을 통해 우리는 인터넷 상에서 데이터를 안전하게 주고받을 수 있습니다.