[네트워크] HTTPS와 TLS 정리: 암호화, 인증서, 디지털 서명 이해하기

안전한 네트워크 통신

네트워크에서는 메시지를 패킷 단위로 주고받는다.

 

문제는 이 패킷이 중간에서 캡처될 수 있다는 점이다.  

메시지를 평문으로 주고받으면 누군가 패킷을 들여다보고 내용을 확인할 수 있다.

 

더 나아가 메시지를 가로채 변조할 수도 있다.

 

예를 들어 로그인 요청에 아이디와 비밀번호가 평문으로 담겨 있다면, 네트워크 중간에서 이를 훔쳐볼 수 있다. 결제 정보나 개인정보도 마찬가지이다.

 

그래서 안전한 네트워크 통신을 위해서는 암호화가 필요하다.

 

암호화와 복호화

암호화(encryption)는 원문 데이터를 알아보기 어려운 형태로 바꾸는 과정이다.

반대로 복호화(decryption)는 암호화된 데이터를 다시 원문 데이터로 되돌리는 과정이다.

 

암호화와 복호화의 핵심은 키(key)이다.

 

키는 데이터를 암호화하거나 복호화할 때 사용하는 값이다.
같은 원문이라도 어떤 키를 사용하느냐에 따라 암호문이 달라질 수 있다.

 

암호화 방식은 크게 두 가지로 나눌 수 있다.

대칭 키 암호화
비대칭 키 암호화

 

대칭 키 암호화

대칭 키 암호화는 암호화와 복호화에 같은 키를 사용하는 방식이다.

 

송신자와 수신자가 같은 키를 가지고 있어야 한다.

 

예를 들어 A가 B에게 메시지를 보낸다고 하자.

 

A는 하나의 키로 메시지를 암호화한다.
B는 같은 키로 암호문을 복호화한다.

 

대칭 키 암호화의 장점은 빠르다는 점이다.

 

암호화와 복호화에 드는 연산 부담이 비교적 작다.
그래서 많은 데이터를 빠르게 암호화하고 복호화하는 데 적합하다.

 

하지만 큰 문제가 있다.

 

송신자와 수신자가 같은 키를 가지고 있어야 하므로, 이 키를 안전하게 공유해야 한다.

 

만약 대칭 키가 중간에 유출되면 공격자는 암호문을 복호화할 수 있다.
또 같은 키로 메시지를 암호화해 위조할 수도 있다.

 

비대칭 키 암호화

대칭 키 암호화의 가장 큰 문제는 키를 안전하게 공유하기 어렵다는 점이다.

이를 해결하기 위해 등장한 방식이 비대칭 키 암호화이다.

 

비대칭 키 암호화는 공개 키 암호화라고도 한다.

 

비대칭 키 암호화에서는 서로 다른 두 개의 키를 사용한다.

 

공개 키는 다른 사람에게 공개해도 되는 키이다.

개인 키는 자신만 가지고 있어야 하는 키이다.

 

두 키는 한 쌍으로 동작한다.
한 키로 암호화한 데이터는 다른 키로 복호화할 수 있다.

 

공개 키를 알아도 개인 키를 알아내기는 매우 어렵다.
반대로 개인 키에서 공개 키를 유추하는 것도 일반적으로 불가능하도록 설계된다.

공개 키 암호화 예시

A가 B에게 “HI”라는 메시지를 안전하게 보내고 싶다고 하자.

먼저 A는 B의 공개 키를 요청한다.

B는 A에게 자신의 공개 키를 보내준다.

 

공개 키는 이름 그대로 공개되어도 되는 키이기 때문에, 누군가 중간에서 이 키를 보더라도 큰 문제가 되지 않는다.

 

A는 B의 공개 키로 “HI”를 암호화한다.

원문: HI
B의 공개 키로 암호화
암호문 생성

 

A는 암호문을 B에게 보낸다.

 

