HTTPS 란?

이전 포스팅에서 HTTP에 대해서 썼다. 하지만 대부분 보안때문에 HTTPS를 필수로 사용한다. 그래야 네트워크 경유지에서 패킷이 탈취당해도 HTTP 메시지가 암호화되어있어 내용을 알 수 없기 때문이다.

1. 암호화 방식

암호화 방식은 크게 2가지로 나뉜다. 대칭키 암호화와 비대칭키 암호화 방식이다. HTTPS를 암호화하는 방식은 대칭키와 비대칭키 암호화를 둘다 쓰는 방식이라고 볼 수 있다.

1.1 대칭키 암호화

대칭키 암호화는 암호화와 복호화에 같은 키를 사용한다. 그래서 구현이 간단하고 빠르지만, 키가 탈취당하면 키를 획득한 사람이 암호화와 복호화가 모두 가능해서 키 분배에 어려움이 있다. 대칭키 암호화에 가장 많이 쓰이는 알고리즘은 AES 알고리즘이다.

1.2 비대칭키 암호화

비대칭키 암호화는 공개키(Public key)로 암호화하고 복호화는 개인키(Private Key)로 한다. 그리고 그 반대 역시 가능하다. 개인키로 암호화하면 공개키로 복호화할 수 있으며 두 키는 쌍을 이룬다. 주로 서버에서만 복호화하고 클라이언트에서 암호화하기 때문에 공개키를 아무에게나 줘도된다. 왜냐하면 암호화한 데이터는 서버에서만 복호화할 수 있기 때문이다.

비대칭키 암호화 방식은 또 다른 방식으로도 응용된다. 만약 공개키가 검증되었다면 이를 통해서 암호화된 정보의 출처 검증이 가능하다. 만약 어떤 데이터를 A회사가 제공한 공개키로 복호화에 성공한다면 데이터의 출처가 A사임을 알 수 있다. 또한 복호화에 실패한다면 A사의 데이터가 아님을 알수도 있다. 이런 공개키가 어떤 회사의 공개키인지 검증해주는 기관을 CA(Certificate Authority)라고 한다.

비대칭키는 키분배는 쉽지만 구현이 더 복잡하고 연산도 느리다. 비대칭키 암호화 가장 많이 쓰이는 알고리즘은 RSA 알고리즘이다.

2. HTTPS 암호화 방식

HTTPS는 비대칭키 암호화를 통해서 클라이언트가 생성한 대칭키를 서버에서 받아서 클라이언트가 생성한 대칭키를 사용하여 데이터를 전달한다. 이를 요약하면 다음과 같은 과정을 겪는다.

클라이언트가 서버의 SSL 인증서를 받는다.(공개키를 포함)
클라이언트는 세션키(1회용 키, 대칭키)를 생성하고 "서버의 공개키로 생성한 세션키를 암호화"하여 서버에 전달한다.
서버와 클라이언트는 서로만 아는 세션키(대칭키)를 이용해 데이터를 교환한다.

3. CA와 인증서

공개키(비대칭 키)를 사용하여 세션키를 교환하는 방식 자체는 위험의 소지가 있다. 예를 들면 중간에 해커가 공개키를 위조하여 클라이언트에게 보내도 클라이언트는 구분할 수가 없다. 그래서 진짜로 생각하고 그대로 클라이언트만의 세션키를 해커에게 보내줄 수 있게 된다. 이를 해결하기 위한 방법이 SSL/TLS 인증서다. 기술적인 해결방법보다는, 사회적인 합의와 신뢰에의한 해결방법이다. 대한민국 여권이 한국에서 발행된 것임이 증명되면 대한민국 출신이라고 신뢰하듯이, 엄격하게 증명된 소수의 CA 기관에서 인증된 공개키면 해당 서버에서 온 것임을 증명하는 것이다.

3.1 인증서 생성

서버는 CA를 통해 인증서를 발급받는다. 아래는 그 과정이다.

서버는 서버만 알고있는 [서버-공개키]와 [사이트 정보]를 CA에 보내며 SSL 인증서 발급을 요청한다.
CA는 서버의 [인증서-정보]([서버-공개키], [사이트-정보], [발급-정보]을 합친 것)을 함께 해쉬화 하여 [Hashed-인증서-정보]를 만든다.
CA만 알고있는 [CA-비밀키]를 사용하여 [Hashed-인증서-정보]를 암호화하여 Signature(서명)를 만든 후, 둘을 합쳐서 인증서를 생성하여 서버에 전달한다.
서버는 통신시 CA에서 발급받은 인증서를 클라이언트에게 준다. 인증서의 Signature는 [CA-공개키]로 복호화되면 [Hashed-인증서-정보]가 된다.

3.2 인증서 확인

클라이언트는 브라우저에 신뢰가능한 CA들의 [CA-공개키] 목록을 가지고 있다. 그래서 이 목록의 [CA-공개키]로 인증서 Signature를 복호화시 증명이 되는지 여부를 통해 해커가 아닌 옳바른 도메인에서 온 데이터가 맞음을 증명할 수 있게 된다.(신뢰 기반)
만약 브라우저에 내장된 [CA-공개키] 목록에 없는 기관의 인증서라면 브라우저는 경고창을 띄어준다. 이 때는 직접 해당 기관의 공개키 등을 확인하여 직접 확인해보고, 신뢰할 수 있는 기관인지 여부도 판단하여 사용하면 된다. 그리고 아래는 확인 과정이다

클라이언트는 서버에 요청하여 인증서를 받아온다.
인증서의 [인증서-정보](시그니처 제외한 부분)을 명시된 알고리즘으로 해시화한다. 그러면 [Hashed-인증서-정보]가 나온다.
클라이언트는 인증서의 Signature를 브라우저에 내장된 [CA-공개키]로 복호화한다. 이 값은 [Hashed-인증서-정보]다.
위의 2번째와 3번째에서 구한 [Hashed-인증서-정보]가 같은 값을 갖는지 확인하여 해커에게서 온 인증서가 아닌 올바르게 전달받은 인증서임을 증명한다.

실제 키 인증서 확인하는 과정에서는 인증서가 폐기된 인증서인지 여부까지 CA에서 확인하는 과정이 있다. Client에서 CRL 혹은 COSP를 통해 확인한다.

방법	확인 주체	설명
CRL	클라이언트	CA가 주기적으로 발행하는 폐기 목록을 클라이언트가 다운로드해 확인
OCSP	클라이언트	클라이언트가 인증서의 상태를 CA에게 실시간으로 물어봄
OCSP Stapling	클라이언트 (확인), 서버 (전달)	서버가 CA에서 받아온 OCSP 응답을 클라이언트에게 같이 전달해 성능 향상

3.3 인증서 확인 후

인증서 확인 후 [클라이언트-세션 키]를 생성하고, 이 키를 [서버-공개키]로 복호화하여 서버에 전달한 뒤 [클라이언트-세션 키]로 암호화 하여 데이터를 주고 받는다.