HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

RECOMMEND POSTS BEFORE THIS

• HTTP(HyperText Transfer Protocol)

1. HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

HTTP(HyperText Transfer Protocol)은 다음과 같은 보안적인 문제점들을 가지고 있습니다.

• 평문(plain text)를 주고 받기 때문에 도청이 가능합니다.
• 메시지를 중간에 변조할 수 있습니다.
• 통신하는 상대방을 확인하지 않기 때문에 위장이 가능합니다.
  • 통신하고 있는 상대방이 안전한지 확인이 불가능합니다.

이런 문제들을 해결하기 위해 보안적으로 개선된 프로토콜이 HTTPS(HyperText Transfer Protocol over Secure Socket Layer)입니다.

HyperText Transfer Protocol over Secure Socket Layer
SSL(Secure Socket Layer)을 통한 하이퍼 텍스트 전송 프로토콜

보안 관련된 계층(layer)을 만들고 이를 거쳐 통신하는 방법입니다. SSL(Secure Socket Layer)라는 단어는 TLS(Transport Layer Security)라는 용어로 바뀌었지만, 현재까지도 SSL이라는 명칭을 많이 사용하고 있습니다.

1.1. Communication Layers of HTTP and HTTPS

• 일반적인 HTTP 통신과 달리 어플리케이션(application) 계층과 전송(transport) 계층 사이에 보안 계층이 하나 더 존재합니다.

https://heidyhe.github.io/https/

1.2. How to communicate via HTTPS?

• 어플리케이션이 메시지를 송신할 때 보안 계층은 어플리케이션 계층에서 받은 메시지를 암호화하여 보안 계층으로 내려줍니다.
• 어플리케이션이 메시지를 수신할 때 보안 계층은 전송 계층에서 받은 메시지를 복호화하여 어플리케이션 계층으로 올려줍니다.

2. Encryption/Decryption Algorithms

HTTPS는 두 가지 암호화/복호화 알고리즘을 사용합니다. 보안 레이어에서 무슨 일을 알기 위해선 각 알고리즘이 어떤 방식으로 동작하는지 알아야 합니다.

• 대칭 키(Symmetric Key)
• 비대칭 키(Asymmetric Key)

2.1. Symmetric Key

대칭 키 방식은 다음과 같은 특징을 가지고 있습니다.

• 하나의 키로 암복호화가 모두 가능합니다.
• 비대칭 키 방식보다 속도가 빠릅니다.
• 하나의 키로 암복호화가 가능하기 때문에 키가 노출되면 보안에 문제가 발생합니다.
• 다음과 같은 예를 들어보겠습니다.
  • 사용자_A가 KEY_A로 평문을 암호화 합니다.
  • 사용자_A가 암호화 된 메시지를 사용자_B에게 전달합니다.
  • 사용자_B는 암호화 된 메시지를 KEY_A로 복호화 합니다.
  • 사용자_B는 복호화 된 평문 내용을 확인할 수 있습니다.

https://mysterico.tistory.com/30

2.2. Asymmetric Key

비대칭 키 방식은 다음과 같은 특징을 가지고 있습니다.

• 키가 두 개 존재합니다.
  • 비공개 키(private key)
  • 공개 키(public key)
• 두 키는 상호 보완적으로 동작합니다.
  • 비공개 키로 암호화한 평문은 공개 키로만 복호화가 가능합니다.
  • 공개 키로 암호화한 평문은 비공개 키로만 복호화가 가능합니다.
• 대칭 키 방식에 비해 속도가 느립니다.
• 비공개 키, 공개 키가 모두 노출되면 보안에 문제가 발생합니다.
• 비공개 키는 개인이 소유하고, 공개 키는 통신하고 싶은 타인에게 제공합니다.
• 다음과 같은 예를 들어보겠습니다.
  • 사용자_A가 PUBLIC_KEY_A로 평문을 암호화 합니다.
  • 사용자_A가 암호화 된 메시지를 사용자_B에게 전달합니다.
  • 사용자_B는 암호화 된 메시지를 PRIVATE_KEY_A로 복호화 합니다.
  • 사용자_B는 복호화 된 평문 내용을 확인할 수 있습니다.