중간에서 누군가 암호문을 보더라도 내용을 이해할 수 없다.

 

B는 자신만 가지고 있는 개인 키로 암호문을 복호화한다.

 

이 방식의 장점은 키를 안전하게 공유하기 쉽다는 점이다.

 

대칭 키처럼 비밀 키 자체를 상대에게 직접 전달할 필요가 없다.

 

하지만 공개 키 암호화는 대칭 키 암호화보다 느리다.
암호화와 복호화 과정에서 더 많은 연산이 필요하다.

 

 

대칭 키와 공개 키를 함께 사용하기

대칭 키 암호화는 빠르지만 키 공유가 어렵다.

공개 키 암호화는 키 공유는 안전하지만 느리다.

 

그래서 실제 보안 통신에서는 두 방식을 함께 사용한다.

 

핵심 아이디어는 이렇다.

 

먼저 공개 키 암호화를 사용해 대칭 키를 안전하게 공유한다.
그 뒤 실제 데이터 통신은 빠른 대칭 키 암호화로 처리한다.

 

이때 사용되는 대칭 키를 세션 키(session key)라고 한다.

 

 

 

세션 키

세션 키는 하나의 통신 세션에서 사용하는 대칭 키이다.

 

통신을 시작할 때 클라이언트와 서버는 안전하게 세션 키를 만든다.
이 과정에서 공개 키 암호화가 활용될 수 있다.

 

세션 키가 만들어진 뒤에는 실제 데이터를 이 세션 키로 암호화하고 복호화한다.

1. 공개 키 암호화로 세션 키를 안전하게 공유한다.
2. 이후 실제 데이터는 세션 키로 암호화한다.
3. 빠르고 안전한 통신이 가능해진다.

 

 

이 방식은 두 암호화 방식의 장점을 결합한다.

공개 키 암호화로 안전하게 키를 공유하고, 대칭 키 암호화로 빠르게 데이터를 주고받는다.

인증서

암호화만으로는 부족한 문제가 있다.

 

내가 받은 공개 키가 정말 상대방의 공개 키인지 확인해야 한다.

 

예를 들어 사용자가 은행 사이트에 접속했다고 하자.
공격자가 중간에서 가짜 공개 키를 보내면, 사용자는 공격자의 공개 키로 데이터를 암호화할 수도 있다.

 

그래서 공개 키의 신뢰성을 검증할 방법이 필요하다.

 

이때 사용하는 것이 인증서(certificate)이다.

 

네트워크에서 말하는 인증서는 보통 공개 키 인증서를 의미한다.

 

공개 키 인증서는 공개 키와 그 공개 키의 유효성을 증명하기 위한 전자 문서이다.

 

인증서에는 보통 다음과 같은 정보가 포함된다.

인증서 소유자 정보
소유자의 공개 키
인증서 유효 기간
인증서를 발급한 기관
디지털 서명

 

인증 기관

인증서를 발급하고 검증할 수 있도록 신뢰받는 기관을 인증 기관(CA, Certificate Authority)이라고 한다.

 

대표적인 인증 기관에는 DigiCert, GlobalSign, IdenTrust 등이 있다.

 

CA는 어떤 사이트의 공개 키가 정말 그 사이트의 것인지 확인하고 인증서를 발급한다.

클라이언트는 CA가 발급한 인증서를 보고 해당 서버를 신뢰할 수 있는지 판단한다.

 

디지털 서명

인증서에는 디지털 서명이 포함된다.

 

디지털 서명은 인증서가 위조되지 않았고, 신뢰할 수 있는 CA가 발급했다는 것을 확인하기 위한 정보이다.

 

서명값은 보통 다음 흐름으로 만들어진다.

1. 인증서 내용에 해시 함수를 적용해 해시값을 만든다.
2. 그 해시값을 CA의 개인 키로 암호화한다.
3. 암호화된 값을 서명값으로 사용한다.

 

