보안 HTTP

해당 장에서는 HTTP 트랜잭션을 안전하게 보호하는 복잡하고 적극적인 기술을 제시한다.

HTTP를 안전하게 만들기

은행 거래나 구매와 같이 큰 돈의 트랜잭션이나, 보안 상 중요한 자료들의 접근 등에 대해서는 기존의 방식보다 더 안전한 방식이 필요하다. 이에 HTTP와 디지털 암호화 기술을 결합한다.

HTTP의 보안 버전은

• 서버 인증 : 위조된 서버가 아님을 알 수 있음
• 클라이언트 인증 : 진짜 사용자임을 알 수 있음
• 무결성 : 데이터 위조로부터 안전
• 암호화 : 도청에 대한 걱정 없이 대화
• 효율 : 저렴하게 사용할 수 있으면서도 알고리즘은 빨라야 함
• 편재성 : 모든 클라이언트와 서버에서 지원
• 관리상 확장성 : 즉각적인 보안 통신
• 적응성 : 최선의 보안 방법 지원
• 사회적 생존성 : 사회 문화적, 정치적 요구를 만족 과 같은 조건들을 모두 만족해야 한다.

그렇다면 이러한 HTTP 보안 기술은 무엇이 있을까?

HTTPS

HTTPS는 가장 대중적인 방식이다. HTTPS는 모든 요청과 응답 데이터에 대해 네트워크로 보내지기 전에 암호화된다. 이는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작한다.

이러한 보안 계층은 안전 소켓 계층(Secure Sokcets Layer, SSL)과 전송 계층 보안(Transport Layer Security)로 구현된다. 둘은 거의 비슷하므로 둘 모두를 SSL이라고 칭하기도 한다. 인코딩이나 디코딩은 SSL 라이브러리에서 일어나기 때문에 클라이언트와 서버는 TCP 입력/출력 호출을 SSL 호출로 대체하고, 추가 설정 몇 가지 정도만 필요하다.

디지털 암호학

디지털 암호의 기초에서 먼저 정리해야 할 용어들이 있다.

• 암호 : 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
• 키 : 암호의 동작을 변경하는 숫자로 된 매개변수
• 대칭키 암호 체계 : 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
• 공개키 암호법 : 비밀 메시지를 전달하는 컴퓨터를 쉽게 만들 수 있는 시스템
• 디지털 서명 : 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬
• 디지털 인증서 : 신뢰할만한 조직에 의해 서명되고 검증된 신원 확인 정보

비밀 코드의 기술과 과학

암호법

암호법은 암호라 불리는 비밀 코드에 기반하여 메시지를 인코딩하고, 받은 메시지를 디코딩 하는 방법이다. 암호가 적용되어 코딩된 메시지는 보통 암호문이라고 불린다.

대표적인 암호로, 율리우스 카이사르 암호가 있는데, 알파벳 순서상 세번 뒤의 알파벳으로 교체하는 방식이다. 이러한 방식을 통해서 예전부터 비밀 메시지를 만들어 왔다.

암호 기계

이러한 암호는 옛날에는 수작업이었기 때문에 간단하고 풀릴 위험이 높았지만, 기술이 진보하면서 글자들을 단순 옮기는 것 뿐만이 아닌 글자 대체, 회전, 스플리팅과 같은 기술을 사용한 암호 기계를 만들기도 했다.

키가 있는 암호

이러한 기계에는 암호의 동작 방식을 변경할 수 있는 다른 값을 설정할 수 있는 다이얼이 달려있어 다른 사람이 이를 사용하여 암호를 해독하는 것을 방지했다.

위와 같이 해당 가상 암호 기계들은 서로 다른 키 값을 가지고 있기 때문에 키에 따라 제각각 다르게 동작하고 결괏값도 다르다.

디지털 암호(와 비대칭 암호화)

디지털 계산이 가능해지면서 여러 복잡한 알고리즘이 가능해지고, 매우 큰 키를 통해 가상 암호 알고리즘을 만들어내어 보안은 더욱 강화된다. 평문은 인코딩 키 e로 인코딩하고, 디코딩 키 d로 디코딩하는 방식이다.

이러한 암호화 기법은 주로 비대칭 암호화로 불린다.

대칭키 암호화