https://mysterico.tistory.com/30/

3. Certificate Authority and SSL Certificate

대칭 키/비대칭 키 암호화 알고리즘을 통해 메시지를 암복호화한다는 것은 알았습니다. 통신하는 상대방이 안전하고 신뢰할 수 있는지 보장하기 위한 방법으로 인증서(certificate)를 사용합니다.

3.1. Certificate Authority

SSL 인증서를 발급해주는 기업들을 CA(Certificate Authority) 혹은 Root Certificate라고 부릅니다. CA는 아무 기업이나 할 수 있지 않습니다. 신뢰성이 업격하게 공인된 기업들만 참여할 수 있습니다.

• https://en.wikipedia.org/wiki/Certificate_authority

Certificate Authority Marketing

Rank	Issuer	Usage	Market share
1	IdenTrust	38.0%	51.2%
2	DigiCert	14.6%	19.7%
3	Sectigo	13.1%	17.7%
4	GoDaddy	5.1%	6.9%
5	GlobalSign	2.2%	3.0%

3.2. SSL Certificate

SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서다.

서비스 기업들은 자신의 공개 키를 클라이언트(이하 브라우저)에게 안전하게 전달하기 위해 인증서를 사용합니다. 서비스 기업들은 암호화가 필요한 공개 키를 CA에게 전달하여 인증서 생성을 요청합니다. CA는 자신이 지닌 비공개 키를 사용해 서비스 기업을 위한 인증서를 생성합니다. SSL 인증서에는 다음과 같은 정보를 가지고 있습니다.

• 해당 인증서를 발급한 CA
• 서비스의 도메인
• 서비스에서 제공하는 공개 키와 암호화 방법

사용자가 브라우저를 통해 서비스에 접근하면 서비스는 미리 발급해놓은 인증서를 브라우저에게 전달합니다. 브라우저는 전달 받은 인증서를 CA의 공개 키로 복호화합니다. CA는 세계적으로 신뢰할 수 있는 공인된 기관이기 때문에 CA의 공개 키는 대부분의 브라우저가 이미 알고 있습니다.

Brower message depending on certificate authority

• 인증서를 발급한 CA의 공인 여부는 브라우저 주소창을 통해 확인할 수 있습니다.

https://opentutorials.org/course/228/4894

SSL Certificate Issuance Process

다음과 같은 과정을 통해 서비스 기업의 인증서가 발행됩니다.

1. 서비스 기업은 자신의 공개 키를 CA에게 전달하며 인증서 생성을 요청합니다.
2. CA는 자신의 비공개 키를 사용해 서비스 기업의 공개키를 암호합니다.
3. 생성한 인증서를 서비스 기업에게 전달합니다.

Exchange SSL Certificate Between Server and Browser

인증서를 발급 받은 기업은 자신이 운영하는 서비스에 인증서를 적용합니다. 브라우저와 서비스(혹은 서버) 사이에 인증서 전달은 다음과 같은 과정을 통해 이뤄집니다.

1. 브라우저가 서버에게 데이터 요청을 합니다.
2. 서버는 브라우저에게 인증서를 우선 전달합니다.
3. 브라우저는 이미 알고 있는 CA 목록 중 해당 인증서를 암호화한 업체가 있는지 확인합니다.
4. 브라우저는 이미 알고 있는 CA의 공개 키를 사용해 해당 인증서를 복호화합니다.
5. 복호화 후 해당 인증서 내부에 들어있는 서비스 업체의 공개 키를 사용합니다.

4. HTTPS Communication Process

HTTPS 통신을 위해 필요한 준비문들은 모두 확인하였습니다. 이제 통신 과정을 살펴보겠습니다. 통신 과정은 크게 세 단계로 나뉩니다. 각 단계에서 어떤 일들이 일어나는지 알아보겠습니다.

1. Handshake
2. Session
3. Session Close

4.1. Handshake

아래 설명에서 클라이언트는 브라우저입니다.

1. 클라이언트가 서버에 접속합니다. (Client Hello)
   • 임의의 데이터를 생성하여 이를 전달합니다.
   • 클라이언트와 서버가 지원하는 암호화 방식에 대해 서로 협상합니다.
   • 클라이언트 측에서 자신이 사용할 수 있는 암호화 방식을 전송합니다.
   • SSL HandShaking을 이미 수행하였다면 기존의 세션을 재활용 합니다.
