[네트워크] HTTPS의 동작원리

기존 HTTP 방식은 전송 중 데이터를 가로챈다면 누구나 데이터를 읽을 수 있다. 즉, 데이터가 암호화되지 않은 상태로 인터넷상에서 돌아다닌다는 것이다. 이러한 보안문제를 해결하기 위해 통신데이터를 암호화하여 안전하게 데이터를 통신하는 방법이 HTTPS이다. HTTPS를 사용하면 중간자 공격, 데이터 변조와 같은 위협에서도 보호받을 수 있다.

대칭키(비밀키)와 비대칭키(공개키)

HTTPS를 이용한 통신은 TCP 연결, SSL handshake, 데이터통신 세단계로 구성되어 있다. 이중 SSL handshake 단계에서는 공개키 방식을 이용하고 이후 데이터통신에서는 대칭키 방식을 이용한다.

💡 대칭키(비밀키 암호화 방식)
하나의 키로 암호화하고 복호화하는 방식이다. 이 방식은 과정이 간단하며 빠르지만 키를 분실하거나 탈취당한다면 복호화가 쉽다는 치명적인 단점이 있다.

💡 비대칭키(=공개키 암호화 방식)
비대칭키는 공개키와 개인키로 나누어져 있다. 공개키로 암호화한다면 개인키로 복호화가 가능하며 그 역도 성립한다. 공개키는 외부에서 사용할 수 있지만 개인키는 서버에서 소유함으로써 보안을 강화한다. 공개키 방식은 대칭키보다 더 안전하지만 계산 과정이 복잡하고 연산 도중 컴퓨터의 자원이 많이 사용되는 단점이 있어 대칭키와 적절히 혼합하여 사용한다. 비대칭키를 생성하는 방식으로 RSA 알고리즘이 있다.


SSL/TLS

SSL(Secure Socket Layer)와 TLS(Transport Layer Security Protocol)은 인터넷 통신에 안전한 계층을 추가하는 방식으로 이 기술을 구현하기 위해 존재하는 것이 SSL/TLS 인증서이다. TLS가 SSL보다 최신버전이지만 TLS, SSL, SSL/TLS 등 각자가 편한 이름으로 많이 부른다.


CA(Certificate Authority)

CA는 인증서를 발급해주는 인증기관이다. 사이트의 정보와 사이트의 공개키를 제공하면 인증기관에서는 CA 개인키를 이용해 암호화하여 사이트 인증서를 발급해준다. 발급한 인증서를 사용하는 클라이언트에서는 해당 CA의 공개키를 이용해서 복호화할 수 있다.

💡 Root CA
CA의 공개키가 인증된 것인지 어떻게 알 수 있을까? CA의 공개키에 대한 인증서를 발급해주는 상위 인증기관이 존재한다. 이 상위 인증기관의 차상위 계층도 존재하며 그렇게 최상단에는 Root CA가 존재한다. 이 Root CA에서는 자신의 공개키에 대한 인증서를 스스로 발급한다.


SSL Handshake

SSH Handshake의 목표는 데이터를 암호화하는 실질적인 키인 대칭키(PSK)를 서버와 공유하는 것이다. 이를 위해서 공개키(RSA, ECDHE 방식으로 생성)를 이용하여 키 교환(디피-헬만 알고리즘)하여 대칭키(PSK)를 안전하게 공유한다. SSL Handshake 과정을 순서대로 알아보자.

서버의 SSL 인증서 발급과정

  1. 서버에서 인증 서명 요청서(CSR, Certificate Signing Request) 생성
    • 서버에서 공개/개인키를 생성
    • 공개키와 서버 정보를 CA에 전달
  2. CA에서 SSL 인증서를 발급
    • 서버의 정보와 공개키를 CA의 개인키를 이용해 암호화하여 SSL 인증서를 만든다.
  3. 서버에서 SSL 인증서를 받는다.


SSL Handshake

TCP 연결이후 SSL Handshake를 통해 보안 세션을 만든다.

  1. Client -> Server
    • ClientHello
      Cipher Suite 목록, SSL 프로토콜 버전, Random Byte 등을 함께보낸다.
  2. Server -> Client
    • ServerHello
      받은 Cipher Suite 중 하나를 선택하고 응답해준다.(with SSL 프로토콜 버전)
    • Certificate
      서버의 SSL 인증서를 보낸다.
    • (Server Key Exchange)
      (어떤 키 교환 메커니즘을 사용하느냐에 따라 생략될 수도 있음) SSL 인증서 내부에 서버의 공개키가 없는 경우, 대칭키를 만드는데 사용할 재료를 보낸다.
    • ServerHelloDone
      서버의 행동종료를 알림
  3. Client -> Server
    • Certificate
      CA의 공개키를 이용해 서버 SSL 인증서를 복호화하며 유효성을 검증한다.
    • Client Key Exchange
      어떤 키 교환 메커니즘을 사용하느냐에 따라 취하는 행동이 달라진다. 복호화환 SSL 인증서 내부에 서버 공개키가 있는 경우 클라이언트에서 대칭키를 생성하고 서버 공개키를 이용해 암호화하여 서버로 보낸다.
      서버의 공개키가 없는 경우, 데이터통신을 암호화하는데 사용할 대칭키를 생성하기 위한 재료를 만들어 보낸다.
  4. 종료
    • ChangeCipherSpec, Finished
      서로가 필요한 정보를 모두 교환하였으므로 통신 준비 완료 패킷을 보내고 Handshake를 종료하게 된다.


키 교환 매커니즘

키 교환 메커니즘은 비밀키를 안전하게 공유하는 방식이다. 비밀키의 경우 공개될 경우 보안에 치명적이기 때문에 클라이언트와 서버가 이 비밀키를 교환하기 위해 키 교환 매커니즘을 사용한다. 대표적으로 RSA Key Exchange 방식과 Diffie-Hellman(디피-헬만) 방식을 이용한 키 교환 방식이 존재한다.

💡 RSA Key Exchange
공개키를 이용해 비밀키를 교환하는 방식이다. 서로가 교환한 Random byte를 이용해 클라이언트측에서 만들어 서버의 공개키로 암호화한뒤 송신한다.
(주의 RSA 암호화와 RSA key exchange 다른 것)

💡 Diffie-Hellman Key Exchange
키 자체를 교환하는 것이 아닌 키를 만들 재료를 교환하는 방식이다. 서로가 선택한 재료로 비밀키를 만들어낸다. DH, DHE, ECDHE 등이 있으며 ECDHE를 가장 많이 사용한다.


참고

카테고리:

업데이트:

댓글남기기