반대로 이전과 이후에 같은 키를 사용하는 대칭키 암호화 방식도 있다. 대칭키 암호화 방식의 경우 비밀 키 K를 똑같이 공유하고, 같은 키로 인코딩 및 디코딩을 진행한다. 잘 알려진 대칭키 암호 알고리즘으로 DES, Triple-DES, RC2, RC4 알고리즘 등이 있다.

키 길이와 열거 공격(Enumertaion Attack)

이러한 대칭키 암호화 방식에서는 인코딩과 디코딩 알고리즘이 알려져 있기 때문에 결국 키가 제일 중요한 비밀이다. 좋은 암호 알고리즘의 경우 해당 키를 알려면 우주에 존재하는 모든 키 값을 시도해야 한다. 이렇게 무차별로 모든 키값을 대입하는 공격을 열거 공격이라고 한다. 키 값이 적다면 금방 풀리지만, 가능한 키 값이 아주 많으면 죽을 때까지 해도 못한다.

가능한 키 값의 개수같은 경우, 유효한 키와 가능한 키의 비트 수로 결정이 된다. 비트가 높을 수록 경우의 수는 한없이 늘어나고 128비트의 키같은 경우 2^128의 키값이 가능하기 때문에 매우 강력한 조건이다. 이는 곧 암호의 길이가 보안을 높여준다는 이야기기도 하다.

공유키 발급하기

대칭키 암호의 단점은 개인별로 각각의 개인 키를 가져야 한다는 점이다. 발송자와 수신자가 서로 대화하려면 둘 다 공유키를 가져야 한다. 각각에 대해 비밀 키를 생성한 다음에 두 사용자 사이에서 둘만이 대화가능해야 하기 떄문에 매 사용자의 쌍마다 새롭게 키를 발급해야 한다. 그리고 대화 참여자의 각 쌍은 그들만의 개인키 또한 필요하다. 그렇기 때문에 키의 수는 N^2 개가 될 수 밖에 없으며, 이는 키가 점점 늘어날 수록 관리하기 힘들어진다는 문제점이 있다.

공개키 암호법

한 쌍의 호스트가 하나의 인코딩/디코딩 키를 사용하는 대신, 공개키 암호 방식은 두 개의 비대칭 키를 사용한다. 하나는 호스트의 메시지를 인코딩하고, 다른 하나로는 그 호스트의 메시지를 보기 위한 디코딩을 하기 위해 사용한다.

여기서 인코딩 키의 경우 공개되어 있기에 공개키 암호화 방식이라고 하지만, 호스트만이 개인 디코딩 키를 알고 있다.

이런 방식을 사용하면, 인코딩의 경우에는 누구나 사용할 수 있는 인코딩 키를 사용하는 대신, 디코딩 키를 각 사용자마다 다르게 하면 되므로 N^2까지 키의 개수가 증가하는 최악의 상황을 면할 수 있다.

RSA

공개키 비대칭 암호의 경우, 비밀인 개인키를 공개키, 암호문 일부, 메시지와 암호화한 암호문 을 알고 있더라도 계산할수 없음을 보증해야 한다.

이러한 요구를 만족하는 공개키 암호 체계 중 하나는 MIT에서 발명된 RSA 알고리즘이다. 개발자 Ron Rivest, Adi Shamir, Leonard Adleman 세 명의 이름을 따서 RSA로 불린다. 해당 알고리즘의 경우 기본 숫자들끼리의 계싼 과정에서 사칙연산 등에 대해서는 쉽지만 소인수분해 과정은 훨씬 어렵다는 점을 원리로 삼아 발전시킨 알고리즘이다. 보안도가 매우 높아 대한민국을 포함한 대부분의 인터넷 뱅킹에서 해당 알고리즘을 사용한다.

혼성 암호 체계와 세션 키

비대칭 공개키 암호 방식은 누구나 공개키만 알면 그 키에 대응되는 공개 서버에 안전하게 메시지를 보낼 수 있게 해준다. 두 노드가 안전하게 의사소통하려고 할 때 개인키에 대한 협상을 할 필요가 없다.

하지만 이러한 공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있어 대칭과 비대칭을 섞은 방법이 쓰이기도 한다. 이를 혼성 암호 체계(hybrid cryptosystem) 라고 한다. 대칭키 암호화의 효율성과 공개키 암호화의 보안성을 결합한 암호화 기법이다.

