한빛출판네트워크

HTTPS^{HyperText Transfer Protocol over Secure Socket Layer}는 서로 다른 두 컴퓨터가 네트워크를 통해 안전하게 메시지를 주고받기 위해 만든 프로토콜입니다. HTTPS는 TCP 대신 전송 계층 보안^{Transport Layer Security}(TLS) 프로토콜을 기반으로 하는 HTTP라고 이해하면 됩니다. 여기서 이야기하는 TLS는 OSI 7계층 중 네 번째에 해당하는 전송 계층의 TCP 프로토콜을 기반으로 동작하는 보안 프로토콜입니다.

TIP TLS가 등장하기 전까지는 TLS 대신 보안 소켓 계층
Secure Sockets Layer(SSL) 프로토콜을 사용했습니다. 오늘날 SSL은 너무 많은 취약점으로 더 이상 사용하지 않지만, 여러 문서나 OpenSSL 등의 라이브러리는 SSL 이름을 계속 사용합니다. 이러한 문서나 라이브러리에서 사용하는 SSL은 TLS와 같다고 생각하면 됩니다.

캡처 프로그램으로 클라이언트가 보낸 모든 내용을 볼 수 있습니다.

이처럼 네트워크로 암호화되지 않은 메시지를 주고받을 때는 제삼자가 메시지를 볼 수 있어서 신용카드 정보나 비밀번호와 같은 민감한 데이터를 주고받으면 안 됩니다. 또한 제삼자가 메시지를 원하는 형태로 변조할 수 있으므로 서버가 해킹될 위험도 있습니다.

그러나 HTTPS를 사용하면 서버와 클라이언트가 주고받는 메시지를 암호화하여 제삼자가 볼 수 없습니다. 메시지를 암호화/복호화할 때 사용하는 키는 HTTPS로 메시지를 주고받는 두 컴퓨터만 알기 때문에 제삼자가 메시지를 보더라도, 암호화되어 내용을 알 수 없습니다.

HTTPS는 4계층에서 동작하는 TLS와 달리, 더 높은 7계층에서 동작합니다. 그래서 키를 안전하게 교환하는 것 외에도 7계층 정보인 HTTP의 도메인 주소가 신뢰할 수 있는지 검사하는 기능도 제공합니다.

익스플로러, 크롬, 파이어폭스와 같은 웹 브라우저는 HTTPS 연결 과정에서 서버가 보낸 인증서를 받습니다. 인증서가 신뢰할 수 있는 기관에서 인증한 게 아니거나 인증 기간이 만료됐다면 연결을 허용하지 않습니다. 신뢰할 수 있는 기관이란 국가별로 인증서를 발급하는 기관을 뜻합니다. 만약 인증서가 안전한 것으로 검증된 경우에는 웹 브라우저에서 화면을 볼 수 있습니다.

TIP 신뢰할 수 있는 인증서 발급 기관 목록은 https://www.checktls.com/showcas.html에서 볼 수 있습니다.

HTTPS는 전적으로 TLS를 기반으로 하며 TLS 버전에 따라 사용 가능한 암호화 목록과 안정성이 달라집니다. 높은 TLS 버전을 사용하면 오래된 하드웨어나 소프트웨어를 지원하지 않아서 호환성 문제가 발생하지만, 더 강력한 암호 알고리즘을 사용하기 때문에 해킹 위험이 줄어듭니다.

TLS 1.0은 1990년대 말에 제정된 최초의 TLS 버전으로 TLS 프로토콜의 기반이었던 SSL 3.0과 일부 호환됩니다. 그래서 TLS 1.0은 SSL 3.0이라고도 합니다.

1.0은 오래 전에 제정된 만큼 모든 암호 알고리즘에 취약점이 있습니다. 크롬, 익스플로러, 파이어폭스, 사파리 등의 웹 브라우저들은 TLS 1.0 프로토콜을 사용할 경우 경고를 출력하거나 접근을 제한하기도 합니다. 게다가 이 브라우저들은 2020년 3월부터 TLS 1.0 및 1.1 지원을 중단할 것이라고 발표했습니다(출처:https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/).

TLS 1.1은 1.0 프로토콜에서 발견된 취약점들을 개선하고 더 강력한 암호 알고리즘을 사용합니다. 1.0과 마찬가지로 거의 모든 브라우저에서 사용 중단을 선언한 상태입니다. 그러나 유니티와 같은 일부 플랫폼에서는 TLS 지원이 늦어서 1.1을 사용하는 곳이 꽤 많이 남아 있습니다.

TLS 1.2에서는 TLS 1.1에서 서명, 랜덤 함수 등에서 사용하는 MD5/SHA-1 해시 함수들을 사용할 수 없게 제거하고 알고리즘을 SHA-2 기반으로 바꿨습니다. 사용할 수 있는 암호 목록도 더 강력하고 안전합니다.

모질라의 조사(https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/)에 따르면, 현재 TLS 1.2 버전을 가장 많이 사용합니다.

