HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

5 분 소요


지난 포스트에서 HTTP 프로토콜에 관해 정리해보았습니다. 이번엔 보안과 관련되어 조금 더 보완된 HTTPS(HyperText Transfer Protocol over Secure Socket Layer)에 대해 알아보겠습니다.

HTTPS(HyperText Transfer Protocol over Secure Socket Layer) 란?

HTTP 통신의 보안 측면에서 문제가 있어 이를 개선한 통신 프로토콜입니다.

HTTP 통신의 보안 문제
  • 암호화하지 않은 통신이므로 도청이 가능합니다.
  • 통신 상대를 확인하지 않으므로 위장할 수 있습니다.
  • 완전성을 증명할 수 없기 때문에 변조할 수 있습니다.

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

HTTPS 이름의 over Secure Socket Layer 라는 문장에서 벌써 느낌이 옵니다. 보안과 관련된 Layer를 한 단계 더 거쳐서 통신을 하는 방법입니다. 참고로 SSL(Secure Socket Layer)라는 단어는 TLS(Transport Layer Security)라는 용어로 바뀌었지만 아직 SSL이라는 명칭을 많이 사용하고 있습니다.

HTTPS 통신 Layer

이미지 출처, https://heidyhe.github.io/https/


위의 이미지에서 보이듯 HTTP 통신과 달리 HTTPS 통신은 Application 계층과 Transport 계층 사이에 Security 계층이 하나 더 존재합니다. Security 계층에서는 Application 계층에서 전달받은 메세지를 암호화하여 Transport 계층으로 내려주거나, Transport 계층에서 올라온 데이터를 Application 계층으로 복호화하여 넘겨줍니다. 다른 이미지를 통해 조금 더 쉽게 이해해보겠습니다.

HTTPS 통신 시 메세지 전달 과정

암호화 방식

일단 암호화 방식에 대해 알아야 합니다. 암호화 방식은 크게 대칭 키 방식, 비대칭 키 방식이 존재하고 HTTPS 통신은 두 개의 암호화 방식을 모두 사용합니다.

대칭 키 방식(Symmetric Key)

  • 하나의 키로 암호화 복호화를 모두 하는 암호화 방식입니다.
  • 하나의 키로 암호화, 복호화가 가능하므로 해당 키가 노출되면 보안에 문제가 발생합니다.
  • 비대칭 키 방식에 비해 속도가 빠릅니다.

이미지 출처, https://mysterico.tistory.com/30


비대칭 키 방식(Asymmetric Key)

  • 키가 두 개 존재합니다. A Key로 암호화를 하면 B Key로 복호화할 수 있습니다.
  • 반대로 B Key로 암호화하면 A Key로 복호화할 수 있습니다.
  • 두 개의 키를 모두 노출되지 않는 한 보안상 문제가 없습니다.
  • 둘 중 하나는 비공개 키(private key)로 외부에 공개하지 않고, 하나는 공개 키(public key)로 타인에게 제공합니다.
  • 속도가 느리다는 단점을 가지고 있습니다.

이미지 출처, https://mysterico.tistory.com/30/


CA(Certificate authority) 기업과 SSL 인증서

암호화 방법에 대해 설명하는 것을 보아하니 HTTPS 통신은 위의 두 가지 암호화 방식을 이용하는 것 같습니다. 그렇다면 어떤 방법을 통해 Security 계층에서는 암호화와 복호화를 수행할까요? 우선 CA(Certificate authority) 기업과 SSL 인증서가 무엇인지 알아야 합니다.

CA(Certificate authority) 기업

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

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%

SSL 인증서

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

서비스 기업들은 자신의 공개 키를 클라이언트에게 안전하게 제공하기 위해 SSL 인증서를 이용합니다. SSL 인증서는 CA(Certificate authority) 기업을 통해 만들 수 있습니다. 서비스 기업은 자신의 공개 키를 CA 기업에게 제공하고 SSL 인증서 생성을 요청합니다. CA 기업은 자신의 비공개 키로 몇 가지 정보들을 암호화 한 SSL 인증서를 만들어 서비스 기업에게 전달합니다.

SSL 인증서에는 다음과 같은 정보를 가지고 있습니다.

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