• 대칭키 암호화의 효율성 : 대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하므로 속도가 빠르지만, 키 공유가 어려워 보안에 취약
• 공개키 암호화의 보안성 : 공개키 암호화는 암호화와 복호화에 서로 다른 키를 사용하므로 키 공유가 안전하고, 공개키를 사용하여 암호화하면 개인키를 가진 사람만 복호화
• 대칭키 + 공개키(효율성 + 보안성) : 혼성 암호 체계는 먼저 공개키 암호화로 대칭키를 안전하게 교환하고, 이후 대칭키를 사용하여 데이터의 암호화 및 복호화를 수행

디지털 서명

암호 체계는 메시지를 암호화하고 해독하는 것뿐 아니라 누가 메시지를 썼는지 알려주고 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 이용될 수 있다. 이러한 기법 중 인터넷 보안 인증서에중요한 디지털 서명(digital signing)에 대해 알아보자.

서명은 암호 체크섬이다

디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다. 이러한 서명은

• 서명은 작성한 저자가 누군지 알려줌. 극비 개인 키를 갖고 있기 때문에 저자만 체크섬 계산 가능
• 체크섬은 저자의 비밀 개인 키에 관련되어 있기 때문에 올바른 체크섬을 날조할 수 없어 메시지 위조 방지 하기 때문에 이점을 가진다.

디지털 서명은 비대칭 공개키에 의해 생성되고, 개인 키는 오직 소유자만이 알고 있다. 위 그림은 디지털 서명이 함께 전송되는 과정을 보여준다. 데이터 송신하는 쪽에서 메시지를 정제하여 고정된 길이의 요약(digest)로 만들면, 거기에 사용자의 개인 키를 매개변수로 하는 서명 함수를 적용하여 디지털 서명을 추가한 뒤 데이터를 송신한다. 데이터 수신자는 이러한 메시지를 받은 후에 이러한 데이터가 위조되었는지 확인하기 위해 공개키를 이용한 역함수를 적용함으로써 서명이 같은지를 체크하는 과정을 통해 데이터의 보안을 유지한다.

디지털 인증서

디지털 인증서는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다. 다른 인증 방식에 대해서는 상대적으로 위조하기 쉽기 때문에 인터넷의 신분증이라고 불릴 수 있는 인증서를 통해 보다 보안을 높인다.

인증서의 내부

인증서에도 디지털 서명과 같이 공식적으로 인증 기관에 의해 디지털 서명된 정보의 집합이 담겨있다. 여기에는

• 대상의 이름(사람, 서버, 조직 등)
• 유효 기간
• 인증서 발급자(보증인)
• 인증서 발급자의 디지털 서명 등이 담겨있다.

디지털 인증서의 경우 추가적으로 사용된 서명 알고리즘에 대한 서술적인 정보와 보통 대상의 공개키도 담고 있다. 이를 통해 누구나 디지털 인증서를 만들 수 있지만, 인증서의 정보 보증, 개인키로 서명할 수 있는 권한 등을 얻을 수 있지는 않게 한다.

디지털 인증서는 위와 같은 구조를 띄고 있다.

X.509 v3 인증서

국제전기통신연합(ITU-T)에서 정의한 공개 키 인증서 표준이다. 대부분의 인증서가 이 X.509 라는 서식에 정보를 저장한 디지털 인증서를 사용한다.

v3 인증서의 경우 인증 정보를 파싱 가능한 필드에 넣어 구조화하는 표준화된 방법을 제공하며, 이러한 정보는 마이크로소프트에서 아주 잘 정리를 해놨다

속성	Description
버전	인증서의 버전 번호를 식별하는 정수입니다.
일련 번호	CA(인증 기관)에서 발급한 각 인증서의 고유 번호를 나타내는 정수입니다.
서명	CA가 인증서에 서명하는 데 사용하는 암호화 알고리즘의 식별자입니다. 값에는 알고리즘의 식별자와 해당 알고리즘에서 사용하는 선택적 매개 변수(해당하는 경우)가 모두 포함됩니다.
발급자	인증서 발급 CA의 고유 이름(DN)입니다.
유효성 검사	인증서가 유효한 포괄 기간입니다.
Subject	인증서 주체의 고유 이름(DN)입니다.
주체 공개 키 정보	인증서 주체가 소유한 공개 키입니다.
이러한 정보가 v1에서 기본적으로 가지고 있던 정보라면, v2에서는

