HTTPS(TLS) 통신 과정

기본개념

1.  HTTPS, SSL, TLS

SSL은 원래 넷스케이프(Netscape)에서 개발된 보안 프로토콜로, 1995년에 최초 버전인 SSL 1.0이 발표되었습니다. 그러나 SSL 1.0과 SSL 2.0은 보안 취약점이 존재하여 실제로는 널리 사용되지 않았습니다. 이후 SSL 3.0이 개발되어 1996년에 발표되었고, 상대적으로 안전하며 일반적으로 사용되었습니다. 그러나 SSL 3.0도 보안 취약점이 발견되어 안전하지 않은 것으로 인식되었습니다.

그 후 SSL의 기반을 유지하면서 새로운 프로토콜인 TLS가 개발되었습니다. TLS는 1999년에 최초 버전인 TLS 1.0이 발표되었고, 이후 TLS 1.1, TLS 1.2, TLS 1.3 등의 버전이 발표되었습니다. TLS는 SSL과 기능적으로 거의 동일하며, 더욱 강력한 보안과 성능을 제공합니다. 따라서 현재는 TLS가 SSL보다 널리 사용되고 있습니다.

 

TLS와 SSL은 주로 웹 서버와 클라이언트 간의 통신에서 사용되며, HTTPS 프로토콜을 통해 보안된 연결을 구축합니다. 이를 위해 공개키 기반의 암호화 기법과 대칭키 암호화 기법을 혼합하여 사용합니다. TLS/SSL은 웹 브라우저와 웹 서버 간의 핸드셰이크 과정을 통해 공개키를 교환하고, 이후의 통신은 대칭키 암호화를 사용하여 데이터를 암호화하고, 해시 함수를 사용하여 데이터의 무결성을 보호합니다.

 

2.  해시함수, 공개키, 대칭키

해시함수, 공개키, 대칭키는 모두 암호학(Cryptography)에서 사용되는 중요한 개념들입니다. 암호학에서는 해시함수, 공개키, 대칭키가 각각 다른 목적과 특징을 가지고 있으며, 이를 적절하게 조합하여 보안성을 확보하는 것이 중요합니다.

해시함수는 임의의 길이의 데이터를 고정된 길이의 해시 값으로 변환하는 함수입니다. 해시 함수는 입력 데이터를 일방향으로 변환하므로, 해시 값을 이용하여 원래 데이터를 복원하는 것은 거의 불가능합니다. 좋은 해시 함수는 다음과 같은 특징을 가집니다.

• 충돌 저항성(Collision Resistance): 서로 다른 입력에 대해 동일한 해시 값이 생성되는 충돌을 찾기 어렵습니다.
• 일방향성(One-way): 해시 값을 통해 원래 데이터를 역추적하는 것은 어렵습니다.
• 고정 길이 출력: 어떤 크기의 입력도 항상 동일한 길이의 해시 값으로 변환됩니다.

 

해시 함수는 데이터의 무결성 검증, 비밀번호 저장, 디지털 서명 등 다양한 암호학적 용도로 사용됩니다.

대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 암호화 기법입니다. 즉, 암호화와 복호화에 동일한 키를 사용하므로, 키를 안전하게 공유하는 것이 중요합니다.

대칭키 암호화는 공개키 암호화보다 빠르고 효율적이지만, 대칭키를 안전하게 공유하는 문제가 있습니다. 대칭키 암호화는 주로 대량의 데이터를 빠르게 암호화하는 데에 사용되며, TLS/SSL 프로토콜과 같은 보안 통신에서 데이터 암호화에 사용됩니다.

공개키 암호화는 암호화와 복호화에 서로 다른 키를 사용하는 암호화 기법입니다. 두 개의 키 중 하나는 공개키(public key)로, 다른 하나는 개인키(private key)로 알려져 있어야 합니다. 공개키는 누구나 알 수 있으며, 개인키는 해당 키의 소유자만이 알고 있어야 합니다.

공개키 암호화는 데이터를 공개키로 암호화하면, 해당 데이터는 개인키로만 복호화할 수 있습니다. 이를 통해 데이터의 기밀성을 보장할 수 있습니다. 또한, 개인키로 암호화하면, 해당 데이터는 공개키로만 복호화할 수 있으므로, 데이터의 출처를 인증하는 데에도 사용됩니다. 주로 디지털 서명과 인증에 사용됩니다.

 

3. 디피-헬먼(Diffie-Hellman) 키 교환 알고리즘

디피-헬먼(Diffie-Hellman) 키 교환 알고리즘은 공개키 기반의 키 교환 알고리즘 중 하나로, 암호학에서 중요한 역할을 하는 알고리즘입니다. 디피-헬먼 알고리즘은 1976년에 Whitfield Diffie와 Martin Hellman에 의해 개발되었습니다.

​

