[Network] TLS/SSL

암호화 통신 프로토콜

SSL(Secure Socket Layer) / TLS(Transport Layer Security)는 모두 웹 브라우저와 웹 서버 간 통신을 암호화하는 프로토콜이다. SSL은 웹 브라우저 개발사에서 만든 프로토콜로 인터넷 기술 표준화 단체인 IETF가 TLS로 다시 설계하여 인터넷 표준으로 삼았다.

📖 장점

• 기밀성(암호화) : 서버와 주고 받는 데이터가 스니핑 되는 것을 방지한다.
• 데이터 무결성 : 패킷 전달 과정에서 데이터가 제 3자에 의해서 악의로 변경되는 것을 방지한다.
• 서버 인증 : 서버가 신뢰할 수 있는 서버라는 것을 확인한다.

📖 암호화

TLS는 보안과 성능상의 이유로 두 가지 암호화 방법을 혼용해서 사용한다. 암호화를 위해서는 키가 필요하다.

이때 암호화와 복호화에 사용하는 키는 서로 동일 할 수도, 다를 수도 있다.

대칭키 암호화(Symmetric Key Algorithm)

• 대칭키 암호화란, 암호화를 하는 키와 복호화를 하는 키가 동일한 키를 사용하는 방식이다. 이 때 사용하는 키를 대칭키라고 한다.
• 대칭키를 사용하기 위해서는 상대와 같은 키를 공유해야 한다. 대칭키를 패킷을 통해 상대방과 공유하는 과정에서 이 패킷을 훔쳐보는 스니핑(sniffing) 공격에 취약하다는 단점이 존재한다.

비대칭키 암호화

• 하나의 키를 갖는 대칭키 암호와 방식과 달리, 비대칭키 암호화 방식은 한 쌍의 키를 갖게 된다. 이 한 쌍의 키를 각각 암호화, 복호화 과정에서 사용한다.
• 하나는 공개 키(Public Key), 다른 하나는 개인키(Private Key)라고 부른다. 하나의 키로 암호화를 하였다면 다른 남은 키로 복호화를 할 수 있다. 암호화에 사용한 키로 다시 복호화가 불가능하다. 이렇게 한 쌍의 키로 암호화 및 복호화를 하는 방식을 RSA 알고리즘이라 한다.
• 비대칭키 암호화를 사용하면 상대방에게 전달하는 공개키를 도중에 해킹당한다 해도 개인키를 알지 못하기 때문에 복호화를 할 수 없다.

📖 TLS 암호화 방식

비대칭키 암호화는 RSA 알고리즘을 이용한 암호화 방식으로 복잡한 수학적 원리로 이루어져 있어 CPU 리소스를 크게 소모한다는 단점이 있다. 이를 해결하기 위해 TLS에서는 두 가지의 암호화 방식을 모두 사용하여 두 방식을 보완하여 사용한다.

처음 대칭키를 서로 공유하는 과정에서 RSA 비대칭키 방식을 사용하고 안전하게 공유 받은 대칭키를 사용하여 실제 통신할 때 데이터를 주고 받는 과정에서 사용한다.

📖 인증서

서버가 신뢰할 수 있는 서버인지를 확인하기 위해 필요하다. 인증서는 다음과 같은 정보들을 포함한다.