속성	Description
발급자 고유 ID	발급 CA에서 정의한 대로 발급 CA를 나타내는 고유 식별자입니다.
주체 고유 ID	발급 CA에서 정의한 인증서 주체를 나타내는 고유 식별자입니다.
의 정보가 추가되었고,
v3에서는 확장 필드가 추가되었는데, 이에 대한 정보는 아래와 같다.

속성	Description
기관 키 식별자	인증서 주체와 이 인증서를 발급한 CA 인증서의 일련 번호 또는 발급 CA의 공개 키 해시를 나타내는 식별자입니다.
주체 키 식별자	현재 인증서의 공개 키 해시입니다.
주요 사용량	인증서를 사용할 수 있는 서비스를 정의하는 비트맵 값입니다.
프라이빗 키 사용 기간	키 쌍의 프라이빗 키 부분에 대한 유효 기간입니다.
인증서 정책	인증서 주체의 유효성을 검사하는 데 사용되는 정책 정보의 컬렉션입니다.
정책 매핑	각 organization 정책을 다른 organization 정책에 매핑하는 정책 매핑 컬렉션입니다.
주체 대체 이름	제목에 대한 대체 이름의 컬렉션입니다.
발급자 대체 이름	발급 CA에 대한 대체 이름의 컬렉션입니다.
주체 디렉터리 특성	X.500 또는 LDAP 디렉터리의 특성 컬렉션입니다.
기본 제약 조건	인증서가 CA 또는 사용자, 컴퓨터, 디바이스 또는 서비스에 발급되었는지 여부를 지정할 수 있도록 하는 제약 조건 컬렉션입니다. 이 확장에는 있을 수 있는 하위 CA의 수를 제한하는 경로 길이 제약 조건도 포함됩니다.
이름 제약 조건	CA에서 발급한 인증서에서 허용되는 네임스페이스를 지정하는 제약 조건 컬렉션입니다.
정책 제약 조건	CA 간의 정책 매핑을 금지하는 데 사용할 수 있는 제약 조건의 컬렉션입니다.
확장 키 사용	키 사용 확장에서 식별된 목적 외에 인증서의 공개 키를 사용하는 방법을 나타내는 키 용도 값의 컬렉션입니다.
CRL 배포 지점	기본 CRL(인증서 해지 목록)이 게시되는 URL 컬렉션입니다.
anyPolicy 억제	하위 CA 인증서에서 모든 발급 정책 OID(2.5.29.32.0)의 사용을 금지합니다.
최신 CRL	델타 CRL 배포 지점이라고도 하는 이 확장에는 발급 CA의 델타 CRL이 게시된 하나 이상의 URL이 포함되어 있습니다.

서버 인증을 위해 인증서 사용하기

안전한 웹 트랜잭션 과정에서 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 만약 이 과정에서 인증서가 없으면 보안 커넥션은 실패한다. 서버 인증서는

• 웹사이트의 이름과 호스트명
• 웹사이트의 공개키
• 서명 기관의 이름
• 서명 기관의 서명 등의 정보를 담고 있는데, 여기서 서명 기관을 브라우저가 검사하게 된다. 브라우저는 기본적으로 여러 서명 기관의 인증서가 미리 설치되어 있기 때문에 이를 통해 서명을 검증할 수 있다. 이런 식으로 서명을 미리 등록해놓고 해당 디지털 서명이 진짜인지 검사를 한다.

인증서가 유효하지 않다면 이러한 식의 안내가 뜰 수도 있다.

HTTPS의 세부사항

HTTPS는 HTTP의 가장 유명한 보안 버전으로 널리 구현되어 있다. HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 집합을 결합한 형태로, 매우 안전한 동시에 유연하고 관리하기 쉽게 만들어준다. 이를 통해 인터넷 애플리케이션과 전자상거래 등에 대한 고속 성장을 이룰 수 있었으며, 광역 보안 관리에 있어 중요하다.

HTTPS 개요

HTTPS는 위에서 설명한 것과 같이 HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층으로 보낸다.

HTTPS 스킴