서로 다른 두 컴퓨터가 메시지를 암호화하여 주고받아도, 암호화와 복호화에 사용하는 키가 노출되면 메시지 내용을 보거나 변조가 가능해서 안전하다고 볼 수는 없습니다. 그래서 HTTPS 프로토콜은 핸드셰이킹 과정에서 키를 안전하게 교환합니다.

키 교환은 RSA 알고리즘과 디피-헬먼^{Diffie-Hellman ephemeral}(DHE) 알고리즘 중 한가지 방법을 사용합니다. 두 방법 모두 소수와 이산대수의 특징을 이용하여 ‘불가능에 가까운 연산’을 요구하게 함으로써, 제삼자가 연결 과정을 보더라도 키를 유추할 수 없게 합니다. 또한 이 과정에서 서버의 인증서를 사용하는 데 인증서가 필요한 이유는 뒷부분에서 설명하겠습니다.

이번 장에서 두 알고리즘을 자세히 소개하면 책의 범위를 넘어가므로 두 방법에 어떤 차이점이 있는지, 무엇을 사용해야 하는지 등을 살펴보겠습니다.

RSA 알고리즘을 사용한 키 교환 방식은 취약하여 TLS 1.3부터는 지원하지 않습니다. RSA 알고리즘 자체가 취약한 것은 아니지만, 이를 사용한 교환 방식에 취약점이 있기 때문입니다.

RSA 알고리즘을 사용해 키를 교환할 때, 모든 클라이언트와의 키 교환이 서버 공개키 하나에 의존하기 때문에 비공개키가 한 번이라도 노출되면 과거에 주고받았던 메시지나 미래에 주고받을 모든 메시지까지 복호화하는 것이 가능합니다.

디피-헬먼 알고리즘은 공개키를 주고받은 이후 추가 과정을 더해 키를 만들기 때문에 비밀키가 노출되더라도 과거에 주고받았던 메시지가 노출될 일은 없습니다. 물론 비밀키가 노출됐기 때문에 미래에 주고받을 메시지는 여전히 노출될 수 있습니다.

이처럼 비밀 키가 노출돼도 과거에 주고받은 메시지가 안전한 특성을 PFS^{Perfect Forward Security}라고 합니다.

그러나 디피-헬먼 또한 시간이 지나면서 취약점이 발견됐습니다. 그래서 오늘날에는 이 취약점을 보완한 타원 곡선 디피-헬먼^{Elliptic Curve Diffie-Hellman ephemeral}(ECDHE) 알고리즘을 HTTPS 키 교환 시 사용합니다.

HTTPS 통신을 하기 위해서는 반드시 인증서가 필요합니다. X.509는 이러한 형태의 인증서를 위한 표준으로 신뢰할 수 있는 인증 기관^{certificate authority}(CA)에서만 발급이 가능하며 일정 비용을 지불하면 누구나 발급할 수 있습니다. 코모도^Comodo, 고대디^GoDaddy, 시만텍^Symantec(인수 전에는 베리사인^VeriSign) 등이 대표적인 인증 기관이며, 인증 기관 대부분은 미국과 유럽에 있습니다.

TIP전 세계 모든 사람에게 무료로 SSL 인증서를 발급해주는 letsencrypt에서 무료로 인증서를 발급할 수 있습니다. 유효 기간은 3개월로 유료 발급기관에서 보장하는 1년이나 2년보다는 짧지만, 인증서 갱신 자동화 기능을 제공하기 때문에 큰 문제가 되진 않습니다.

X.509 인증서는 발행 기관, 인증서 버전, 고유 번호, 인증서 소유자 및 소유자 정보 등을 포함하고 있습니다. 아래 이미지는 인증서가 포함하는 정보를 보여줍니다.

다음은 인증서를 발급할 때 주의할 점입니다.

• 인증서는 세 가지 종류가 있습니다. 도메인 1개를 지원하는 싱글 도메인, 제한된 개수의 서브 도메인을 지원하는 멀티 도메인, 개수 제한이 없는 서브 도메인을 지원하는 와일드 카드(*) 도메인 인증서가 있습니다. 실무에서는 대부분 와일드 카드 도메인을 구매합니다.

• 인증서 도메인 이름^{common name}(CN)은 최대 64글자까지 사용할 수 있습니다.

• HTTPS URL은 반드시 인증서의 도메인 이름 전체 또는 일부를 포함해야 클라이언트가 연결할 수 있습니다https://tools.ietf.org/html/rfc2818#section-3.1 ). 인증서 이미지를 예로 들면, 클라이언트는 *.stackexchange.com을 포함하는 URL 주소만 연결을 맺을 수 있습니다

