[Network] HTTP vs HTTPS, SSL 의 통신과정

1. [Network] 암호화 해시 함수(Cryptographic hash function)
2. [Network] MAC 과 Digital Signatures
3. [Network] HTTP vs HTTPS, SSL 의 통신흐름

 

생소한 용어들을 정리하기 위해 앞의 두 글을 읽어보고 오는 것을 추천합니다.

HTTP 보다는 HTTPS 에 대해 다루며, HTTPS 는 어떤 것을 의미하는지, 어떤 과정을 통해 통신하고 어떤 문제점들을 해결하는지를 중심으로 다룹니다.

---

1. HTTPS 란? (이동)
2. SSL 이란? (이동)
3. SSL 의 통신과정 (이동)

 

1. HTTPS 란?

SSL 의 이해를 돕기 위한 간략화된 이미지

보안(confidentiality, data integrity, end-point authentication) 이 강화된 TCP 를 Secure Sockets Layer (SSL) 이라 부르며, 보통 SSL 과 함께 언급되는 Transport Layer Security (TLS) 는 국제 인터넷 표준화 기구 (IETF) 에 의해 SSL version 3 를 조금 수정하여 표준화한 것입니다. (해당 글에서는 편의상 SSL 로 통일하겠습니다.)

HTTPS 는 SSL/TLS 와 같은 보안 연결을 통해, 암호화된 HTTP 데이터가 전달되는 프로토콜입니다. 즉 HTTP 의 보안 버전이라고 할 수 있습니다. HTTP 와 TCP 와 직접 통신하는 기존의 방식에서, HTTP 는 SSL 과, SSL 이 TCP 와 통신하는 방식을 HTTPS 라고 합니다.

 

2. SSL 이란?

왜 SSL 을 통한 HTTPS 연결이 필요한지 이해하기 위해 시나리오 하나를 예시로 들겠습니다. Bob 이 Alice 의 쇼핑몰을 둘러보고 있는 상황이라고 하겠습니다.

1. Alice 의 사이트는 Bob 에게 상품의 종류, 수량, 그의 주소, 결제 카드 번호 등을 기입할 수 있는 페이지를 보여줍니다.
2. Bob 은 해당 페이지에 필요한 정보를 기입하여 제출을 하게 됩니다.

이 과정에는 문제가 없어보이지만, 이 과정에 보안 조치가 이뤄지지 않는다면 Bob 은 몇 가지 예상치 못한 일들을 당할 수 있습니다.

1. 기밀성 (confidentiality) 이 보장되지 않는다면, 공격자는 Bob 의 주문을 중간에 가로채고, 그의 결제 카드 정보를 소유할 수 있습니다. 공격자는 Bob 의 비용으로 물건을 구매할 수 있게 됩니다. (기밀성이 보장되지 않는다 = 원본 내용이 그대로 유출된다, 암호화되지 않는다는 의미)
2. 데이터 무결성 (data integrity) 이 보장되지 않는다면, 공격자는 Bob 의 주문을 수정할 수 있습니다. (데이터가 조작되어도 데이터를 받는 입장에서는 조작된 사실을 알지 못한다는 의미)
3. 서버 인증 (server authentication) 이 보장되지 않는다면, 공격자는 Alice 의 사이트를 모방하여 Bob 의 정보들을 탈취할 수 있습니다. (해당 사이트가 정말로 Alice 의 사이트가 맞는지, 신뢰할 수 있는 사이트인지 검증할 방법이 없다는 의미)

즉 SSL 은 전달되는 데이터를 암호화하고, 데이터의 변조 여부를 확인하고, 접속하고자 하는 서버가 신뢰할 수 있는 서버인지 검증해주며, 다시 말하자면 기밀성, 데이터 무결성, 서버 및 클라이언트 인증을 통해 TCP 를 강화함으로써 이러한 문제들을 해결할 수 있습니다.

 

3. SSL 통신과정

SSL 은 TCP 를 보호하기 위한 목적으로 만들어졌으며, 공개키(비대칭키) 와 대칭키를 기반으로 동작하는 프로토콜입니다.

SSL 의 통신과정은 크게 handshake, key derivation, data transfer 세 가지 순서로 나눌 수 있습니다. 

1. handshake

SSL handshake

handshake 단계는 Bob 과 Alice 의 TCP connection (a) 단계, Alice 가 정말 Alice 인지 검증하는 (b) 단계, Alice 에게 SSL session 을 위해 필요한 대칭키들을 생성하기 위해 Bob 과 Alice 모두에게 사용될 대칭키를 전송하는 (c) 단계 총 세 단계로 구성됩니다. (Bob 은 클라이언트, Alice 는 서버입니다.)