웹 서버로의 요청을 만들 때 웹 서버에게 HTTP 보안 프로토콜 버전을 수행한다고 말해줄 방법이 필요한데, URL의 스킴을 통해 이루어진다. 어려운 용어일 수도 있는데, 그냥 URL 앞에 http:// 로 시작하느냐 https:// 의 차이이다. 브라우저는 웹 리소스에 대한 트랜잭션 수행을 요청받으면 URL의 스킴을 검사하고 이에 맞는 포트로 전송한다(http 80, https 443). 여기서 추가적으로 https 스킴이 있다면 클라이언트는 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드셰이크를 하는 과정을 거치고, 이후에는 암호화된 HTTP 명령을 보내게 된다.

SSL 트래픽은 바이너리 프로토콜이기 때문에 HTTP와는 완전히 다르며, 트래픽은 443 포트로 전달된다. 여기서 어떻게 보안 서버와의 커넥션을 준비할까?

보안 전송 셋업

암호화 되지 않은 HTTP에서 클라이언트는 웹 서버의 80번 포트로 TCP 커넥션을 맺은 후에 HTTP 메시지를 교환한 후 커넥션을 닫는다. 하지만 HTTPS의 경우, 기존의 방식에 SSL 암호 계층이 추가된 버전임으로 중간에 여러 과정이 추가된다. HTTPS의 경우 443 포트로 TCP 연결을 하게 되면 클라이언트와 서버는 암호별 매개변수와 교환 키를 협상하면서 SSL 계층을 초기화시킨다(Handshake). 핸드셰이크가 완료되면 SSL 초기화는 완료되면서 클라이언트가 서버를 향해 요청 메시지를 보안 계층에 보낼 수 있고, 암호화된 데이터는 다시 서버로 암호화되어 전송된다.

SSL 핸드셰이크

위에서 이야기 했던 SSL 핸드셰이크의 경우,

• 프로토콜 번전 번호 교롼
• 양쪽이 알고 있는 암호 선택
• 양쪽의 신원을 인증
• 채널을 암호화하기 위한 임시 세션 키 생성 의 과정을 거치면서 핸드셰이크를 진행한다. 이러한 과정에서 자세하게 무슨 일이 일어나냐면 위 사진과 같이

1. Client Hello
   • 클라이언트가 지원하는 암호화 알고리즘(암호군, Cipher Suites)과 TLS 버전 정보 전송.
2. Server Hello
   • 서버가 사용할 암호군과 TLS 버전을 결정하고, 인증서(Certificate) 전송.
3. 인증서 검증 및 키 교환
   • 클라이언트는 서버의 인증서를 검증하고, 세션 키를 생성하기 위한 과정을 수행.
   • 키 교환 방식(ECDHE, RSA 등)에 따라 클라이언트와 서버가 공유할 키를 결정.
4. Finished 메시지 전송
   • 클라이언트와 서버는 서로 세션 키를 사용해 암호화된 “Finished” 메시지를 주고받으며, 핸드셰이크를 완료. 의 과정이 이루어지며, 우리가 알고 있던 TCP 계층의 핸드셰이크 과정에서 암호화하는 과정을 더한 버전이라고 생각하면 된다.

서버 인증서

SSL은 서버 인증서를 클라이언트로 나르고 다시 클라이언트 인증서를 서버로 날라주는 상호 인증을 지원한다. 클라이언트 인증서는 대부분 쓰이지 않는다. 하지만 보안 HTTPS 트랜잭션은 예외이다. 항상 서버 인증서를 요구한다. 인증서를 매번 요구하는 데는 그만큼 중요한 정보의 트랜잭션이 일어난다는 소리기도 하다. 잘 알려진 인증기관에 의해 서명된 서버 인증서는 이러한 민감한 정보를 보내기 전에 서버를 얼마나 신뢰할 수 있는지 평가하는 것을 도와준다.

서버 인증서는 X.509 v3에서 파생된 인증서로, 위 사진과 같이 조직의 이름, 주소, 서버 DNS 도메인 이름 등의 정보를 가진 인증서이다. 클라이언트 소프트웨어는 이러한 인증서를 검증할 수 있다.

사이트 인증서 검사

클라이언트 소프트웨어가 이러한 인증서를 검사할 수 있다고 해서 사용자가 인증서를 검사하는 것은 아니다. 웹 브라우저가 이러한 인증서에 대해 간단하게 기본 검사를 하고, 청저한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다. 이 과정에서 웹 서버 인증서 검사를 위한 알고리즘은 웹브라우저 검사 기법의 기초를 마련했다.

