HTTPS - 1. 그림으로 살펴보는 HTTPS

그림으로 살펴보는 포스팅을 시작으로, 3편의 포스팅을 통해 HTTPS에 대해서 알아보겠습니다.

• HTTPS - 1. 그림으로 살펴보는 HTTPS

• HTTPS - 2. HTTPS의 Ciphersuite, Handshake, Key derivation

• HTTPS - 3. SSL/TLS History and Security

들어가며

암호화의 구현이 필요한 시스템이나 프로토콜을 설계할 때 HTTPS(HTTP Over TLS)의 동작방식은 좋은 레퍼런스가 될 수 있습니다.

우선 이번 글에서는 그림을 통해 HTTPS가 어떻게 동작하는지 간단하게 살펴보겠습니다.

평문 전송부터 시작해, 하나씩 필요한 기능들을 추가해보면서 필요한 이유들을 이해해봅시다.

용어정리

대칭암호화(Symmetric Encryption), 비대칭 암호화(Asymmetric Encryption), 서명(Signing)의 개념에 대해서는 간단하게 정리만 하고 가겠습니다.

암호화에 필요한 개념은 이쪽글을 읽어보는 것을 추천드립니다.

• Symmetric Encryption : 
  • 같은 키를 이용해 암/복호화하는 방식
  • 보통 데이터 암호화에 사용되며 AES 알고리즘이 많이 사용된다.
• Asymmetric Encryption :
  • 공개키(Public key), 개인키(Private key) 쌍으로 존재
  • 공개키로 암호화하면 개인키로 복호화, 개인키로 암호화하면 공개키로 복호화를 한다.
  • 공개키를 가지고 개인키를 알아낼 수 없다(역도 성립).
  • 보통 키교환, 서명에 사용된다. 
  • ex) RSA

• Signing
  
  • 우리가 알고 있는 서명과 같은 의미로, 개인키를 이용해 서명하고 공개키를 이용해 확인한다.
  • 부인방지, 무결성을 제공한다.
  • ex) RSA, ECDSA

Plaintext - HTTP

우선, Alice가 Bob에게 메시지를 평문으로 전송하는 경우입니다. 

이렇게 평문으로 메시지를 전송할 경우는 Mallory가 간단하게 Alice의 메시지를 가로챈 후 Bob에게 변조된 메시지를 전송할 수 있습니다.

Symmetric encryption

이번에는 메시지를 보호하기 위해 Symmetric 암호화를 이용해 메시지를 암호화하기로 하였고,

이를 위해 사전에 Alice는 Bob에게 암호화 Key를 전송하기로 했습니다.

하지만, 이 경우에는 key를 교환하는 방식에 문제가 있습니다.

Alice가 key를 전송할 때 Mallory가 이 key를 가로챈 후 Bob에게 새로운 암호화 key를 전송한다면, 

Mallory는 Alice, Bob간의 암호화된 메시지를 읽고, 변조할 수 있게 됩니다.

• Alice가 Bob에게 Key 전송
• Mallory가 Key를 가로챈 후, Bob에게 Fake Key 전송
• Alice는 본인이 전송한 Key를 이용해 메시지를 암호화하여 전송
• Mallory는 Key를 이용해 Alice의 메시지를 복호화
• Mallory는 Fake Key를 이용해 변조된 메시지를 암호화하여 Bob에게 전송.

RSA key exchange

이번에는 Key를 안전하게 교환하기 위해 Asymmetric encryption 기반의 key 교환방식을 추가하였습니다.
과정은 이렇습니다.

• Bob은 Asymmetric key 한 쌍(Private Key, Public Key)을 만든 뒤, Alice에게 Public key를 공유.
• Alice는 Symmetric key를 생성한 뒤, Public key를 이용해 Key를 암호화하여 Bob에게 전송.
• Bob은 암호화된 Key를 private key를 이용해 복호화.
• Alice, Bob은 교환된 key를 이용해 메시지를 암/복호화.

참고) 메시지 자체를 Asymmetric encryption을 이용해 암/복호화 하지 않는 이유는 Asymmetric encryption이 Symmetric encryption 방식에 비해 현저히 느리기 때문입니다.
따라서 메시지 암호화는 Symmetric encrpytion을 이용하고, 암호화 key 교환은 Asymmetric encryption 방식을 사용합니다. 

하지만, 이 방식에도 문제가 있습니다. Alice는 전송받은 Public key가 Bob의 것인지 확신할 수 없습니다.

Bob이 Alice에게 Public key를 전송할 때 Mallory가 가로챈 뒤, Mallory의 Public key를 보낸다면

Mallory는 다시 Alice와 Bob의 통신을 가로챌 수 있게 됩니다.

• Bob은 asymmetric key 한 쌍(Private Key, Public Key)을 만든 뒤, Alice에게 Public key를 공유.
• Mallory는 Bob의 Public key를 가로챈 뒤, Alice에게 자신의 Public key를 전송.
• Alice는 Key를 생성 후, Mallory의 Public key를 이용해 암호화하여 전송.
• Mallory는 본인의 Private key를 이용해 Key를 복호화 한 뒤, Bob에게는 Fake key를 Bob의 Public key로 암호화하여 전송.
• Mallory는 Key, Fake key를 이용해 Alice, Bob의 통신 내용을 읽고 변조.

Web PKI

이번에는 Bob의 Public key를 검증하기 위해 Web PKI를 추가로 이용하기로 했습니다.

PKI에서는 Public key를 검증하기 위해, Certificate 포맷을 만들고 제 3자인 CA(Certificate Authority)의 도움을 받습니다.

Public key를 검증하기 위해, Bob, Alice는 키교환과정 이전에 아래의 작업이 필요합니다.

• Bob

1. 1. Bob은 Asymmetric Key 한 쌍을 만듭니다.(Public key, Private key)
   2. Bob은 위에서 만든 Public key를 포함한 Certificate 포맷을 만든 후, 외부 신뢰기관(CA)에게 서명 요청을 합니다.(CSR)
   3. CA는 Bob의 정보를 확인한 뒤, CA의 private key를 이용해 certificate에 서명(signature 추가)을 합니다.
   4. Bob은 서명받은 Certificate를 서버에 설치합니다.

• Alice

1. 1. Alice는 신뢰할 수 있는 CA들의 public key를 이미 갖고 있습니다.(OS 혹은 browser 내장) 

통신을 시작할 때, Bob은 CA에게 미리 서명받은 Certificate를 Alice에게 보냅니다.

Alice는 Certificate를 받은 후, CA의 서명(signature)를 확인하여 Certificate의 내용이 변조되지 않았음을 확인합니다.

(Certificate 내의 Hostname을 보고 통신하고 있는 상대가 Bob이란 것도 확인합니다.)

Alice는 서명을 확인할 때, 이미 갖고 있는 CA의 Public key를 이용합니다.(OS 혹은 Browser등에 설치되어 있음)

마치며

이제까지 HTTPS의 동작방식을 간단하게! 살펴보았습니다.

하지만, 위에서 본 것과는 달리 실제로는 교환한 키를 바로 암호화 키로 사용하지는 않습니다.

교환한 키는 pre-master key라고 부르며, pre-master key에 random값들을 조합하여 master key를 유도(derive)하여 사용합니다.

다음 글에서는 HTTPS에서 사용되는 추가적인 키 교환방식들과 메시지 암호화 알고리즘, 메시지 무결성 검증 방법 등을 포함해 좀 더 자세히 살펴봅시다.

Reference

• HTTPS explained with carrier pigeons
  https://medium.freecodecamp.org/https-explained-with-carrier-pigeons-7029d2193351