2. 서버가 클라이언트에게 응답합니다. (Server Hello)
   • 임의의 데이터를 생성하여 이를 전달합니다.
   • 인증서를 전달합니다.
   • 클라이언트가 전달한 암호화 방식 중에서 서버에서 사용 가능한 암호화 방식을 선택해서 클라이언트에게 전달합니다.
   • 이렇게 협의가 끝나면 클라이언트와 서버는 협의한 암호화 방식을 이용하여 정보를 교환합니다.
3. 클라이언트는 서버의 인증서를 전달받습니다.
   • 클라이언트는 인증서가 공인된 CA에서 발급되었는지 자신의 리스트를 확인합니다.
   • 서버에서 보낸 임의의 데이터와 자신이 만든 임의의 데이터를 조합하여 대칭 키를 만듭니다.
   • 인증서를 복호화하여 얻은 서버의 공개 키를 이용해 생성한 대칭 키를 암호화합니다.
   • 암호화 된 대칭 키를 서버에게 전달합니다.
4. 서버는 암호화 된 클라이언트의 대칭 키를 전달받습니다.
   • 클라이언트가 만들어 전달한 암호화 된 대칭 키를 자신의 비공개 키로 복호화합니다.
   • 해당 대칭 키에 매칭되는 세션 키(session key)를 만듭니다.
   • 앞으로 해당 클라이언트 식별은 세션 키를 이용합니다.
5. 클라이언트와 서버는 handshake 단계 종료를 서로에게 알립니다.

4.2. Session

1. 실제로 서버와 클라이언트가 데이터를 주고 받는 단계입니다.
2. 세션 키 값을 이용하여 대칭 키 방식으로 데이터를 암호화하여 상대방에게 전달합니다.
3. 상대방도 세션 키 값과 대칭 키를 알고 있으므로 이를 이용해 복호화합니다.

4.3. Seession Close

1. 데이터의 전송이 끝나면 통신이 끝났음을 서로에게 알려줍니다.
2. 통신에서 사용한 세션 키는 폐기합니다.

HTTPS Communication Process

https://mysterico.tistory.com/30

5. Summary

다음과 같이 요약할 수 있습니다.

• HTTPS는 대칭 키와 비대칭 키를 사용해 속도와 보안을 적절하게 유지한 통신 방법입니다.
• 인증 기관에서 발급한 인증서를 통해 서비스 업체의 공개 키(서비스 업체)를 브라우저에게 안전하게 전달합니다.
  • 인증서를 브라우저에게 전달하면, 브라우저에 이미 존재하는 인증 기관의 공개 키(CA)로 복호화가 가능합니다.
  • 브라우저가 인증서를 복호화하면 공개 키(서비스 업체)를 얻을 수 있습니다.
• 공개 키(서비스 업체)를 사용해 서버와 브라우저는 대칭 키를 공유합니다.
  • 대칭 키는 같은 키로 암복호화가 가능하기 때문에 탈취 당할 경우 서버와 클라이언트 모두 위험합니다.
  • 대칭 키를 그대로 인터넷 상에 노출하는 것은 위험합니다.
  • 브라우저는 대칭 키를 공개 키(서비스 업체)로 암호화하여 서버에게 전달합니다.
  • 서버는 암호화 된 메시지를 비공개 키(서비스 업체)로 복호화하여 대칭 키를 얻습니다.
• 서버와 브라우저는 대칭 키를 사용해 메시지를 암복호화합니다.
  • 통신 메시지의 암복호화를 비대칭 키만 사용하는 것은 많은 연산이 필요하기 때문에 비효율적입니다.

REFERENCE

• HTTPS의 원리
• https://heidyhe.github.io/https/
• https://mysterico.tistory.com/30
• https://jeong-pro.tistory.com/89
• https://coding-start.tistory.com/208
• https://opentutorials.org/course/228/4894
• https://bravenamme.github.io/2019/07/04/https-1/
• https://bravenamme.github.io/2019/12/03/https-2/