HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🤩
개발/네트워크(Network)/
HTTPS 스스로 정리

HTTPS 스스로 정리

HTTPS보안 전송 셋업(SSL 핸드 쉐이크와 요청/응답 암호화)SSL 핸드쉐이크암호키대칭키 암호화 방식(Symmetric Key)공개키 암호화 방식(Asymmetric Key)디지털 서명디지털 인증서암호 모음(Cipher Suite)

HTTPS

HTTPS 를 사용할 때 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
이 HTTPS 는 HTTP 의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데,
  • 이 보안 계층은 안전 소켓 계층(Secure Sockets Layer, SSL) 혹은
  • 그를 계승한 전송 계층 보안(Transport Layer Security, TLS)를 이용하여 구현된다
  • SSL과 TLS 은 매우 비슷하다
  • 요청을 전송하면 HTTP 계층을 지나 SSL or TLS 계층에서 암호화를 하고 TCP를 통해 데이터를 전송하게 된다.
    • 어려운 인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 안에서 일어나기에 웹 클라이언트와 서버가 프로토콜을 처리하는 로직을 크게 변경할 필요 없다.
notion image

보안 전송 셋업(SSL 핸드 쉐이크와 요청/응답 암호화)

HTTP에서는 TCP 핸드쉐이크 만을 통해 커넥션을 수립하고 요청/응답을 주고 받는다.
그러나 HTTPS에서는 TCP 커넥션을 수립한 후 SSL Handshake를 통해 SSL 초기화를 수행하고 클라이언트는 요청 메시지를 보안 계층에 보낼 수 있게 된다.

SSL 핸드쉐이크

보안 계층을 수립하기 위한 클라이언트와 서버 간에 데이터를 주고 받는 과정
  1. 클라이언트가 암호(Cipher Suites) 후보들을 보내고 인증서를 요구한다.
  1. 서버는 선택된 암호(Cipher Suites)를 보내고 서버에 있는 인증서(공개키 포함)를 보낸다.
  1. 클라이언트는 받은 인증서를 자신이 갖고 있는(OS나 웹브라우저에 포함되어 있음) 인증서 정보와 비교하여, 서버의 인증서의 서명 값을 검증함 ⇒ 검증 완료되면 해당 인증서는 믿을만하다는 것. 서버를 신뢰할 수 있다는 것.
  1. 검증이 되었다면 클라이언트는 요청/응답을 암호화(대칭키 암호화)할 대칭키를 생성하고 서버의 인증서의 공개키 로 대칭키를 암호화해서 전송함
  1. 서버는 클라이언트가 보내온 암호화된 대칭키를, 자신의 개인키(인증서의 공개키에 대응되는 개인키)로 복호화 하여 대칭키를 얻어냄
 
해당 대칭키를 이용하여 보안 계층에서 요청/응답 데이터를 암호화하는 것임
결국 HTTP를 암호화 한다는 이야기는 서버와 클라이언트 간에 대칭키를 공유한다는 이야기
 

암호

텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘, 나중에 그 비밀 메시지를 디코딩하는 방법 암호가 적용되어 코딩된 메시지는 보통 암호문이라 불림

키

암호의 동작을 변경하는 숫자로 된 매개변수
 

대칭키 암호화 방식(Symmetric Key)

  • 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
  • 발송자와 수신자 모두 통신을 위해 비밀 키 k를 똑같이 공유할 필요가 있음.
    • 발송자는 공유된 비밀 키를 사용해 메시지를 암호화하고 결과로 나온 암호문을 발송함
    • 수신자는 역시 암호문을 받은 뒤 같은 공유된 키를 사용하여 원래의 평문을 복원하기 위해 함수를 적용함
  • 잘 알려진 대칭키 암호 알고리즘으로는 DES, Triple-DES, RC2, RC4 등이 있음
  • 대칭 키 암호의 단점 중 하나는 발송자와 수신자가 서로 대화하려면 둘다 공유키를 가져야 한다는 것임.
    • 만약 누군가가 은밀하게 대화를 나누고 싶다면 먼저 서버 측과 개인키를 발급해야 하고, 그렇게 은밀하게 대화를 나누는 사람 별로 개인키를 하나씩 다 발급해야 할 것임 → 관리해야 하는 키가 너무 많아짐

