HTTPS 동작 방식

HTTPS란?

HTTPS는 HyperText Transfer Protocol Secure의 약자이며 HTTP의 보안 버전이다.

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

HTTPS는 TCP위에 SSL/TLS층을 추가하여 암호화 인증 및 무결성 보장을 통해 웹사이트를 안전하게 만들어주는 프로토콜이다.
이러한 HTTPS의 동작방식을 알아보기 전에 3가지 개념에 대해서 알아야 한다!!

1. 대칭키

💡 암호화와 복호화에 사용되는 키가 동일한 것

만약 클라이언트와 서버가 대칭키 방식으로 통신을 한다면 클라이언트도 대칭키를 가지고 있어야 한다.
이 경우는 클라이언트에게 키를 전달하는 것도 위험하고 클라이언트의 소스코드를 누구나 볼 수 있기 때문에 위험하다.
🤣 원거리에서 대칭키를 안전하게 전달하는 것은 어렵다!!

2. 공개키(비대칭키)

💡 공개키와 개인키(비밀키)라는 2가지 키를 가지고 있는 것

공개키는 말그대로 누구나 가질 수 있는 공개된 키를 의미한다. 정보를 보내는 쪽(클라이언트)는 이 공개키를 가지고 데이터를 암호화해서 전송한다.
개인키는 공개키로 암호화된 데이터를 복호화할 수 있는 키로써 자신(서버)만이 가지고 있는 키입니다.

🤪 이 방식은 데이터를 안전하게 송수신할 수 있다는 장점이 있지만 암호화/복호화 과정을 거치느라 속도가 느리다는 단점이 있다

3. 인증서와 CA(Certificate Authority)

SSL을 적용하기 위한 인증서를 말한다.

인증서의 내용은 크게 2가지로 구분할수 있다.

1. 서비스의 정보 (CA, 도메인)
2. 서버 측의 공개키 (공개키의 내용, 공개키의 암호화 방식

위와 같은 인증서를 발급해주는 기관을 CA라고 한다. 인증서가 보안과 관련된 만큼 CA는 영향력있고 신뢰할 수 있는 기업에서만 가능하다.

우리 브라우저는 CA리스트를 미리 가지고 있다. CA목록에 있는 기업을 공인된 CA라고 하며 목록에 없는 기업을 사설CA라고 하며 이를 통해 인증서를 발급받으면 아래와 같은 경험을 할 수 있다.

HTTPS 통신과정 및 원리

https는 대칭키와 공개키(비대칭키) 방식을 모두 사용하는 하이브리드 방식이다.
데이터를 전송하기 위해 대칭키 방식을 사용하고, 안전하게 전달하기 위해 공개키방식을 사용한다.

SSL Handshake의 목표 2가지

1. 서버와 클라이언트가 주고받을 데이터 암호화 알고리즘 결정
2. 서버와 클라이언트가 주고받을 데이터의 암호화를 위한 동일한 대칭키(데이터를 암호화하는 키)를 얻음

위 그림에서 노랑색이 SSL 인증 Handshake과정이다.
파랑색은 TCP의 3-way Handshake로 HTTPS가 TCP기반의 프로토콜이기 때문에 SSL handshake에 앞서 연결을 생성한 것이다.

 

1. Client Hello (Client - server)

• 클라이언트가 통신하고자 하는 서버로 연결을 시도하는 패킷을 전송한다.
• 이 때 전송하는 패킷에는 아래와 같은 정보들이 담겨있다.
  • 자신(client)이 사용 가능한 cipher suite 목록 (cipher suite 예시 : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA)
  • 이 cipher suite 에 어떤 프로토콜(TLS/SSL)을 사용할지, 인증서 검증 또는 데이터를 어떤 방식으로 암호화할지 등이 표시된다.
  • 세션 ID
  • SSL 프로토콜 버전, 등

2. Server Hello (Server -> Client)

• 받은 패킷에 대해 응답 전송
• 클라이언트에서 받은 cipher suite 목록 중 선택한 1개의 cipher suite
• SSL 프로토콜 버전 등과 같은 정보가 담긴 응답을 보낸다.

3. Certificate (Server -> Client)

• 서버는 2번에서 보낸 패킷 이외에도 클라이언트에게 Certificate라는 내용의 패킷을 보낸다.
• 이 Certificate안에 서버의 SSL인증서 내용이 담겨있다.

4. (Client) Server의 SSL 인증서 검증

• 3번에서 전달받은 서버의 SSL인증서를 검증한다.
• SSL 인증서를 발급한 CA(인증기관)는 CA의 비밀키(private key)를 이용해 인증서를 암호화했다. 그래서 SSL 인증서는 CA의 공개키를 이용해서만 복호화 할 수 있다. 클라이언트는 해당 CA의 공개키를 통해 암호화된 인증서를 복호화 한다. 즉, 클라이언트에서 CA 의 공개키를 이용해 인증서를 복호화했을 때, 복호화가 되었다는 것은 인증서는 해당 CA 에서 발급되었다라는 것을 검증할 수 있는 것.

그렇다면, 클라이언트는 CA 의 공개키를 어디서 구할까?

클라이언트가 브라우저 또는 안드로이드 기기일 경우에는, 인증서를 발급하는 주요 인증기관(CA)의 리스트와 공개키를 가지고 있다. 그래서 매번 CA로 요청하는 것이 아닌 가지고 있는 리스트에서 확인할 수 있다.

그러나, 리스트에 없다면 외부 인터넷을 통해 인증기관의 정보와 공개키를 확보한다. 이것이 SSL 인증서를 사용 시 인터넷 접속이 필요한 이유!

 

😀 정리!

1. 클라이언트는 인증서를 발급한 공개키를 구한다.

2. 1번에서 구한 공개키로 SSL 인증서를 복호화한다.

3. 복호화에 성공하면 SSL 인증 성공!!

5. Client ->Server (대칭키 전달)Client Key Exchange

• 이제 클라이언트는 서버와 데이터를 안전하게 주고받기 위해 데이터를 암호화해야한다.
• 이때 데이터를 암호화하기 위해 대칭키(비밀키, 암호화하는 키)를 생성한다.
• 이제 생성한 대칭키를 서버에 전달해야 한다.
• 이 대칭키를 서버만 볼 수 있게 서버의 공개키로 암호화해서 서버에게 전달한다.

6. Server / Client SSL Handshake Finished

서버는 클라이언트가 전달한 암호화된 대칭키를 받음

• 서버의 공개키로 암호화 됐기 때문에 서버의 비밀키로 복호화 가능
• 서버와 클라 둘다 동일한 대칭키를 가지고 있어 통신 가능 !

인증서 발급과정 및 원리

1. (서버) 서버의 공개키와 비밀키를 생성
2. (서버 -> CA) 인증서를 발급받기 위해 서버는 CA에다가 아래의 정보들을 전달한다.
   • 1번에서 생성한 서버의 공개키
   • 서버의 각종 정보들
3. (CA) 2번에서 서버로부터 받은 정보(공개키)들을 담아 SSL 인증서를 발급

   4. (CA) 3번에서 발급한 인증서를 암호화하기 위해 CA의 공개키와 비밀키를 생성하고 CA의 비밀키를 이용해 SSL 인증서를             암호화함
   5. (CA->Server) 4번에서 암호화한 인증서를 다시 서버로 전달 하면 SSL 인증 완성

출처 :

https://nuritech.tistory.com/25

https://mysterico.tistory.com/30