HTTPS

Hyper Text Transfer Protocol Secure Socket layer

HTTP는 클라이언트와 서버 간의 요청과 응답을 주고받는 프로토콜이고,
HTTPS는 HTTP 내용을 암호화하여 보안(Security)을 추가한 프로토콜입니다.

HTTPS의 암호화 과정에서는 SSL/TLS 프로토콜이 사용되며, 이를 위해 인증서, CA, 비대칭키 암호화 방식이 사용됩니다.

SSL/TLS이 제공하는 기능 :

• 암호화 (Encryption): SSL 및 TLS는 데이터를 암호화하여 전송합니다. 암호화는 데이터를 해독하기 어렵게 만들어 제3자가 데이터를 엿보거나 변조하는 것을 방지합니다.
• 인증 (Authentication): 서버의 신원을 확인하여 클라이언트가 신뢰할 수 있는 서버와 통신하고 있는지 확인합니다. 이는 인증서를 통해 이루어지며, 클라이언트는 서버의 인증서를 검증하여 서버의 신원을 확인합니다.
• 무결성 (Integrity): 데이터가 전송 중에 변경되지 않았는지를 확인합니다. 데이터에 대한 체크섬 또는 해시를 사용하여 무결성을 검증합니다.

인증서(Certificate)

인증서는 데이터를 보내준 서버가 정말 요청했던 서버에서 보낸 것이 맞는지 확인하는 목적으로 데이터 제공자의 신원을 확인하는 데 사용합니다.
인증서는 인증 기관(CA)에 의해 발급되며, CA는 서버의 신원을 검증하고 인증서에 서명하여 신뢰성을 보장합니다.

인증서에는 다음과 같은 정보가 포함됩니다

• 웹 사이트의 도메인 이름 (예: www.example.com)
• 인증서를 발급한 인증 기관(Certificate Authority, CA)의 정보
• 인증서의 유효 기간
• 웹 사이트의 공개 키 및 암호화 방식 정보

서버는 요청에 대한 응답을 할때 인증서의 정보도 같이 전송합니다. 클라이언트는 인증서의 도메인과 응답객체의 도메인이 동일한지 확인하여 같다면 신뢰할수 있다고 판단합니다. 따라서 중간자 공격(Man-in-the-Middle Attack)처럼 제 3자가 정보를 엿보거나 조작할 수 없게 합니다.
인증서는 일정 기간 동안 유효하며, 만료된 인증서는 갱신되어야 합니다. 이를 통해 웹 사이트의 신뢰성과 보안을 유지할 수 있습니다.

CA(Certificate Authority)

CA는 인증서를 발급하는 관리하는 공인된 기관입니다.

CA는 웹 사이트의 신원을 확인하고, 해당 웹 사이트가 공개 키를 소유하고 있음을 보증합니다. 웹 브라우저는 미리 신뢰할 수 있는 CA의 목록을 가지고 있으며, 서버로부터 받은 인증서가 해당 목록에 있는 CA에 의해 서명되었는지를 확인하여 신뢰할 수 있는 웹 사이트인지 판단합니다.

인증서 기관에는 VeriSign, DigiCert, GlobalSign, Symantec, Comodo 등이 있습니다.

비대칭키 암호화 방식

비대칭키 암호화 방식: 비대칭키 암호화는 공개 키와 개인 키를 사용하여 데이터를 암호화하고 복호화하는 방식입니다. 공개 키는 누구나 알 수 있지만, 개인 키는 해당 키를 소유한 개인만이 알 수 있습니다. HTTPS에서는 서버가 공개 키와 개인 키를 생성하고, 공개 키를 인증서에 포함시켜 클라이언트에 제공합니다. 클라이언트는 공개 키를 사용하여 데이터를 암호화하고 서버로 전송하며, 서버는 개인 키를 사용하여 해당 데이터를 복호화합니다. 이를 통해 데이터의 안전한 전송과 상호 인증이 이루어집니다.

공개 키 (Public Key):
공개 키는 암호화된 데이터를 복호화하는 데 사용되는 키로, 누구나 알 수 있습니다. 공개 키는 인증서에 포함되어 다른 사용자에게 제공됩니다.

개인 키 (Private Key):
개인 키는 복호화된 데이터를 암호화하는 데 사용되는 키로, 해당 키를 소유한 개인만이 알 수 있습니다. 개인 키는 안전하게 보호되어야 하며, 소유자만이 접근할 수 있어야 합니다.

공개 키로 암호화 한다면 개인 키로만 복호화 할 수 있고,
개인 키로 암호화 한다면 공개 키로만 복호화 할 수 있습니다.

비대칭키는 복호화는 한쌍의 다른 키로만 복호화되므로 안전하지만 비대칭키 알고리즘은 복잡하기 때문에 컴퓨터에 부담이 큽니다. 그래서 클라이언트와 서버가 데이터를 주고받을 때는 대칭키를 사용합니다. 그런데 대칭키를 서로 주고받는 과정에서부터 정보가 탈취된다면 모든 데이터가 복호화 가능하기 때문에 HTTPS는 이러한 대칭키를 주고받을 때는 비대칭키 방식으로 주고받도록 합니다.

HTTPS 통신 연결

이미지 출처: https://www.f5.com/labs/learning-center/what-is-mtls

1. client → server 연결을 시도한다 (Client Hello)
클라이언트가 통신하고 싶은 서버로 연결을 시도하는 패킷을 전송하면서 SSL/TLS 핸드셰이크 프로토콜이 시작됩니다. 클라이언트는 임시대칭키를 생성합니다.
패킷에는 사용 가능한 cipher suite 목록, TLS/SSL 방식선택, 데이터를 어떤 방식으로 암호화할지, session id, ssl protocol version 등의 정보가 있습니다.

2.3.4. server → client 응답 (Server Hello)
Client Hello 패킷에 대해 서버가 응답으로 Server Hello패킷을 전송합니다.
Certificate 라는 내용의 패킷에 서버의 인증서 정보와 서버의 공개키 정보를 담아 보냅니다.
그리고 클라이언트의 인증서를 요청합니다.

5. SSL 인증서 검증
클라이언트는 CA의 공개키로 인증서를 복호화하고 복호화가 된다면 인증서 검증에 성공했으니 서버의 공개키를 얻을 수 있습니다.
임시대칭키를 서버의 공개키로 암호화하여 전송하고 Change Cipher Spec을 통해 SSL/TLS Handshake의 완료를 알립니다.

6. 비밀키 생성 완료
서버는 전달받은 대칭키를 개인키로 복호화하면 이제 서버와 클라이언트 모두 동일한 대칭키(비밀키)를 갖게 되었으니 HTTPS연결이 성립되었고, 이후에는 대칭키인 비밀키를 이용해서 암호화와 복호화를 진행하면 됩니다.