HTTPS 동작 원리

[jaejae-yoo]

대칭키와 공개키 비교

• 대칭키 암호법
  • 암호화할 때 사용하는 키와 복호화할 때 사용하는 키가 같다.
  • 발송자와 수신자 모두 통신을 위해 비밀 키를 똑같이 공유한다.
• 공개키 암호법
  • 두 개의 비대칭 키를 사용한다.
  • 하나는 호스트의 메시지를 암호화하기 위한 것이며, 다른 하나는 그 호스트의 메시지를 복호화 하기 위한 것이다.
    • 암호화 키는 모두에게 공개되어 있지만, 개인 복호화 키는 호스트만이 알고 있다.

혼성 암호 체계

• 비대칭 공개키 암호 방식은 누구나 공개키를 알면 그 키에 대응되는 공개 서버에 안전하게 메시지를 보낼 수 있게 해준다.
  • 그러나 공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있다.
• 따라서 실제로는 대칭과 비대칭 방식을 섞어서 쓴다.
  • 노드들 사이의 안전한 의사소통 채널을 수립할 때는 편하게 공개키 암호화 방식을 사용하고, 이렇게 만들어진 안전한 채널을 통해, 임시의 무작위 대칭키를 생성하고 교환하여 이후의 나머지 데이터를 암호화할 때는 빠른 대칭 키를 사용하는 방식이 흔히 쓰인다.

디지털 서명

• 디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다.
  - 서명은 메시지를 작성한 저자가 누구인지 알려준다.
  - 저자는 저자의 극비 개인 키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다.
  - 체크섬은 저자의 개인 ‘서명'처럼 동작한다.
  - 서명은 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신중인 메시지를 수정했다면, 체크섬은 해당 메시지와 맞지 않게 될 것이다.
• 디지털 서명은 보통 비대칭 공개키에 의해 생성된다.
• 개인 키는 오직 소유자만이 알고 있기 때문에, 저자의 개인 키는 일종의 ‘지문'처럼 사용된다.

디지털 인증서

• 대상의 이름(사람, 서버 조직 등)
• 유효 기간
• 인증서 발급자(누가 이 인증서를 보장하는가)
• 인증서 발급자의 디지털 서명

HTTPS

• HTTPS를 사용할 때, 모든 HTTP 요청과 응답 데이터는 TCP로 보내기 전에 먼저 암호화하는 보안 계층으로 보내서 암호화한다.

  • HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데, 이 보안 계층은 안전 소켓 계층(Secure Sockets Layer, SSL) 혹은 전송 계층 보안(Transport Layer Security, TLS)을 이용하여 구현된다.
    • SSL과 TLS는 매우 비슷하다.

• HTTPS는 TCP위에 놓인 보안 계층 위의 HTTP이다.

• HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다.

• 만약 URL이 HTTP 스킴을 갖고 있다면, 클라이언트는 서버에 80번 포트로 연결하고 평범한 HTTP 명령을 전송한다.

• 만약 URL이 HTTPS 스킴을 갖고 있다면, 클라이언트는 서버에 443 포트로 연결하고 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 ‘핸드셰이크'를 하고, 암호화된 HTTP 명령이 뒤를 잇는다.

보안 전송 셋업 과정

1. 클라이언트는 먼저 웹 서버의 443 포트(보안 HTTP의 기본 포트)로 연결한다.
2. TCP 연결이 되고 나면, 클라이언트와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화한다(핸드 셰이크).
3. 핸드 셰이크가 완료되면 SSL 초기화는 완료되며, 클라이언트는 요청 메시지를 보안 계층에 보낼 수 있다.

1) 암호화되지 않은 HTTP 트랜잭션

1.1) 서버의 80 포트로 TCP 커넥션 연결
1.2) TCP를 통해 보내진 HTTP 요청
1.3) TCP를 통해 보내진 HTTP 응답
1.4) TCP 커넥션 닫힘

2) 암호화된 HTTPS 트랜잭션

 2.1) 서버의 443 포트로 TCP 커넥션 연결
 2.2) SSL 보안 매개변수 핸드셰이크
 2.3) SSL과 HTTP 요청/TCP를 통해 보내진 암호화된 요청
 2.4) SSL과 HTTP 요청/TCP를 통해 보내진 암호화된 응답
 2.5) SSL 닫힘
 2.6) TCP 커넥션 닫힘

SSL 핸드 셰이크

암호화된 HTTP 메시지를 보내기 전에, 클라이언트와 서버는 SSL 핸드셰이크를 해야 한다.

SSL 핸드 셰이크 과정

1. TCP 연결을 위한 3-way-handshake를 수행한 클라이언트(브라우저)가 HTTPS를 사용하는 것을 알게 되면, 서버에게 다음 정보를 보냅니다.

   • 클라이언트가 지원하는 암호화 방식 모음

   • 클라이언트가 생성한 랜덤 데이터

   • 이전에 SSL 핸드 셰이크가 완료된 상태라면, 그때 생성된 Session ID

2. 서버는 위 요청에 대한 정보를 클라이언트에게 전송합니다.

   • 클라이언트의 암호화 방식 정보 중에서, 서버가 지원하고 선택한 알고리즘 방식

   • SSL 인증서

   • 서버가 생성한 랜덤 데이터

3. 클라이언트는 SSL 인증서를 검증한다.

   • 클라이언트는 서버가 보낸 SSL 인증서가 CA가 만든 것인지 CA 공개키로 인증서를 복호화하여 검증합니다.

4. 클라이언트는 자신이 생성한 랜덤 데이터와 서버의 랜덤 데이터를 사용하여, premaster secret 키를 만들어 서버에 전송합니다.

   • 웹 인증서에있는 서버의 공개키로 premaster secret를 암호화하여 서버로 전송합니다.

   • premaster secret: 암호화 통신에 사용될 대칭키 (대칭키이므로 절대 노출되면 안된다.)

5. 서버는 비밀키로 premaster secret을 복호화합니다.

   • master secret : 복호화한 값

   • master secret으로 Session Key를 생성합니다. Session Key는 클라이언트와 서버 사이의 데이터를 주고받을 때 사용할 대칭키입니다.

6. 서버와 클라이언트는 Session Key를 사용해서 대칭키 방식으로 데이터를 주고 받습니다.

---

Rerefrences

HTTP 완벽 가이드 웹은 어떻게 동작하는가, 데이빗 고울리 외 4인, 2014
https://brunch.co.kr/@sangjinkang/38

[tco0427]

좋은 자료 공유 감사합니다!!
천천히 읽어보고, 궁금한점 comment 달게요!