날짜 검사

날짜 검사의 경우 인증서의 시작 및 종료일을 검증한다

서명자 신뢰도 검사

모든 인증서는 CA(Certificate Authority)에 의해 서명되어 있다. 이러한 인증서는 누구나 발급할 수 있지만, 그렇다고 무조건 인증서를 무조건적으로 받아서 브라우저가 처리하지는 않는다. 위에서 나왔던 보안 경고와 같이 알려지지 않은 인증 기관으로부터 서명된 인증서는 경고를 보여준다. 여기서 사용자는 이러한 인증서를 그대로 받아들일지, 아니면 나갈지를 선택할 수 있다.

서명 검사

한번 서명기관이 믿을 만하다고 판단이 된 이후에 브라우저는 서명기관의 공개키를 서명에 적용하여 그의 체크섬과 비교해봄으로써 인증서의 무결성을 검사한다.

사이트 신원 검사

서버가 누군가 다른 이의 인증서를 복사하거나 트래픽을 가로채는 것을 방지하기 위해 인증서의 도메인 이름을 검사한다. 보통의 서버 인증서는 단일 도메인이지만, 서버 클러스터나 서버 팜을 위해 여러 서버에 대한 와일드 카드로 표현되어 있는 인증서를 받을 때도 있다. 호스트명이 인증서의 신원과 맞지 않을 때는 사용자를 우선으로 생각하기 때문에 사용자에게 알리거나 커넥션을 아예 끊어버린다.

가상 호스팅과 인증서

가상 호스팅이란? 기본적으로 웹서버에 존재하는 주 호스트 도메인을 등록하여 사용하고 있지만 추가적으로 한 서버에 여러 도메인을 등록하여 사용한다는 의미 도메인 이름, ip 주소, 포트 등을 기반으로 가상호스팅을 한다

가상 호스트로 운영되는 사이트의 보안 트래픽은 까다롭다. 유명한 웹 서버 프로그램은 하나의 인증서만을 지원하기 때문에 인증서의 이름과 가상 호스트명이 다르면 경고가 나타난다. 이러한 문제를 피하기 위해 보안 트랜잭션을 시작하는 모든 사용자를 특정 도메인으로 리다이렉트 시키면서 이러한 인증서 문제를 회피하기도 한다.

다른 방법으로는 SNI(Server Name Indication) 이라는 방법도 있다. 클라이언트가 서버에 직접 도메인이 어딘지 알려줌으로써 해당 도메인에 맞는 인증서를 제공하도록 하는 방식이다.

SAN(Subject Alternative Name) 인증 방식은 그냥 빠꾸 없이 하나의 인증서에 모든 도메인을 포함시키도록 하는 방법도 있다.

진짜 HTTPS 클라이언트

SSL은 복잡한 바이너리 프로토콜이기 때문에, 이를 가공하지도 않고 SSL 트래픽을 보내게 되면 처리가 아주 힘들어 질 뿐더러 핸드셰이크 과정에서 실패할 확률이 크다. 따라서 상용 또는 오픈 소스 라이브러리를 사용하여 처리한다.

OpenSSL

SSL과 TLS의 가장 인기 있는 오픈 소스 구현으로, 대부분의 대칭/비대칭 암호화 프로토콜을 구현한 라이브러리로, 1996년 당시 상용되던 SSLeay라는 오픈 소스 구현체를 포크해서 만든 구현체이다. 해당 라이브러리도 X.509 표준의 인증서 생성, 인증 요청 발급, 인증, 인증서 검증 등의 작업에 사용된다.

간단한 HTTPS 클라이언트

const tls = require("tls");
const fs = require("fs");
 
const options = {
  host: "example.com", // 연결할 서버
  port: 443, // HTTPS 기본 포트
  rejectUnauthorized: false, // 서버 인증서 검증 비활성화 (테스트용, 실제 환경에서는 true)
  ca: fs.readFileSync("/etc/ssl/certs/ca-certificates.crt"), // 신뢰할 CA 목록 (옵션)
};
 