1. (a) 단계인 TCP 연결이 이루어졌다고 가정하고, Bob 은 Alice 에게 자신의 nonce^* 를 전송합니다.
2. 그러면 Alice 는 자신의 공개키가 포함된 사이트 인증서를 Bob 에게 전송합니다. 해당 인증서는 해당 글([Network] MAC 과 Digital Signatures) 에서 언급한 CA 에 의해 인증된 인증서를 의미합니다.
3. Bob 은 웹브라우저에 내장된 CA 공개키를 통해 사이트 인증서를 복호화하여 사이트의 정보와 Alice 의 공개키를 얻을 수 있으며, Alice 의 사이트가 맞다는 것을 확신할 수 있습니다. 해당 과정까지가 (b) 단계입니다.
4. 그 후에 Bob 은 대칭키를 Alice 의 공개키로 암호화하여 Alice 에게 전송합니다. (더 정확히는 pre-master secret, master secret 등의 용어가 사용되지만, 편의상 '대칭키' 라고 사용하겠습니다.)
5. Alice 는 대칭키를 얻기 위해 자신의 개인키로 복호화합니다.

해당 과정을 통해 정확히 Bob 과 Alice 둘만이 이번 SSL session 을 위한 대칭키를 알게 됩니다.

^*nonce : 간단하게 '랜덤한 값' 이라고 칭하겠습니다.

 

2. key derivation

SSL handshake 를 통해 대칭키가 Bob 과 Alice 에게 공유되었습니다. 이렇게 공유된 대칭키를 그냥 사용할 수도 있지만, 암호화와 무결성 검사를 위해 다른 키를 사용하는 것이 더 안전하기 때문에 Alice 와 Bob 은 대칭키와 SSL handshake 에서 주고 받은 nonce 를 사용하여 네 가지 key 를 만들게 됩니다.

E_B = Bob 이 Alice 에게 데이터를 보낼 때 사용할 암호화 키
M_B = Bob 이 Alice 에게 데이터를 보낼 때 사용할 MAC 키
E_A = Alice 가 Bob 에게 데이터를 보낼 때 사용할 암호화 키
M_A = Alice 가 Bob 에게 데이터를 보낼 때 사용할 MAC 키

키 파생 단계 이후 Alice 와  Bob 은 데이터를 암호화하기 위한 두 개의 암호화 키와, 데이터의 무결성을 검증하기 위한 두 개의 MAC 키 총 네 가지 키를 갖게 됩니다.

 

3. Data Transfer

이제 Alice 와 Bob 은 TCP 연결을 통해 서로 보안 데이터를 전송할 수 있습니다. SSL 이 데이터를 암호화한 다음, 암호화된 데이터를 TCP 로 전달하는 과정을 생각해볼 수 있습니다. 하지만, 이렇게 하게 될 경우 무결성 확인을 위한 MAC 은 어떤 과정에 넣으면 될까요? 

Bob 의 모든 데이터의 무결성을 검증하기 위해 TCP 세션이 끝나기까지 기다리는 것은 비효율적일 수 있습니다. 이 문제를 해결하기 위해

1. 데이터 stream 을 records 로 분할합니다.
2. M_B 를 '암호화 해시 함수' 에 대입하여 MAC 을 구합니다.
   [Network] 암호화 해시 함수(Cryptographic hash function)
3. MAC 을 각 record 에 추가한 다음, (record + MAC) 을 E_B 로 암호화합니다.
4. 이렇게 암호화된 패키지가 TCP 에 전달됩니다.

하지만 이것만으로는 데이터 무결성을 확신할 수 없습니다. 공격자가 Alice 와 Bob 사이에서 전송되는 TCP segments 를 삽입/삭제/재배열 할 수도 있기 때문입니다. 때문에 이러한 것을 막기 위해 SSL 은 sequence number 를 사용합니다.

1. Bob 은 0부터 시작하며, 각 SSL record 가 전달될 때마다 증가하는 sequence number 카운터를 유지합니다.
2. 이 때 실제로 record 자체에 sequence number 를 포함하지는 않습니다. Bob 이 MAC 을 계산하는 과정에서 sequence number 를 포함합니다.
3. Alice 는 Bob 의 sequence number 를 추적하여 MAC 계산에 적절한 sequence number 를 포함함으로써 record 의 데이터 무결성을 확인할 수 있습니다.

이러한 SSL sequence number 의 이용을 통해 공격자가 segment 를 재배치하거나 재배열하는 등의 Man-in-the-middle attack 을 수행하는 것을 예방할 수 있습니다.