디피-헬먼 키 교환 알고리즘은 두 사용자가 상호 독립적으로 비밀 키를 공유하지 않고, 공개 통신 경로를 통해 비밀 키를 합의하는 방식으로 작동합니다. 이 알고리즘은 주로 공개적인 네트워크(예: 인터넷)에서 암호 통신을 수행하는데 사용되며, 주요 목적은 안전한 통신을 위해 대칭키를 교환하는 것입니다.

 

이러한 방식으로 디피-헬먼 키 교환 알고리즘을 사용하면, 두 사용자는 비밀 정보를 공유하지 않고도 안전하게 대칭키를 합의할 수 있습니다. 이렇게 합의된 대칭키는 이후에 대칭키 암호화를 사용하여 데이터를 보호하는데 사용됩니다.

 

 

HTTPS 통신 과정

1.  [STEP1]  TCP/IP 핸드셰이크

• 이 부분은 이번 포스팅 주제에서 벗어나므로 생략하겠습니다.

2. [STEP2]  TLS 핸드셰이크

2-1.  서버 신뢰성 확인

• 서버의 디지털 인증서는 서버의 공개키와 서버 정보(도메인 등)을 포함하고 있으며, 신뢰할 수 있는 인증 기관(Certificate Authority, CA)에 의해 서명됩니다.
• 클라이언트(일반적으로 웹 브라우저)는 서버로부터 받은 인증서를 검증하여 인증서의 유효성과 서버의 신원을 확인합니다.
• 인증서가 유효하고 신뢰할 수 있는 CA에 의해 서명된 경우, 서버의 신뢰성이 높습니다.
• 인증서에는 발행자의 디지털 서명이 있고, 그 발행자의 인증서를 취득함으로써 서명을 검증할 수 있습니다. 그리고 다시 상위 발행자의 인증서도 차례로 검증해가면 최종적으로 발행자와 주체자가 동일한 인증서가 나오고 이것을 루트 인증기관이라고 합니다.
• 루트 인증기관의 신뢰성은 브라우저와 OS에는 미리 신뢰할 수 있는 인증기관의 인증서가 설치되어 있고, 이 인증서와 대조함으로써 최종적으로 서버가 승인된 것임을 확인하여 루트 인증기관의 신뢰성을 보증합니다.

2-2. 대칭키 교환

• 공개 키 암호를 사용하는 방법과 키 교환 전용 알고리즘이 있습니다.
• 공개 키 암호를 사용하는 방법은 서버 인증서에 첨부된 공개 키로 통신용 공통 키를 암호화해 그 키를 서버에 보냅니다.
• 키 교환 전용 알고리즘은 어느 한 쪽이 완전한 키를 만들어 상대에 넘기는 것이 아니라, 키를 생성할 시드를 클라이언트와 서버 양쪽에서 하나씩 만들어 서로 교환해서 계산한 결과가 공통 키가 됩니다.(디피-헬먼(Diffie-Hellman) 키 교환 알고리즘)
• 공개 키 암호를 사용하는 방법은 키 교환 통신 내용이 모두 기록된 경우, 서버의 비밀키가 유출될 경우 기록된 통신 내용도 해독될 가능성이 있습니다. 키 교환 전용 알고리즘은 동적으로 계산되고 파일로 저장되지 않기 때문에 키가 유출될 일이 없습니다.​

3. [STEP3]  HTTP 요청

• 기밀성과 무결성(조작 방지)를 위해 교환한 대칭키를 이용해 암호화 통신합니다.

 

 

 

HTTPS 통신 고속화

1. RTT

• TCP/IP 핸드셰이크는 1.5RTT, TLS 핸드세이크는 2RTT, HTTP 요청은 1RTT 소요됩니다. TCP/IP 핸드셰이크 마지막의 0.5RTT와 그 후 TLS의 최초 통신은 함께 이루어지기 때문에 총 4RTT 소요가 소요됩니다.
• RTT(Round Trip Time)는 네트워크 통신에서 사용되는 지연 시간의 측정 단위입니다. RTT는 데이터가 송신자로부터 수신자까지 전송되고 돌아오는데 소요되는 시간을 측정합니다. 즉, 패킷이 1회 왕복하는 시간을 1RTT라고 합니다.
• 통신에서 전기 신호가 서버에 도덜하고 응답이 되돌아오기까지의 시간은 매우 긴 시간이므로 인터넷을 더 빠르게 하려면 왕복 시간을 줄이는 것이 중요합니다. 이를 위한 장치가 몇 가지 구현되어 있습니다.

2.  고속화를 위한 방법

• Keep-Alive : 세션이 지속되므로 최초 요청 이후의 통신에는 대칭키 교환 과정없이 바로 통신하여 1RTT만 소요
• 세션 재개 기능 : 최초의 핸드셰이크에서 전에 사용하던 세션ID을 보내면 이후의 키 교환이 생략되어 1RTT로 세션 재개
• QUIC : TLS 아래 전송 계층에서 TCP가 아닌 UDP를 사용하여 TCP/IP 핸드셰이크 단계를 생략
• SSL 가속기 : TLS 계산 부하가 커서 고속화를 위해 사용하는 하드웨어 제품