해시 함수

해시 함수(hash function)는 임의의 길이의 데이터를 고정된 길이의 데이터로 바꾸는 함수이다.

해시 함수를 적용한 결과를 해시값(hash value)이라고 한다.

 

해시 함수의 중요한 특징은 입력이 조금만 달라져도 결과가 크게 달라진다는 점이다.

 

예를 들어 문서에서 글자 하나만 바뀌어도 해시값은 완전히 달라질 수 있다.

이 특성 때문에 해시 함수는 데이터 변조 여부를 확인하는 데 사용된다.

원본 데이터의 해시값 계산
전송 후 받은 데이터의 해시값 계산
두 값을 비교
같으면 변조되지 않았다고 판단
다르면 변조되었다고 판단

 

해시값은 데이터의 지문처럼 생각할 수 있다.
데이터가 조금이라도 바뀌면 지문도 달라진다.

인증서 검증 과정

클라이언트가 서버로부터 인증서를 받았다고 하자.

 

클라이언트는 이 인증서가 정말 신뢰할 수 있는 CA가 발급한 것인지 확인해야 한다.

 

검증 과정은 다음과 같다.

1. 인증서에서 서명값과 인증서 내용을 분리한다.
2. 서명값을 CA의 공개 키로 복호화한다.
3. 복호화 결과로 인증서 내용에 대한 해시값을 얻는다.
4. 클라이언트가 직접 인증서 내용에 해시 함수를 적용한다.
5. 직접 계산한 해시값과 복호화한 해시값을 비교한다.
6. 두 값이 같으면 인증서가 변조되지 않았고, CA가 서명한 인증서라고 판단한다.

 

이 과정에서 값이 일치한다면, 해당 인증서는 CA의 개인 키로 서명된 것임을 확인할 수 있다.

 

인증서 내용이 중간에 변조되었다면 직접 계산한 해시값이 달라진다.
CA가 아닌 누군가가 임의로 만든 인증서라면 CA의 공개 키로 올바르게 검증되지 않는다.

 

디지털 서명은 개인 키로 만든 서명을 공개 키로 검증하여 신원을 확인하는 절차라고 볼 수 있다.

 

 

HTTPS

HTTP는 기본적으로 평문 통신이다.

 

HTTP 메시지를 그대로 주고받으면 중간에서 누군가 메시지를 볼 수 있다.

 

이를 보완하기 위해 등장한 것이 HTTPS이다.

 

HTTPS는 HTTP over TLS를 의미한다.

 

HTTP 메시지를 TLS를 통해 안전하게 주고받는 방식이다.

 

HTTPS를 사용하면 HTTP 메시지가 암호화되어 전송된다.
중간에서 패킷을 캡처하더라도 실제 내용을 알아보기 어렵다.

 

또한 인증서를 통해 접속한 서버가 신뢰할 수 있는 서버인지 검증할 수 있다.

SSL과 TLS

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인증과 암호화를 수행하는 프로토콜이다.

TLS는 SSL을 계승한 프로토콜이다.

 

초기에는 SSL 2.0, SSL 3.0이 사용되었고, 이후 TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3이 등장했다.

오늘날에는 보통 TLS가 사용된다.

 

하지만 관습적으로 SSL 인증서, SSL 설정이라는 표현이 여전히 많이 쓰인다.

정확하게 말하면 현대 HTTPS 통신은 대부분 TLS 기반이다.

 

HTTPS 메시지 송수신 단계

HTTPS 통신은 대략 다음 단계로 이루어진다.

1. TCP 3-way handshake
2. TLS handshake
3. 암호화된 HTTP 메시지 송수신

 

먼저 TCP 연결을 수립한다.

그다음 TLS 핸드셰이크를 수행한다.

TLS 핸드셰이크에서는 암호화 통신을 위한 정보 교환, 키 생성, 인증서 송수신과 검증이 이루어진다.