클라이언트가 브라우저를 통해 서버에 접속하면 서버는 미리 발급해놓은 암호화된 SSL 인증서 정보를 클라이언트에게 전달합니다. 클라이언트는 전달받은 SSL 인증서를 CA 기업의 공개 키로 복호화합니다. 세계적으로 신뢰할 수 있는 CA 기업의 공개 키는 이미 브라우저가 알고 있습니다.

생활 코딩
브라우저는 내부적으로 CA의 리스트를 미리 파악하고 있다. 이 말은 브라우저의 소스코드 안에 CA의 리스트가 들어있다는 것이다. 브라우저가 미리 파악하고 있는 CA의 리스트에 포함되어야만 공인된 CA가 될 수 있는 것이다. CA의 리스트와 함께 각 CA의 공개 키를 브라우저는 이미 알고 있다.

SSL 인증서를 발급해준 CA가 공인되었는지 아닌지에 따라 아래와 같은 이미지를 브라우저에서 확인할 수 있습니다.

CA 공인 여부에 따른 브라우저 메세지

이미지 출처, https://opentutorials.org/course/228/4894


SSL 인증서 발급 과정
  1. 서비스 기업은 자신의 공개 키를 CA 기업에 전달하여 SSL 인증서 생성을 요청합니다.
  2. CA 기업은 자신의 비공개 키로 서비스 기업의 공개 키와 함께 몇 가지 정보를 함께 암호화합니다.
  3. 생성한 SSL 인증서를 서비스 기업에게 전달합니다.

서버-클라이언트 SSL 인증서 전달 과정
  1. 클라이언트(브라우저)가 서버에게 데이터 요청을 합니다.
  2. 서버는 클라이언트에게 SSL 인증서를 전달합니다.
  3. 클라이언트는 자신이 관리하는 공인된 CA 목록 중에 해당 SSL 인증서를 암호화한 CA가 있는지 확인합니다.
  4. 목록에 존재하는 CA라면 클라이언트는 이미 알고 있는 해당 CA의 공개 키를 이용해 해당 인증서를 복호화합니다.

HTTPS 통신 과정

HTTPS 통신 과정에 대해 정리하기 전까지 알고 있어야하는 준비문들에 대한 정리가 끝났습니다. 이제 HTTPS 통신이 어떻게 이루어지는지 정리해보겠습니다.

Handshake

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

Session

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

Seession close

  • 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려줍니다.
  • 통신에서 사용한 대칭 키인 session key는 폐기합니다.
HTTPS 통신 과정 이미지

이미지 출처, https://mysterico.tistory.com/30

대칭 키와 비대칭 키를 모두 사용하는 이유

대칭 키는 해커에 의해 탈취 당할 경우에 서버와 클라이언트 모두 위험에 빠집니다. 대칭 키를 인터넷 상에 그대로 노출하는 것은 위험합니다. 또, 처음에 SSL 인증서를 통해 전달한 비대칭 키를 사용한 암호화, 복호화는 많은 컴퓨팅 파워를 소모하므로 비효율적입니다. 그렇기에 이 둘을 적절하게 사용하여 보안과 성능 문제를 해결합니다.

  • 최초 비대칭 키를 이용해 대칭 키를 서로 공유
  • 이후 통신은 대칭 키를 이용하여 데이텅 암호화 복호화

OPINION

HTTPS 통신에 대한 개념을 작성하려고 마음 먹은게 지난 주 목요일인데 하루 이틀 밀리다 보니 벌써 5일이나 지났습니다. 프로젝트, 공부, 공부한 내용을 정리하기까지 하루가 24시간인게 애석합니다.
Slack Chatbot 사이드 프로젝트 보완도 해야하는데…😂

HTTPS 통신 과정에는 제 생각보다 많은 내용들이 숨어있었습니다. 정리하기 전에는 ‘Secure Layer를 두어 보안을 강화한다.’ 정도로만 알고 있었는데 이런 내용들을 제 나름대로 정리하다보니 머리 속에 체계가 잡히는 듯하여 도움이 되었습니다. 또, 통신에서 대칭 키와 비대칭 키의 약점을 서로 보완하여 둘 모두를 HTTPS 통신에서 활용했다는 점이 인상 깊었습니다.

REFERENCE

카테고리:

업데이트:

댓글남기기