HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

4 분 소요


RECOMMEND POSTS BEFORE THIS

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이라는 명칭을 많이 사용하고 있다. 일반적인 HTTP 통신과 달리 애플리케이션(application) 계층과 전송(transport) 계층 사이에 보안 계층이 하나 더 존재한다.

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


서버와 클라이언트는 HTTPS를 통해 어떻게 통신할까?

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

2. Encryption/Decryption Algorithms

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

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

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

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


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

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

3. Certificate Authority and SSL Certificate

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

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

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의 공개 키는 대부분의 브라우저가 이미 알고 있다.

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

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


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

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


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

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

4. HTTPS Communication Process

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

  1. 핸드쉐이크(Handshake)
  2. 세션(Session)
  3. 세션 종료(Session Close)

아래 설명에서 클라이언트는 브라우저이다. 먼저 핸드쉐이크 과정을 살펴보자.

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

세션 과정은 다음과 같다.

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

세션 종료 과정은 다음과 같이 이뤄진다.

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

아래 이미지는 핸드쉐이크와 세션 과정이다.

https://mysterico.tistory.com/30

5. Summary

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

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

REFERENCE

카테고리:

업데이트:

댓글남기기