const client = tls.connect(options, () => {
  console.log("🔒 TLS Handshake 완료!");
  console.log("🔗 서버 인증서 정보:", client.getPeerCertificate());
 
  // HTTPS 요청 보내기
  client.write(
    "GET / HTTP/1.1\r\n" +
      "Host: example.com\r\n" +
      "Connection: close\r\n" +
      "\r\n"
  );
});
 
// 데이터 수신
client.on("data", (data) => {
  console.log("📥 서버 응답:\n", data.toString());
});
 
// 에러 처리
client.on("error", (err) => {
  console.error("❌ 오류 발생:", err.message);
});
 
// 연결 종료
client.on("end", () => {
  console.log("🔚 연결 종료");
});

책에서는 C 프로그램으로 HTTPS 클라이언트를 만드는 간단한 예제를 작성하지만,,, 나는 자바스크립트 러버이므로 자바스크립트로 HTTPS 클라이언트 예제를 들고 왔다. 사실 C만큼의 low level이 아닌 이상 웬만한 부분은 추상화 되어 있기 떄문에 간편하게 사용할 수 있다.

이렇게 만들어진 예제에서는 처음 섹션이 만들어지자마자 tls(ssl) 커넥션을 갖게 된다. 해당 connect 메서드 안에서 클라이언트는 커넥션의 상태와 선택된 매개변수에 대해 물어보고 서버의 인증서를 검증할 수 있다. 서버의 인증서를 검사하는 과정에서 서버 사이트의 인증서에 대한 조직 등을 확인할 수 있으며, 요청에 대응하는 호스트명을 받게 된다. SSL 채널이 수립된 후에 클라이언트가 사이트 인증서를 안심하고 받아들이게 되면 HTTP 요청을 보안 채널을 통해 전송한다.

프락시를 통한 보안 트래픽 터널링

클라이언트는 웹 서버에 접근해주는 웹 프락시 서버를 종종 이용할 때가 있다. 가장 대표적인 예로 회사에서 기업 네트워크와 공공 네트워크 사이의 경계에 프락시를 설치함으로써 회사 내부망에서 특정 사이트를 차단하고 암호화된 정보를 공유하는 등 네트워크 보안을 강화할 수 있다. 이를 보안 웹 게이트웨이(Secure Web Gateway, SWG) 또는 프록시 방화벽(Proxy Firewall) 이라고도 한다.

위 사진처럼 HTTP 트래픽의 교환 과정에서 공공 인터넷 사이에 프락시를 둠으로써 바이러스 검사나 콘텐츠 제어 등을 수행할 수 있는 것이다. 하지만 만약 클라이언트에서 서버로 보낼 데이터를 서버의 공개키로 암호화한다면, 프록시는 암호화된 데이터가 프록시가 해독할 수 없는 형태로 전송된다. 서버와 클라이언트만 서로의 키가 있기 때문이다. 그렇기 때문에 프록시는 더이상 HTTP 헤더를 읽을 수 없고 헤더를 읽을 수 없으니 요청을 어디로 보내야 하는지도 모르게 된다.

이러한 상황에서 HTTPS가 프록시와도 잘 동작할 수 있게 하기 위해 프록시에게 어디로 접속하는지에 대해 말해주는 방법이 필요하다. 많이 쓰이는 방법은 HTTPS SSL 터널링 프로토콜이다.

클라이언트는 먼저 자신이 연결하고자 하는 안전한 호스트와 포트를 암호화가 시작되기 전 평문의 형태로 알려준다. 이는 HTTP의 CONNECT라 불리는 확장 메서드를 통해 이루어진다.

CONNECT는 안전한 원 서버의 호스트 명과 포트를 콜론으로 구분된 형태로 제공하는 한 줄의 텍스트 명령이다

프락시에게 희망하는 호스트와 포트번호를 말해주면 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다. 이 호스트:포트에 추가적으로 HTTP 버전 문자열과 CRLF가 순서대로 오고, 요청 헤더줄들이 이어진 다음 빈줄 하나가 오면, 빈줄 다음에는 커넥션 수립을 위한 핸드셰이크 성공 후 SSL 데이터 전송이 이루어진다.

프락시는 다시 이 중간에서 요청을 평가하여 유효한 요청이면서 허가를 받은 커넥션인지 확인한다. 여기서 적법할 경우 프락시는 목적지 서버로 연결하고 200 Connection Established 응답을 클라이언트에게 보내준다.