앞서 암호 키 교환 과정에서 인증서를 사용한다고 설명했습니다. 그러나 키 교환 과정은 암호화가 되지 않은 상태에서 진행해서 중간자가 개입해 메시지를 변조할 경우 통신을 가로챌 수 있습니다. 그래서 클라이언트는 키를 교환하기 전에 이 서버가 신뢰할 수 있는 서버인지 검증하는 작업이 필요한데, 연결을 맺는 클라이언트는 이 과정에서 서버가 보내는 인증서를 통해 검증합니다.

모든 인증서에는 인증서 변조를 막기 위한 서명이 있습니다. 서명은 앞서 살펴봤던 인증서에서 볼 수 있는 여러 정보와 인증서 발급 기관이 제공하는 비밀키를 사용하여 만들어집니다.

서명은 비밀키를 알고 있는 기관에서만 만들 수 있고 인증서 정보가 변조되면 서명이 바뀌거나 일치하지 않으므로 변조 사실을 알 수 있습니다. 이 특징을 이용하면 인증서를 받은 클라이언트는 서명을 확인하는 것만으로 인증서를 보낸 서버가 신뢰할 수 있는지 확인할 수 있습니다.

인증서는 신뢰할 수 있는 인증 기관인 루트 인증 기관Root CA 외에도 (아래)인증서 연결 구조 그림과 같이 최상위 기관에서 인증서를 발급받은 중간 기관에서 다시 인증서를 발급할 수 있습니다. 각 인증서는 서로 연결되어 있어서 인증서를 검증해야 하는 클라이언트는 인증서를 중간 기관에서 발급했더라도, 이 기관이 최상위 기관으로부터 인증서를 발급받았다는 증거(서명)를 찾아 신뢰할 수 있는 기관인지 확인할 수 있습니다. 이 과정을 (아래)인증서 연결 구조 그림을 보면서 설명하겠습니다.

인증서 연결 구조 그림은 최상위 기관과 중간 기관, 중간 기관이 발급한 서버 인증서가 어떤 관계에 있는지 보여줍니다. 최상위 인증 기관은 기관을 보증할 곳이 없어서 인증서에 스스로 서명을 합니다.

중간 기관은 최상위 기관으로부터 인증서를 발급받는 곳입니다. 중간 기관 인증서는 최상위 기관이 서명합니다. 서명은 인증서에 포함된 공개키로 복호화가 가능하며 최상위 기관의 해시 값을 복호화 값으로 가져올 수 있습니다.

TIP오늘날 일반적으로 사용하는 인증서는 1개의 중간 기관을 가지거나, 중간 기관이 없는 경우가 많으나 이론적으로는 무수히 많은 중간 기관이 있어도 무방합니다.

클라이언트는 인증서에 있는 공개키를 이용해 앞서 설명했던 암호화 키를 교환합니다. 그러나 키를 교환하기 전에 인증서가 신뢰할 수 있는 기관으로부터 발급한것인지 다음과 같은 검증 작업이 필요합니다.

1. 모바일 기기를 포함한 대부분 운영체제 또는 웹 브라우저는 자체적으로 신뢰할 수 있는 최상위 기관의 CA의 인증서를 가지고 있는데 이를 인증서 번들이라고 합니다. "안드로이드, [설정] → [보안] → [인증서 확인] 그림"은 모바일 기기에서 확인할 수 있는 인증서 번들을 보여줍니다. 이 최상위 기관 인증서들은 이후 과정에서 서명이 일치하는지 확인할 때 사용합니다.

2. 서버가 인증서를 보내면 "서버 인증서 및 중간 기관 이름 추적"그림과 같이 인증서 발급 기관에 해당하는 상위 인증서를 가져옵니다. 이 과정은 최상위 인증서를 찾을 때까지 반복합니다.

3. "인증서 서명 확인 작업"그림과 같이 최상위 인증서 안에 있는 공개키를 이용해 중간 기관 인증서 서명을 복호화합니다. 복호화에 성공하면 최상위 기관 인증서의 해시 값을 가져올 수 있습니다.

4. 3번 과정에서 얻은 해시 값이 인증서 번들에 있는 최상위 기관 인증서 서명과 일치하면, 서버 인증서 서명과 중간 기관의 공개키를 이용해 3번 과정을 다시 반복합니다. 이때는 중간 기관의 인증서 서명값과 서버 인증서 서명을 중간 기관의 공개키로 복호화한 해시 값을 비교합니다. 만약 이 과정 중 해시 값이 일치하지 않으면, 서버 인증서를 신뢰할 수 없는 것으로 간주합니다.

4번까지의 과정이 모두 끝나면, 클라이언트는 서버 인증서가 신뢰할 수 있다고 간주합니다. 서버 인증서는 중간 기관이 발급했지만, 중간 기관이 인증서를 발급하고 서명할 때 사용한 해시 값이 최상위 기관에서 중간 기관에게 발급한 인증서의 해시 값이기 때문입니다.

이렇게 각 인증서가 서로 신뢰 관계에 있는 것을 연쇄 신뢰 또는 신뢰 체인^{chain oftrust}이라고 부릅니다.