[HTTPS] 2. HTTPS와 SSL/TLS 암호화

 

[HTTPS] 1. HTTP의 탄생과 위험성

[HTTPS] 1. HTTP의 탄생과 위험성

 

들어가며: '엽서'를 '비밀 편지'로 바꾸는 마법

지난 1편에서는 'S'가 없는 HTTP가 왜 '모두가 엿볼 수 있는 엽서'처럼 위험한지에 대해 알아보았습니다. 아이디, 비밀번호, 금융 정보 등 우리의 모든 데이터가 암호화되지 않은 채 네트워크를 떠돌아다니는 현실은 그 자체로 심각한 보안 위협입니다.

그렇다면 어떻게 이 불안한 엽서를 아무도 열어볼 수 없는 '견고한 금고'에 넣어 보낼 수 있을까요? 이번 2편에서는 그 해답인 HTTPS의 'S'가 실제로 어떻게 작동하는지, 그 이면의 핵심 기술 SSL/TLS와 암호화의 원리를 자세히 들여다보겠습니다.

 

1. SSL과 TLS: 인터넷 보안의 초석

HTTPS에서 'S'는 'Secure(보안)'를 의미하며, 이 보안은 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 라는 프로토콜을 통해 구현됩니다.

• SSL(Secure Sockets Layer): 1990년대 넷스케이프가 개발한 보안 프로토콜입니다. 인터넷 통신의 보안을 위해 처음으로 널리 사용되었습니다.
• TLS(Transport Layer Security): SSL이 표준화되면서 발전한 후속 버전입니다. 현재 우리가 사용하는 보안 프로토콜은 사실상 모두 TLS입니다. SSL은 오래전에 심각한 보안 취약점이 발견되어 현재는 사용되지 않습니다.

하지만 'SSL'이라는 용어가 오랫동안 통용되어 왔기 때문에, 오늘날에도 많은 사람들이 'TLS'를 'SSL' 또는 'SSL/TLS'라고 부릅니다. 이 글에서도 편의상 혼용하겠지만, 현재의 표준 기술은 TLS라는 점을 기억해 주세요.

SSL/TLS의 핵심 목표는 단 하나, "클라이언트(내 브라우저)와 서버 사이에 다른 누구도 끼어들 수 없는 안전한 통신 채널(터널)을 만드는 것" 입니다. 이 안전한 터널을 만들기 위해 '암호화'라는 기술이 사용됩니다.

 

2. 암호화의 두 가지 얼굴: 대칭키와 비대칭키

암호화는 데이터를 특정 '키(Key)'를 사용해 아무나 읽을 수 없는 형태로 바꾸는 과정입니다. SSL/TLS는 목적에 따라 두 가지 종류의 암호화 방식을 아주 영리하게 조합하여 사용합니다.

1) 대칭키(Symmetric Key) 암호화

• 개념: 하나의 동일한 키로 데이터를 암호화하고 복호화(암호를 푸는 것)합니다.
• 비유: '집 열쇠'나 '금고 열쇠'와 같습니다. 이 열쇠를 가진 사람은 누구든 문을 잠글 수도, 열 수도 있습니다.
• 장점: 암호화 및 복호화 속도가 매우 빠릅니다.
• 단점: 치명적인 '키 배송 문제'가 있습니다. 데이터를 안전하게 주고받기 위해 상대방에게 이 '대칭키'를 전달해야 하는데, 암호화되지 않은 인터넷에서 키를 그냥 보내는 것은 '집 열쇠를 문밖에 걸어두는' 것과 마찬가지입니다.
  
  

2) 비대칭키(Asymmetric Key) 암호화

• 개념: 서로 다른 두 개의 키가 한 쌍으로 존재합니다. 하나는 '공개키(Public Key)', 다른 하나는 '개인키(Private Key)'라고 부릅니다.
• 비유: '자물쇠와 열쇠 세트' 또는 '개인 우체통'과 같습니다.
  • 공개키 (자물쇠): 세상 누구에게나 나눠줄 수 있는 '자물쇠'입니다. 누구나 이 자물쇠로 제 상자를 잠글 수 있습니다.
  • 개인키 (열쇠): 이 자물쇠를 열 수 있는 '열쇠'는 세상에 오직 저만 가지고 있습니다. 절대 남에게 보여주지 않습니다.
