HTTPS (HTTP over SSL)
HTTPS(HyperText Transfer Protocol Secure)는 HTTP 프로토콜에 암호화 프로토콜을 사용하여 통신을 암호화한 HTTP의 보안 버전이다. HTTPS는 데이터 전송의 보안을 강화하기 위해 사용된다. 모든 웹 사이트에 HTTPS가 권장되지만, 특히 로그인 자격 증명이 필요한 웹 사이트는 HTTPS를 사용해야한다.
우리가 접근하는 웹 사이트가 https://~ 로 시작한다면, 웹 서버로 데이터가 암호화되어 안정하게 전달됨을 의미한다. HTTP를 사용하여 데이터가 전송된다면, 데이터는 쉽게 스니핑할 수 있는 데이터 패킷으로 나뉘어 보안 위험에 노출될 수 있다. HTTPS를 사용하면 패킷을 스니핑하거나 가로챈다고 해도 암호화된 문자로 인식된다.
HTTPS 프로토콜을 사용하기 위해서는 인증 기관(CA) 로부터 SSL 인증서를 발급받아야 한다.
SSL / TLS
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 모두 암호화된 데이터 전송을 위한 프로토콜이다. TLS는 SSL의 취약성을 해결한 업그레이드된 SSL이라고 보면 된다. 현재는 SSL 인증서는 더 이상 사용되지 않으며 TLS가 표준이지만, 여전히 같은 의미로 통용되고 있다.
SSL 인증서로 표기하더라도, 실제로는 TLS 인증서라고 보면 된다.
암호화 방식
SSL 인증서의 동작 원리를 이해하려면, 암호화 방식을 이해하고 있어야 한다.
대칭키 방식(Symmetric Key Cryptosystem)
대칭키 암호화는 암호화와 복호화에 같은 키(대칭키)를 사용하는 방식이다. 이 방식의 가장 큰 장점은 연산 속도가 빠르다는 것이다 그러나 양 측의 키가 같기 때문에 키를 안전하게 교환해야 한다는 단점이 있으며, 키 관리 또한 어려울 수 있습니다.
비대칭키 방식(Asymmetric KeyCryptosystem)
비대칭키 암호화는 암호화와 복호화에 서로 다른 두 개의 키를 사용하는 방식이다. 이 두 키를 공개키와 개인키라고 하며, 한 쌍으로 존재한다. 공개키는 누구에게나 공개될 수 있으며, 개인키는 한쪽에서만 사용한다. 공개키로 암호화된 데이터는 해당 개인키로만 복호화할 수 있다. 비대칭키 암호화의 가장 큰 장점은 키 교환 문제를 해결한다는 것이며, 대표적인 예로 RSA(Rivest-Shamir-Adleman)가 있다. 그러나 대칭키 암호화에 비해 연산 속도가 느리다
하이브리드 방식(Hybrid Cryptosystem)
하이브리드 암호화는 대칭키 암호화와 비대칭키 암호화의 장점을 결합한 방식이다. 데이터 자체는 대칭키를 사용하여 암호화하고, 그 대칭키를 비대칭키를 사용하여 암호화한다. 대칭키 암호화의 빠른 속도와 비대칭키 암호화의 안전한 키 교환의 장점을 모두 활용한다. 대부분의 현대적인 보안 시스템과 통신 프로토콜(예: HTTPS, SSL/TLS)은 하이브리드 암호화 방식을 사용한다.
SSL 인증서 동작 원리
SSL 인증서 발급 과정
서버에서 HTTPS 프로토콜을 사용하기 위해 SSL인증서를 발급받는 과정은 아래와 같다.
0. (서버) 공개키와 비밀키를 생성한다.
1. (서버 -> CA) 서버는 인증서를 발급받기 위해 CA에 다음 정보를 제공한다.
- 1번에서 생성한 서버의 공개키
- 서버의 각종 정보
2. (CA) 2번에서 서버로부터 받은 정보를 담아 SSL 인증서를 발급한다.
3. (CA) 3번에서 만든 인증서를 서명하기 위해, CA의 공개키와 비밀키를 생성한다. CA의 비밀키를 이용해 인증서를 서명한다.
4. (CA->서버) 4번에서 서명된 SSL 인증서를 서버에 전달한다.
인증서를 발급받은 웹 사이트는 브라우저에서 인증서 정보를 확인할 수 있다. CA 정보 및 CA의 공개키 정보까지 (위 과정에서 생성한) 확인할 수 있다.
CA의 서명
위 과정에서 'CA가 인증서를 서명'한다고 표현하였다. CA가 서명한다는 것을 무슨 의미일까?
CA는 사이트(서버) 정보와 공개키 정보를 받으면, 해당 공개키를 해시(SHA-256 등)하여 인증서에 등록한다. 이 해시값을 Finger Print(지문) 라고 한다. 또한 이 지문을 CA의 비밀키로 암호화하여 인증서에 '서명'으로 등록한다. 이 서명을 디지털 서명이라고 한다. 이후 브라우저는 CA의 공개키를 이용해 서명을 복호화하여 이 값이 지문(서버의 공개키를 해시한 값)과 비교하여 인증서가 위조되지 않았음을 검증한다. 인증서의 유효성이 확인되면, 브라우저는 인증서에 있는 서버의 공개키를 추출한다.
이렇게 상위 인증 기관이 하위 인증서가 포함하고 있는 공개키를 상위 기관의 비밀키로 암호화하여 상호 보증하는 것을 Certificate Chain (인증서 체인)이라고 한다.
Self-Signed SSL
CA 인증 없이도 인증서를 생성할 수 있다. TLS 통신도 가능하다. CA 인증과 관련없이 발행하는 인증서가 사설 인증서이다. 이 사설 인증서는 Root CA처럼 Self-Signed 되어있다. 보증기관이 없으며, 보증되지 않는 인증서이다.
사설 인증서를 사용하는 경우, 클라이언트가 해당 인증서를 신뢰할 수 있는 인증 기관(CA)을 알지 못하기 때문에 보안 경고를 발생시킬 수 있다.
SSL 인증서를 통한 암호화된 통신 원리
우리는 앞서 서버가 인증서를 발급받는 과정을 알아봤다. 발급받은 인증서를 통해 웹 서버와 클라이언트(웹 브라우저)가 통신하는 과정은 다음과 같다.
6. 클라이언트 (웹 브라우저)가 서버로 연결을 시도한다.
7. 서버는 Certificate 패킷을 통해 서버의 SSL 인증서를 전달한다.
8. 클라이언트는 서버의 SSL 인증서를 검증한다. CA의 공개키를 이용해 서명을 복호화한다. 복호화하여 나온 해시 값과, 공개키를 해시한 값(지문)이 일치한다면, 인증서가 위조되지 않았으며, 해당 CA에서 발급되었다는 것을 검증하는 것과 마찬가지이다.
9. 데이터를 암호화하기위한 대칭키를 생성하고, 서버의 공개키로 대칭키를 암호화한다.
10. 서버로 암호화된 대칭키를 전달한다.
11. 서버는 비밀키로 복호화하여 대칭키를 얻는다.
12. 이제 서버와 클라이언트는 대칭키를 통해 안전한 통신을 할 수 있다.
5번에서 클라이언트 (웹 브라우저)에 CA가 공개키를 제공하는 것 처럼 표현하였으나,
클라이언트는 CA 리스트를 이미 갖고 있다. PC에 포함되거나 브라우저가 포함하고 있다. CA 리스트는 공인으로 인증된 CA 기관들의 리스트로, CA의 공개키도 함께 갖고 있다.
SSL Handshake
위 내용을 이해하였다면, SSL Handshake 과정은 어렵지 않다.
SSL Handshake 과정의 목적은 다음과 같다.
- 서버와 클라이언트가 주고받을 데이터의 암호화 알고리즘을 결정
- 서버와 클라이언트가 주고받을 데이터의 암호화를 위한 대칭키 전달
이미 우리는 서버와 클라이언트가 통신을 위한 대칭키를 얻기까지의 과정을 전체적인 그림을 통해 이해하였다. SSL Handshake 과정을 이미 대략적으로 살펴본 것이다.
1. 클라이언트 -> 서버 연결 시도 (Client Hello)
클라이언트는 서버에게 'Client Hello' 패킷을 보내며 연결을 시도한다. 패킷에는 자신이 사용 가능한 cipher suite 목록, session id, ssl protocol version 등을 포함한다.
2. 서버 -> 클라이언트 응답 (Server Hello)
서버는 클라이언트의 'Client Hello' 메시지를 받고 클라이언트가 제안한 cipher suite 중 하나를 선택하여 'Server Hello'로 응답한다.
3. 서버 인증서 전달 (Server Certificate)
서버는 자신의 인증서를 클라이언트에게 전송한다. 인증서에는 서버의 공개키, 인증서 발급자, 유효 기간 등이 포함되어 있다. 클라이언트는 전달받는 서버의 인증서를 검증*한다.
* 서버의 인증서 검증은 위에서 살펴본 CA의 공개키를 통한 검증을 의미한다.
4. 클라이언트 -> 서버 대칭키 전달 (Client Key Exchange)
클라이언트는 서버의 공개키를 사용하여 Pre-Master Secret*을 암호화하여 이를 서버에게 전송한다. 서버는 자신의 개인키로 이를 복호화하여 Pre-Master Secret을 획득한다.
* Pre-Master Secret 키
서버의 랜덤 데이터와 클라이언트의 랜덤 데이터를 조합해 생성한 키로, 세션 단계에서 데이터를 주고 받을 때 사용된다.(대칭키 암호화 방식)
5. Change Cipher Spec
이후 클라이언트는 Change Cipher Spec 메시지를 서버에게 보내어 이제부터 암호화된 통신을 시작하겠다고 알리며, 서버 또한 새로 협상된 암호화 설정을 사용할 준비가 되었다고 응답한다.
6. Finished
클라이언트와 서버는 서로에게 'Finished' 메시지를 암호화된 형태로 전송하여, 핸드셰이크 과정이 성공적으로 완료되었음을 확인한다. 이전 단계에서 협상된 Pre-Master Secret 키를 사용한다.
참고
- https://babbab2.tistory.com/5
- https://nuritech.tistory.com/25
- https://www.stevenjlee.net/2020/11/01/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-http-vs-https-%EA%B7%B8%EB%A6%AC%EA%B3%A0-ssl-secure-socket-layer/
