[웹사이트 구축 지식] HTTPS 그 것들 (1) HTTPS 원칙 (재인쇄)

루머 크러셔는 며칠 전에 "공용 와이파이로 인터넷 접속이 은행 계좌 보안을 위협할까요?"라는 글을 발표했습니다. 이 기사는 네트워크 암호화 전송을 위한 HTTPS 사용 시 몇 가지 상황을 소개하며, 답변을 보면 여전히 논란이 남아 있는 것으로 보입니다. 인터넷이 점점 더 대중화되면서 애플리케이션이 점점 더 널리 퍼지고 있으며, 네트워크 보안 문제들도 네티즌들의 관심을 끌 것입니다. 여기서는 TLS/SSL, 즉 우리가 흔히 HTTPS라고 부르는 개념에 대해 원리부터 실제 애플리케이션까지 이야기하며, HTTPS 및 관련 보안 기법을 사용할 때 주의해야 할 문제점들을 살펴보겠습니다.

사이버보안은 개인용 컴퓨터, 프로토콜, 데이터 전송, 소프트웨어 개발 회사와 웹사이트의 보안을 포함하는 총체적인 사건입니다. 앞으로 보안 관련 문제를 조금씩 설명함으로써 더 많은 사람들이 네트워크 보안을 이해하고 네트워크를 더 안전하게 사용할 수 있기를 바랍니다.

이 글은 길어질 것이며, 당분간은 세 부분으로 나눌 계획입니다:

첫 번째 부분은 주로 HTTPS의 원리를 설명합니다; 두 번째 부분은 주로 SSL 인증서 검증 과정과 사용 시 몇 가지 주의사항을 설명합니다. 세 번째 부분에서는 HTTPS 공격의 몇 가지 사례를 소개합니다.

HTTPS에 대해 이야기하기 전에, HTTP가 무엇인지 이야기해 봅시다. HTTP는 우리가 웹을 탐색할 때 보통 사용하는 프로토콜입니다. HTTP 프로토콜이 전송하는 데이터는 암호화되지 않았으며, 즉 평문으로 전송되기 때문에 HTTP 프로토콜을 통해 개인 정보를 전송하는 것은 매우 위험합니다. 이러한 개인 데이터가 암호화되고 전송될 수 있도록 하기 위해, 넷스케이프는 HTTP 프로토콜이 전송하는 데이터를 암호화하는 SSL(Secure Sockets Layer) 프로토콜을 설계했고, 이로써 HTTPS가 탄생했습니다. 현재 SSL 버전은 3.0으로, IETF(인터넷 엔지니어링 태스크포스)가 RFC 6101에서 정의했으며, 이후 IETF가 SSL 3.0을 업그레이드하여 TLS(전송 계층 보안) 1.0이 RFC 2246에 정의되었습니다. 사실 현재 HTTPS는 TLS 프로토콜이지만, SSL이 비교적 일찍 등장했고 현재 브라우저에서도 지원되기 때문에 SSL은 여전히 HTTPS와 동의어입니다. 하지만 TLS인지 SSL인지는 지난 세기의 문제이고, SSL 마지막 버전은 3.0이며, TLS는 앞으로도 암호화 서비스를 계속 제공할 것입니다. 현재 TLS 버전은 RFC 5246에 정의된 1.2이며, 아직 널리 사용되지는 않습니다.

역사에 관심 있는 분들은 TLS/SSL에 대한 상세한 설명이 담긴 http://en.wikipedia.org/wiki/Transport_Layer_Security 을 참고하실 수 있습니다.

답은 네, 안전하다는 것입니다. 앞으로 몇 주 내에 구글은 전 세계 모든 로컬 도메인에 HTTPS를 활성화할 예정이며, 사용자는 검색 전에 구글 계정으로 로그인하기만 하면 되고, 모든 검색 작업은 TLS 프로토콜로 암호화될 예정입니다. 자세한 내용은 다음과 같습니다: http://thenextweb.com/google/2012/03/05/google-calls-for-a-more-secure-web-expands-ssl-encryption-to-local-domains/.

HTTPS는 데이터를 전송하기 전에 클라이언트(브라우저)와 서버(웹사이트) 간에 핸드셰이크를 요구하며, 양측의 비밀번호 정보는 핸드셰이크 과정에서 설정됩니다. TLS/SSL 프로토콜은 단순한 암호화된 전송 프로토콜 집합이 아니라, 비대칭 암호화, 대칭 암호화, 해시 알고리즘을 사용하여 예술가들이 신중하게 설계한 예술 작품이기도 합니다. 악수 과정의 간단한 설명은 다음과 같습니다:

   4. 브라우저로부터 데이터를 받은 후, 웹사이트는 다음과 같은 작업을 수행합니다:

   5. 브라우저는 핸드셰이크 메시지의 HASH를 복호화하고 계산하며, 서버가 보낸 HASH와 일치하면 핸드셰이크 과정이 종료되고, 모든 통신 데이터는 이전 브라우저가 생성한 임의 비밀번호와 대칭 암호화 알고리즘으로 암호화됩니다.

여기서 브라우저와 웹사이트는 서로 암호화된 악수 메시지를 보내고 확인하여 양측이 동일한 비밀번호를 획득했는지, 데이터를 정상적으로 암호화 및 복호화할 수 있는지 확인하고, 실제 데이터 전송에 대한 테스트를 수행합니다. 또한, HTTPS에서 일반적으로 사용되는 암호화 및 HASH 알고리즘은 다음과 같습니다:

그중 비대칭 암호화 알고리즘은 악수 과정에서 생성된 비밀번호를 암호화하는 데 사용되고, 대칭 암호화 알고리즘은 실제 전송된 데이터를 암호화하며, HASH 알고리즘은 데이터의 무결성을 검증하는 데 사용됩니다. 브라우저가 생성한 비밀번호가 전체 데이터 암호화의 핵심이기 때문에, 전송 시 비대칭 암호화 알고리즘으로 암호화됩니다. 비대칭 암호화 알고리즘은 공개 및 개인 키를 생성하며, 공개 키는 데이터를 암호화하는 데만 사용되므로 언제든지 전송할 수 있고, 웹사이트의 개인 키는 데이터를 복호화하는 데 사용되어 웹사이트가 개인 키를 매우 신중하게 보관하여 유출을 방지합니다.

TLS 핸드셰이크 과정 중 어떤 오류도 암호화된 연결이 끊어져 개인 정보 전송을 방해할 수 있습니다. HTTPS가 매우 안전하기 때문에 공격자들은 어디서부터 시작할지 찾지 못해 가짜 인증서를 사용해 고객을 속여 평문 정보를 얻지만, 이러한 방법들은 식별할 수 있으며, 이에 대해서는 후속 기사에서 다룰 예정입니다. 하지만 2010년에 보안 전문가들은 TLS 1.0 프로토콜 처리 과정에서 취약점을 발견했 http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ 는데, 실제로 BEAST라는 이 공격 방식은 2002년에 보안 전문가들에 의해 발견되었으나 공개되지는 않았습니다. 마이크로소프트와 구글은 이 취약점을 수정했습니다. 참고: http://support.microsoft.com/kb/2643584/en-us https://src.chromium.org/viewvc/chrome?view=rev&revision=90643

HTTPS의 단순화된 버전은 대칭 암호화와 비대칭 암호화에서도 작동합니다.