HTTPS

HyperText Transfer Protocol Secure의 약자로, HTTP의 약점을 보완하기 위해 등장한 프로토콜이다.

기존 HTTP의 경우, 평문 데이터(텍스트)를 전송하는 프로토콜로써, 누군가 네트워크에서 신호를 가로채면 내용이 노출될 수 있다는 보안 이슈가 존재한다.

HTTPS는 데이터 암호화를 추가하여 보안성을 강화한 프로토콜로써. HTTP Secure라고도 불리며, 443번 포트를 사용한다. HTTP 레이어 바로 밑단에 SSL을 추가하여 인터넷 상에서 정보를 암호화한다. HTTP 메세지를 TCP로 보내기 전에 먼저 SSL에서 모든 데이터를 암호화함으로써, 공격에 취약한 HTTP와 달리, 데이터의 송수신 과정에서 데이터를 가로채려는 공격 등으로부터 대응할 수 있게 된다.

HTTPS는 애플리케이션 계층의 새로운 프로토콜이 아니며, HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 프로토콜로 대체하는 형태이다.

SSL / TLS

SSL

Netscape Communications Corporation에서 웹 서버와 웹 브라우저간의 보안을 위해 만든 프로토콜로 공개키/개인키 대칭키를 혼합하여 사용한다.

TLS

SSL 프로토콜을 토대로 발전한 프로토콜로서, 당시 SSL 프로토콜을 개발했던 Netscape가 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구)에 양도하면서 이름만 바뀌게 된 형태이다. 실제 TLS 1.0은 SSL 3.1과 동일한 프로토콜이다.

대칭키와 비대칭키

대칭키의 경우, 클라이언트와 서버 모두 동일한 키를 소유하여 기본데이터를 암호화거나 암호화된 데이터를 복호화하는 작업을 진행한다.

비대칭키의 경우, 클라이언트와 서버 각각 다른 키를 소유하는 것을 의미한다. 이를 공개키/개인키라고 하는데, 공개키가 클라이언트에게 개인키가 서버에 소유되며, 각각의 키는 서로 암호화한 작업을 상대 키로만 복호화할 수 있다.

• 공개키 암호화 : 공개키로 암호화하면 개인키로만 복호화할 수 있다 → 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
• 개인키 암호화 : 개인키로 암호화하면 공개키로만 복호화할 수 있다 → 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다

HTTPS는 대칭키 암호화방식과 비대칭키 암호화 방식을 모두 사용(혼용)한다.

통신 이전 HTTPS handshake를 통해 서버와 클라이언트 간에 세션키를 교환하는 작업이 이루어지는데, 이 세션키가 네트워크 통신의 대칭키 역할을 하며, 세션키 생성과정에 공개키/개인키를 활용한 비대칭키 방식이 적용된다.

정리하자면, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키 암호화 방식이 사용되는 것이고, 이후 데이터를 교환하는 과정에서는 빠른 연산 속도를 위해 대칭키 암호화 방식이 사용되는 것이다.

대칭키 비대칭키를 혼합한 HTTPS handshake

순서는 다음과 같다.

1. 클라이언트(브라우저)가 서버로 최초 연결을 시도한다

이 단계에서 클라이언트가 서버에게 보내는 옵션은 다음과 같다.

• 클라이언트 측에서 생성한 랜덤 데이터 (무작위 문자열)
• 사이퍼 슈트 : 암호화 알고리즘 리스트로, 클라이언트가 현재 가능한 암호화 알고리즘 들을 선택하여 보낸다.
• 임시 DH 매개변수

2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨준다

서버는 클라이언트 모두 지원하는 가장 높은 TLS 버전을 식별하여 결정하며, 서버의 사이퍼슈트 지원 여부를 확인하여 암호화 알고리즘을 결정하여 클라이언트에게 응답정보를 보낸다. 해당 정보에서 서버가 보내는 정보는 다음과 같다.

• 서버 측에서 생성한 랜덤 데이터
• 공개키가 포함된 SSL 인증서
• 임시 DH 변수

DH (Diffie-Hellmen)
서로의 공개값 공유, 비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합하여 공통의 암호키를 만드는 알고리즘이다. 실제 TLS 에 사용하는 DH 알고리즘은 여기에 더불어 DHE와 타원곡선암호화 방법을 섞은 ECDHE 알고리즘을 사용한다.

RSA 알고리즘의 경우 인증서의 크기가 커지면 암호화/복호화 속도가 느려지는 단점이 있는 반면, DH의 알고리즘은 키 교환 단계에서만 사용되기 때문에, 인증서의 크기에 대한 영향이 적다.

3. 클라이언트는 서버가 보낸 인증서가 유효한지 확인한다.

먼저 인증서가 정상적인 인증서인지를 확인한다. 브라우저 내의 CA 리스트에 해당 인증서를 발급하는 기관이 존재하는지 확인한 후, 해당 인증기관의 공개키를 통해 인증서에 대해 복호화를 시도한다. 복호화가 정상적으로 이루어진다면 해당 인증기관에 의해 인증서라는 것을 확인하며 이를 보낸 서버를 신뢰할 수 있는 서버라고 판단한다.

이후 클라이언트와 서버거 각각 서로 교환한 DH 매겨변수를 사용 하여 임시 암호키 (세션키)를 생성한다.

4. 클라이언트는 생성한 세션키를 암호화하여 서버에게 보낸다.

생성한 세션키를 서버에게 보내기 위해, 공개키를 통해 암호화하여, 세션키를 서버에게 보내게 된다. 정상적인 작업이라면, 서버의 개인키를 통해 데이터를 복호화하여 동일한 세션키가 나와야 한다.

5. 클라이언트 서버 모두 동일한 세션키를 가지고 있으므로, 이후 세션키(대칭키)를 통해 암호화/복호화를 진행한다.

HTTPS 이점

보안적인 측면

요청-응답에 필요한 데이터를 암호화 하여, 데이터가 악용되는 사례를 방지한다.

SEO 측면

구글은 SSL 인증서를 강조해왔으며, 사이트 내 모든 요소가 동일하다면 HTTPS 프로토콜을 통해 서비스를 제공하는 사이트가 그렇지 않은 사이트보다 SEO 순위가 높다는 것을 공식적으로 발표했다.