1. 서비스 정보(인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버 측 공개 키(공개 키 암호화 방식)
3. 지문, 디지털 서명 등

📖 CA(Certificate Authority)

CA는 인증서를 발급하는 기관으로, Root Certificate라고도 부른다. TLS 통신을 하려면 이 CA를 통해서 인증서를 발급받아야 한다. CA는 자체적으로 공개 키와 개인 키를 가지고 있다. CA로부터 인증서를 발급받기 위해서는 다음과 같은 방식을 따른다.

1. 발급 받고자 하는 기관은 자신의 사이트 정보(도메인 등)과 공개 키를 CA에게 제출한다.
2. CA에서 인증서를 발급 받고자 하는 기관에 대해 검증을 진행한다.
3. CA는 검증을 거친 후 발급 받고자 하는 기관의 공개 키를 해시(SHA-256 등)한다. 이렇게 해시한 값을 Finger Print(지문)라고 한다.
4. Finger Print를 CA의 개인 키로 암호화하고, 인증서의 발급자 서명으로 등록한다. 이렇게 서명된 것을 디지털 서명(Digital Signing)이라고 한다.
5. 이제 CA는 디지털 서명, 발급자 정보 등이 등록되어 있는 인증서를 발급한다.

이러한 방식으로 상위 인증 기관이 하위 인증서가 포함하고 있는 공개 키(인증서)를 상위 기관의 개인 키로 암호화하여 상호 보증하게 되는 것을 인증서 체인(Certificate Chain)이라고 한다.

발급받는 CA 기관이 Root CA가 아니라면, 이 CA 기관마저 또 상위 CA에게 인증서를 발급받는다. 보통 3단계에 걸쳐서 인증서 체인이 이루어진다.

1. tistory.com의 인증서는 그 상위 인증서인 Thawte TLS RSA CA G1의 인증기관(Intermediate CA)의 개인 키로 암호화 된 것이다.
2. Thawte TLS RSA CA G1 인증서는 그 상위 인증서인 DigiCert Global Root CA G2의 인증기관의 개인 키로 암호화 된 것이다.
3. DigiCert Global Root G2는 상위 인증기관이 없는 Root CA이기 때문에 Self-Signed 되어 있다.

Self-Signed(스스로 보증)이란, 자신의 인증서를 해시한 후 CA가 아닌 자신의 개인 키로 암호화하여 서명으로 등록하는 것을 말한다.

📖 CA 인증 없이 인증서 생성

신뢰성은 떨어지지만 CA 인증과 상관 없이 발행하는 인증서를 사설 인증서라고 한다. 이 사설 인증서는 Root CA 처럼 Self-Signed 되어 있다. 때문에 보증기관이 없으며 누구도 보증해주지 않는 인증서다. 이러한 사설 인증서를 사용하여도 TLS 통신이 가능하다. 이러한 경우 “신뢰할 수 없는 사이트”와 같은 안내문을 확인할 수 있다.

📖 TLS(SSL) 인증서로 서버를 인증하는 방법

CA에서 발급받은 인증서를 통해 서버의 신뢰성을 인증한다. 클라이언트는 이 인증서가 CA에서 발급받은 것인지 어떻게 확인할까? 먼저 알아 둘 것은, 클라이언트들은 CA 리스트를 이미 갖고있다. OS를 설치할 때 PC에 포함되거나 브라우저가 포함하고 있다. Mac에서는 KeyChain에, 브라우저는 소스코드에 이미 존재한다. CA 리스트란, 공인으로 인증된 CA기관들의 리스트들로 공개 키 또한 함께 갖고 있다.

1. 서버에서 인증서를 요청한다.

CA는 검증을 거친 후 제출받은 서버의 공개키를 해시하여 CA의 개인 키로 암호화한다. 그리고 서버에게 인증서를 발급해 준다. 이제 서버가 진짜 자신임을 인증해줄 인증서를 갖게 된다.

2. 클라이언트가 서버에 접속하기위해 인증서를 확인하고자 한다.

먼저 클라이언트는 서버로부터 받은 인증서가 자신이 가진 CA 리스트에 있는 기관에서 발급받은 것인지 확인한다. TLS 통신에서 클라이언트와 서버는 서로 몇번 인사를 주고 받으며 서버는 CA에서 발급 받은 자신의 인증서를 클라이언트에게 전달한다. 여기서 전달 받은 인증서가 중간에 변조된 사실이 없는지 무결성 검사를 진행한다. 먼저 클라이언트는 서버로부터 받은 인증서가 자신이 가진 CA 리스트에 있는 기관에서 발급받은 것인지 확인한다.

이것이 확인되면, 해당 CA 기관의 공개 키로 서버 인증서의 서명(Digital Signing)을 복호화한다. 디지털 서명을 복호화 하면 인증서 내용을 해시한 값이 나온다.

이렇게 디지털 서명을 CA 기관의 공개 키로 복호화 하여 나온 해시 값과, 서버의 공개 키를 해시한 값(Finger Print)이 일치 한다면, 인증서가 위조되지 않았음을 인증하는 것이다.

전체적인 검증 절차는 다음 그림과 같다.

3. 클라이언트가 서버를 인증하고 암호화 통신을 진행한다.

클라이언트는 서버의 공개 키로 대칭키를 암호화하여 서버에게 보내고, 서버는 자신의 개인 키로 복호화하여 클라이언트의 대칭키를 알아낸다. 클라이언트는 서버가 CA 인증기관에서 인증받은 신뢰할 수 있는 서버임을 확인했으며 인증서 안에 있는 서버의 공개 키 또한 알았다. 이제 서로 통신을 주고받기 위해 클라이언트는 자신이 사용할 대칭키를 서버에게 TLS 암호화 방식을 통해 전달한다.

📖 TLS HandShake

데이터를 주고 받기 전, 서버의 무결성을 확인하고 대칭키를 전달하는 과정이 이루어진다.

Client Hello(Client)

 클라이언트가 서버에 접속한다. 실제 Client Hello라는 패킷을 전송하고 이 패킷 안에는 다음과 같은 메시지 정보가 들어있다. 

• TLS version
  클라이언트에서 사용하는 TLS 버전.
• Cipher Suite List
  클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 한다. 이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송한다.
• Client Random Data
  클라이언트에서 생성한 난수, 나중에 대칭키를 만들 때 사용.
• Session ID
  매번 HandShake를 하는 과정은 당연히 시간이 소요되는 작업이다. 이 작업을 매번 연결 할 때마다 하지 않기 위해서, 최초 한번의 HandShake만 Full HandShake를 하기위해 Session ID를 사용한다.

최초 HandShake에선 Session ID가 0이고 이후 이어지는 Server Hello 메세지를 통해 서버는 Session ID를 보내준다. 클라이언트는 이 Session ID를 로컬에 저장하고 다시 서버와 HandShake를 맺을 때 로컬에 저장한 Session ID를 보낸다. 서버에서 이 Session ID가 유효하다고 판단하면 SeverHello에 같은 Session ID를 보낸다. 그렇게 되면, 서버의 인증서를 확인하고 암호화 방법을 선정하고 대칭키를 교환하는 등의 작업을 하지 않는다.

•  SNI(Server Name Indication) 
  서버의 이름을 표시하는 부분. SNI를 사용하면 물리적으로 동일한 서버에 존재하는 각기 다른 도메인들이 서로 다른 TLS 인증서를 적용할 수 있다.

Server Hello(Server)

클라이언트가 보낸 Client Hello에 대해 서버에서 응답하는 것. Server Hello 패킷은 Client Hello와 유사한 메시지 정보가 들어있다.

• TLS Version
  서버에서 사용하는 TLS 버전.
• Selected Suite
  클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 이로써 암호화 방식에 대한 협상이 종료되고 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 된다.
• Server Random Data
  서버에서 생성한 난수, 클라이언트와 동일하게 대칭키를 만들 때 사용.
• Session ID
  클라이언트에서 받은 Session ID가 0이면 새로 Session ID를 생성 및 응답, 0이 아니라면 받은 Session ID가 유효한지 확인하여 응답한다.
• SNI(Server Name Indication)
  서버에선 SNI를 비워서(Empty) 보낸다.

Server Certificate(Server)

서버의 인증서를 클라이언트에게 보내는 단계. 클라이언트는 이 메시지를 통해 서버의 인증서가 무결한지 검증한다. 서버의 인증서에 대한 검증이 완료되면 이전에 주고 받았던 클라이언트와 서버의 난수를 조합하여 pre master secret 키를 생성한다. 이 때 사용할 암호화 기법은 대칭키이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안된다. 이 pre master secret(대칭키)를 서버의 공개키로 암호환한다.

• Server Hello Done(Server)
  서버가 클라이언트에게 보낼 메시지를 모두 보냈다는 뜻으로 보내는 메시지.
• Client Key Exchange(Client)
  클라이언트는 만들어둔 pre master secret 키를 서버의 공개키로 암호화하여 서버에게 전달.
• Key Generation(Server&Client)
  클라이언트와 서버가 서로 암호화 및 복호화 할 때 사용할 대칭키를 성공적으로 공유하는 과정.
• Cipher Spec Exchange(Server&Client)
  이후로 전송되는 모든 메세지는 협상된 알고리즘과, 키를 이용하여 암호화 하겠다는 메시지를 전달.
• Finished(Server&Client)
  클라이언트와 서버가 TLS HandShake를 성공적으로 마치고 종료되었다는 것을 서로에게 알린다.
• Application Data(Server&Client)
  클라이언트와 서버가 서로 TLS로 암호화 통신을 하는 데이터 패킷

📖 HTTPS

HTTP는 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트가 주고 받는 메시지를 감청하는 것이 매우 쉽다. 예를들어 로그인을 위해서 서버로 비밀번호를 전송하거나, 또는 중요한 기밀 문서를 열람하는 과정에서 악의적인 감청이나 데이터의 변조등이 일어날 수 있다. 이를 보안한 것이 HTTPS다.

HTTPS는 TLS/SSL 보안 프로토콜 위에서 동작하는 HTTP다.

📚 참고 자료

그림으로 이해하는 네트워크 구조와 기술

TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키)

HTTPS와 SSL 인증서 - 생활코딩

[10분 테코톡] 👶에단의 TLS