공개키 암호화 방식(Asymmetric Key)

  • 한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호화 방식은 두 개의 비대칭 키를 사용함
  • 하나는 호스트의 메시지를 인코딩하기 위한 것이며 다른 하나는 그 호스트의 메시지를 디코딩하기 위한 것임.
  • 인코딩 키는 모두를 위해 공개되어 있다(그래서 공개키 암호 방식이라는 이름이 붙음)
    • 하지만 호스트만이 개인 디코딩 키를 알고 있다.
  • 그래서, 모든 사람이 X에게 보내는 메시지를 같은 키로 인코딩할 수 있지만, X 를 제외한 그 누구도 해당 메시지를 디코딩할 수 없다. (오직 X 만이 디코딩 개인 키를 갖고 있기 때문)
    • 키의 분리는, 메시지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메시지를 디코딩하는 능력은 소유자에게만 부여한다.

디지털 서명

암호 체계는 메시지를 암호화하고 해독하는 것 뿐 아니라, 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 하는 데에 이용될 수 있다.
서명하는 과정
  1. 노드 A 는 가변 길이 메시지를 정제하여 고정된 길이의 요약(digest)으로 만든다. (Message Digest, eg. MD5)
  1. 노드 A는 그 요약에, 사용자의 개인 키를 매개변수로 하는 ‘서명’ 함수를 적용한다.(암호화)
    1. 오직 그 사용자만이 개인 키를 알고 있기 때문에, 올바른 서명 함수는 서명자가 소유자임을 보여준다.
  1. 한번 서명이 계산되면 노드 A 는 그것을 메시지에 끝에 덧붙이고 메시지와 그에 대한 서명 둘 다를 노드 B에게 전송
  1. 메시지를 받은 노드 B가 만약 그 메시지를 쓴 것이 정말로 노드 A이며 동시에 위조되지도 않았다는 것을 확인하기 원한다면, 노드 B 는 서명을 검사할 수 있다
    1. 노드 B 는 개인키로 암호화된 서명에 공개키를 이용한 역함수를 적용한다.
    2. 만약 풀어낸 요약이 노드 B 가 갖고 있는 버전의 요약과 일치하지 않는다면, 메시지가 송신 중에 위조되었거나 아니면 발송자가 노드 A의 개인키를 갖고 있지 않은 것(⇒ 메시지를 쓴것이 노드 A 가 아니게 되는것)
 

디지털 인증서

디지털 인증서(certs 라고 불리는)는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다.
 
인증서의 내부
디지털 인증서에는 공식적으로 ‘인증 기관’에 의해 디지털 서명된 정보의 집합이 담겨있다. 기본적인 디지털 인증서는 보통 다음과 같이 기본적인 것들을 담고 있다.
  • 대상의 이름(사람, 서버, 조직 등)
  • 유효 기간
  • 인증서 발급자(누가 이 인증서를 보증하는가)
  • 인증서 발급자의 디지털 서명
 
추가적으로 디지털 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보 뿐 아니라 보통 대상의 공개키도 담고 있다.
chrome의 인증서 리스트 확인 방법
chrome://settings로 이동합니다.
1. 왼쪽에서 개인 정보 보호 및 보안을 클릭합니다. 2. 보안을 클릭합니다. 3. 고급까지 스크롤합니다. 4. 인증서 관리를 클릭합니다. 5. 목록에서 새로 추가된 CA를 찾습니다.
일반적인 디지털 인증서의 포맷 (Ref. HTTP 완벽 가이드)
일반적인 디지털 인증서의 포맷 (Ref. HTTP 완벽 가이드)

암호 모음(Cipher Suite)

암호 모음 형식 Kx-Au-Enc-Mac
  • 키 교환(Kx)할때 사용하는 공개키 암호화 알고리즘 : RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman,
  • 서명 인증(Au) 디지털 서명 알고리즘 RSA, Diffie-Hellman, DSS, ECDSA, ...
  • 대칭 키 암호화 (Enc) AES128-CBC, AES256-GCM, ..
  • 메시지 다이제스트 (Mac) MD5, SHA, SHA1, SHA256, SHA384
예시
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • AES256-SHA