TLS 핸드셰이크가 끝나면 클라이언트와 서버는 안전하게 만든 키를 바탕으로 암호화된 HTTP 메시지를 주고받는다.

TLS 핸드셰이크

TLS 핸드셰이크는 클라이언트와 서버가 안전한 통신을 시작하기 위해 필요한 정보를 교환하는 과정이다.

 

이 과정에서 다음 일이 이루어진다.

지원하는 TLS 버전 협의
사용할 암호화 알고리즘 협의
키 생성에 필요한 난수 교환
서버 인증서 전달
인증서 검증
암호화 통신에 사용할 키 생성

 

ClientHello

TLS 핸드셰이크는 클라이언트가 ClientHello 메시지를 보내면서 시작된다.

 

ClientHello는 클라이언트가 사용할 수 있는 보안 관련 정보를 서버에게 제시하는 메시지이다.

 

ClientHello에는 보통 다음 정보가 포함된다.

지원하는 TLS 버전
사용 가능한 암호 스위트
키 생성에 필요한 난수
기타 확장 정보

 

암호 스위트(cipher suite)는 사용할 수 있는 암호화 알고리즘, 키 교환 방식, 해시 함수 등의 조합을 의미한다.

 

클라이언트는 “나는 이런 TLS 버전과 이런 암호 스위트를 사용할 수 있습니다”라고 서버에게 알려준다.

ServerHello

서버는 ClientHello를 받은 뒤 ServerHello 메시지로 응답한다.

 

ServerHello는 클라이언트가 제시한 선택지 중 서버가 사용할 값을 선택하는 메시지이다.

 

ServerHello에는 다음 정보가 포함될 수 있다.

선택된 TLS 버전
선택된 암호 스위트
키 생성에 필요한 서버 측 난수

 

ClientHello와 ServerHello를 주고받으면, 클라이언트와 서버는 암호화 통신에 필요한 기본 조건을 맞추게 된다.

 

이후 두 호스트는 교환한 정보와 난수를 바탕으로 암호화에 사용할 키를 생성한다.

인증서와 Certificate 메시지

TLS 핸드셰이크 과정에서 서버는 클라이언트에게 인증서를 보낸다.

 

이때 사용되는 메시지가 Certificate 메시지이다.

 

인증서에는 서버의 공개 키와 서버 신원을 증명하기 위한 정보가 들어 있다.

 

클라이언트는 이 인증서를 검증한다.

이 인증서가 신뢰할 수 있는 CA가 발급한 것인가?
인증서가 변조되지 않았는가?
인증서의 도메인이 접속한 서버와 일치하는가?
인증서의 유효 기간이 지나지 않았는가?

 

검증에 성공하면 클라이언트는 서버의 공개 키를 신뢰할 수 있다.

CertificateVerify

서버는 경우에 따라 CertificateVerify 메시지를 보낼 수 있다.

 

이 메시지는 서버가 인증서에 포함된 공개 키에 대응하는 개인 키를 실제로 가지고 있음을 증명하는 데 사용된다.

 

서버가 개인 키로 특정 데이터를 서명하고, 클라이언트가 서버의 공개 키로 이를 검증할 수 있다면 서버가 해당 개인 키를 가지고 있음을 확인할 수 있다.

Finished 메시지

TLS 핸드셰이크의 마지막에는 클라이언트와 서버가 Finished 메시지를 주고받는다.

Finished 메시지는 지금까지의 핸드셰이크 과정이 정상적으로 완료되었는지 확인하는 역할을 한다.

 

이 메시지를 주고받은 뒤부터는 클라이언트와 서버가 생성한 키를 사용해 암호화된 데이터를 주고받는다.

 

TLS에서는 실제 암호화된 응용 계층 데이터를 Application Data라고 부른다.

 

HTTPS에서는 이 Application Data 안에 암호화된 HTTP 메시지가 들어간다고 보면 된다.