• 작동 방식: 공개키로 암호화한 데이터는 오직 그 쌍을 이루는 개인키로만 복호화할 수 있습니다. 반대의 경우도 마찬가지입니다.
• 장점: '키 배송 문제'를 완벽하게 해결합니다. 안전하게 전달하고 싶은 정보가 있다면, 상대방의 '공개키(자물쇠)'를 가져와 잠가서 보내기만 하면 됩니다. 그 내용은 상대방의 '개인키(열쇠)'가 없으면 절대 열어볼 수 없습니다.
• 단점: 암호화 및 복호화 과정이 매우 복잡하여 대칭키 방식보다 속도가 훨씬 느립니다.

 

3. 최고의 조합: TLS 핸드셰이크(Handshake)의 작동 원리

HTTPS는 속도가 빠른 '대칭키'의 장점과, 키 배송이 안전한 '비대칭키'의 장점을 모두 취하는 아주 영리한 방법을 사용합니다. 이 과정을 'TLS 핸드셰이크(악수)' 라고 부릅니다. 본격적인 대화를 나누기 전에, 서로의 신원을 확인하고 안전한 통신 규칙을 정하는 과정이죠.

복잡해 보이지만, 아래 단계로 간단히 이해할 수 있습니다.

1. Client Hello (클라이언트의 첫인사)
   • 브라우저가 서버에 접속하며 말합니다. "안녕하세요! 저와 안전한 대화를 시작하시죠. 제가 사용할 수 있는 암호화 방식은 이런 것들이 있습니다."
2. Server Hello & Certificate (서버의 응답과 신분증 제시)
   • 서버가 응답합니다. "반갑습니다. 그럼 우리 그중에서 이 방식으로 암호화하죠."
   • 그리고 가장 중요한 것, 자신의 신분을 증명하는 '디지털 인증서(Digital Certificate)' 를 브라우저에 전달합니다. 이 인증서 안에는 서버의 '공개키(자물쇠)' 가 들어있습니다.
3. Client's Verification & Key Exchange (클라이언트의 신분 확인과 비밀 전달)
   • 브라우저는 서버로부터 받은 '디지털 인증서'가 신뢰할 만한 것인지 확인합니다. (이 과정은 3편에서 자세히 다룹니다.)
   • 인증서가 진짜임을 확인하면, 브라우저는 이제부터 서버와 데이터를 주고받을 때 사용할 '대칭키(이번 대화에서만 사용할 비밀 열쇠)' 를 하나 새로 만듭니다.
   • 그리고 이 '대칭키'를 아까 서버에게서 받은 '공개키(자물쇠)'로 안전하게 암호화하여 서버에게 다시 보냅니다.
4. Handshake Complete & Encrypted Communication (악수 완료 및 암호화 통신 시작)
   • 서버는 암호화되어 전달된 꾸러미를 자신이 가진 '개인키(나만 가진 열쇠)' 로 복호화합니다. 이제 서버도 클라이언트가 만든 '대칭키'를 갖게 되었습니다.
   • 이제 클라이언트와 서버, 둘 다 동일한 '대칭키'를 안전하게 공유했습니다.
   • TLS 핸드셰이크는 여기서 끝나고, 이후의 모든 통신은 속도가 빠른 이 '대칭키'를 이용해 암호화되어 빠르고 안전하게 이루어집니다.

 

결론: 빠르고 안전한 통로의 완성

정리하자면, HTTPS는 무작정 모든 데이터를 느린 비대칭키로 암호화하는 것이 아닙니다.

비대칭키(공개키 방식) 는 실제 데이터를 주고받기 위한 '대칭키'를 안전하게 전달하는 단 한 번의 목적을 위해 사용하고, 실제 데이터 통신은 속도가 빠른 '대칭키' 를 이용하는 것입니다.

이 영리한 'TLS 핸드셰이크' 과정을 통해, 1편에서 말했던 불안한 '엽서'는 우리 눈에 보이지 않는 빠르고 안전한 '비밀 통로'를 통해 전달되는 '비밀 편지'로 탈바꿈합니다.

하지만 여기서 마지막 질문이 남습니다. 브라우저는 서버가 제시한 '디지털 인증서'와 그 안의 '공개키'가 정말 진짜라고 어떻게 믿는 걸까요? 해커가 만든 가짜 인증서라면 이 모든 과정이 무용지물이 될 테니까요.

 

다음 편 예고: [3편] 보이지 않는 신뢰의 보증서, 인증 기관(CA) - 이 모든 신뢰의 기반이 되는 '디지털 인증서'와 이를 발급하고 보증하는 '인증 기관(CA)'에 대해 알아보며 시리즈를 마무리하겠습니다.