TLS/SSL 아키텍처

 

TLS/SSL 적용하기 위해서 SSL 아키텍처를 모두 뜯어볼 생각이다. 사실 SSL 인증서 관련 문의도 많고, 

SERVER TO SERVER 통신 시 SSL 관련 로직도 상당히 많아서 이번에 확실히 잡고 HTTPS 구축을 진행하려고 한다. 

 

개발자로 느낀 거지만 어중간하게 아는 것은 치명적인 독으로 작용한다는 사실!!.. 하지만 배울 건 넘치고.. 기억력은 한계에.. 그래서 반복하는 게 최선이라고 생각한다.

 

 

[ SSL 사용 이유 ]

네트워크 보안을 공부하신 분들이라면 대칭키, 비대칭키를 공부하셨을 것입니다.
 대칭키는 통신하려는 서로 간 모두 키를 알고 있어야 데이터를 암호화, 복호화할 수 있습니다. 동일한 키를 사용하기 때문에 속도도 매우 빠르지요. 대신 대칭키를 공유하는 과정에서 노출된다면 암호화된 모든 데이터가 노출될 수 있습니다.

 비대칭키는 서로 다른 키를 가지고 암호화, 복호화를 진행합니다. private, public 키 쌍을 가지고요. 하지만 너무 느리고 비효율적입니다. 

 

그렇다면 처음 대칭키를 교환하는 과정이 문제였기 때문에 처음 대칭키를 교환하는 과정을 비대칭키 암호를 사용하여 교환 후 이후 통신에는 대칭키를 사용한다면 최선의 방법일 것입니다. 

이때 TLS/SSL이 이 역할을 도와줍니다.

[ IP ]

인터넷 프로토콜이 서로 통신함에 있어서 여러 프로토콜이 사용됩니다. 인터넷 하면 역시 IP계층이 가장 많이 사용됩니다. TCP/IP는 계층이 아니라 프로토콜이라는 사실이 중요합니다.  

 

그중 IP는 Internet Layer에 해당되는데, 호스트 간의 라우팅을 담당합니다. 

이 계층에서 동작하는 프로토콜은 IP, ARP, RARP, ICMP, IGMP 등등이 존재합니다.

ICMP도 이 계층에 존재합니다. 이 프로토콜을 사용하는 대표적인 프로그램이 PING입니다. 사람들이 많이 착각하는 게 ping을 날릴 때 포트도 찾는다는 것? 포트는 전송계층에서 사용됩니다. 그래서 ping에서는 사용하지 못하죠.

 

 

[ TCP ]

OSI 7 계층의 전송계층과 동일한 신뢰성 있는 데이터 전송을 담당하는 계층입니다. 

process-to-process 전송을 하기 위해서는 논리적인 주소가 필요합니다. 위에서 ping에서는 포트를 사용하지 못하지만, 이 계층에서는 논리적인 주소, 바로 포트 번호를 논리적 주소로 사용합니다.

 

전송 계층에서는 TCP와 UDP가 존재합니다. UDP도 많이 발전되어 구글에서도 UDP를 열심히 연구 및 반영하고 있다는 점에 기반하면 둘 다 열심히 공부해야 하는 프로토콜입니다.

 

 

[별첨]

응용 계층 설명은 빠질 수 없습니다. 사용자와 맞닿아 있는 부분이기 때문입니다.

HTTP, Telent, SSH, FTP, SMTP, POP3, DNS 등등 응용계층 프로토콜은 전송계층을 기반으로 동작하는 것들이 많습니다. 

 

 

[ TLS Layer ]

 

TLS 계층은 전송 계층 위에서 따로 동작하게 됩니다. TLS를 사용하는 애플리케이션 프로토콜에는 S가 붙게 되는데 TLS기반의 HTTP는 HTTPS라고 지칭합니다. FTP는 그러면 FTPS라고 하겠지요.

 

"TCP는 연결지향형 UDP는 비연결 지향 프로토콜입니다."라는 문구를 많이 보셨을 것입니다. 
TLS는 세션과 연결별로 상태 정보를 유지하기 때문에 연결 지향이라고 할 수 있습니다. 
위의 그림의 과정(Full Handshake)을 통해서 세션을 생성하고 이 세션 정보를 공유하는 여러 연결을 Abbreviation Handshake(축약)을 통해서 성립합니다. 즉 이미 세션이 존재할 때 사용한다는 말입니다.

 

여기서 연결이란 서버와 클라이언트 간 통신의 단위입니다. 세션은 그 연결의 다수로 이루어지며 한번 성립되면 다음 연결을 위해서 session id, negotiated cryptography parameters 등을 지원합니다. 
위의 그림대로 한번 연결을 한후에 연결을 종료한 이후 다음 연결에 이 세션에 대한 정보를 이용해 별도의 과정 없이 연결을 할 수 있다는 이야기입니다.

 

• SSL Handshake protocol
  
   HTTPS 통신과정에서도 송신자와 수신자가 암호화 통신을 하기 위한 방법과 수단에 대해서 공유합니다. 대칭키를 노출시키지 않고 Client가 Server에게 전송하기 위해 규약에 따라 진행함을 뜻합니다. 이 과정에는 SSL 인증서 전달, 대칭키 전달, 암호화 알고리즘 결정, SSL/TLS 프로토콜 결정 등이 포함됩니다.
  이 과정에서 암호키를 결정합니다.
  
  

  

   여기서 파란색 칸과 노란색 칸은 네트워크 상에서 전달되는 IP Packet을 표현한 것입니다.

상단에 존재하는 SYN, SYN ACK, ACK는 TCP layer의 3-way handshake로 HTTPS가 TCP 기반의 HTTP 프로토콜에 SSL을 적용한 프로토콜이기 때문에 SSL Handshake 이전 연결을 생성하기 위해 실시하는 과정이며

ClientHello, ServerHello, Certificate 등등 노란색 상자의 패킷들이 SSL Handshake입니다.

 

 

Client Hello

 

클라이언트가 서버에 첫 연결을 시도하며 전송하는 패킷입니다. 자신이 사용 가능한 Cipher Suite 목록, Session ID, SSL Protocol Version, Random byte 등을 전달합니다.
Cipher Suite는 SSL Protocol version, 인증서 검정, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고 있는 존재로 선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화하게 됩니다.  

Clienthello Packet에는 다음과 같이 중요 매개변수를 보냅니다.

 

• Random Bytes : 클라이언트가 보안 난수 생성기를 사용하여 랜덤 바이트를 생성해야 합니다. 난수 생성을 위한 엔트로피 소스는 운영체제 및 클라이언트 소프트웨어 구현에 따라 다릅니다.
• Session ID : 과거에 클라이언트와 서버 간에 TLS/SSL 세션이 설정된 경우 이 식별자는 이 세션의 암호화 매개변수를 업데이트하는 데 사용할 수 있는 이전 세션 ID값을 가질 수 있습니다. 새로운 세션에는 비어있습니다.
• Cipher Suite List : 클라이언트는 선호하는 순서대로 지원하는 Cipher Suite 목록도 보냅니다. 
  

  

  Cipher Suite 구성

  
  
  
  

Server Hello

Client Hello의 응답으로 Server Hello 

클라이언트가 보내온 ClientHello Packet을 받아 서버에서 지원하는 Cipher Suite 중 하나를 선택하여 Client에게 이를 알려줍니다. 또한 자신의 SSL/TLS protocol의 version 등도 같이 전송합니다. 

• Random Bytes : 클라이언트와 독립적으로 서버에서 생성된 임의의 숫자입니다.
• Version : 서버의 TLS/SSL 버전을 알려줍니다.
• Cipher Suite : 클라이언트가 선호하는 Cipher Suite 중 선택한 것을 알려줍니다.

 

Server Certificate

 

Server Hello가 완료된 이후 서버는 브라우저, 모바일 장치에 있는 루트 인증 기관(CA) 인증서 중 하나에 의해 암호로 확인할 수 있는 인증서 (또는 인증서 체인)를 보내야 합니다.

 

인증서 확인 단계는 TLS/SSL 프로토콜의 일부가 아니라는 점 알아야 합니다. 

encrypted 필드는 실제로 첫 번째 인증서와 연결된 디지털 서명입니다. 

algorithmIdentifier 필드는 SHA-256 해시 값이 상위 인증서 Authority G2에 있는 인증기관의 RSA(비공개) 키를 사용하여 서명되었음을 의미합니다. 

그러면 브라우저는 Google Internet Authority G2 인증서에 포함된 해당 공개 키를 사용하여 서명을 확인합니다. 

루트 CA 바로 아래에 있는 CA인증서까지 동일한 확인 단계가 계속됩니다. 루트 CA 인증서는 브라우저에서 암시적으로 신뢰함으로 검증이 필요하지 않습니다.

 

다음은 인증서 체인의 첫 번째 인증서에 포함된 공개 키입니다.

 

위 인증서에는 www.google.com  서버의 RSA 공개 키가 포함되어 있습니다. 서버가 디지털 서명 알고리즘 선택 시 RSA를 포함하는 암호 제품군을 선택했기 때문입니다. 이 공개 키는 핸드 셰이크 이후 단계에서 디지털 서명 목적으로 사용됩니다.

 

Server에서 자신의 인증서를 Client에게 전달합니다. 인증서 내부에는 Server가 발행한 공개키가 들어 있습니다.
Client는 Server가 보낸 CA( Certificate Authority, 인증기관)의 개인키로  암호화된 인증서를 이미 모두에게 공개된 CA의 공개키를 사용하여 복호화합니다. 

복호화가 성공했다면 이 서버의 인증서는 공인업체에서 인증된 인증서를 가지고 있다는 것이 증명되는 것이고
실패했다면 가짜라는 걸 알 수 있을 것입니다.  즉 클라이언트가 서버를 검증하는 작업을 거치는 것입니다.

 

이렇게 인증서를 검증한 후에는 Client는 데이터 암호화에 사용할 대칭키를 생성해야 합니다. 인증서 내부에 있던 Server의 공개키를 이용해 암호화하여 Server에 전송할 것입니다. 

 

여기까지 흐름도 :  클라이언트에서 서버에게 요청 -> 서버에서 CA의 개인키로 암호화된 인증서 제공 -> 모바일 및 브라우저에서 인증서 검증(사설 인증서가 안 되는 이유) -> Client도 CA의 공개키를 가지고 인증서를 복호화 -> 성공 시 인증서 내부의 공개키를 가지고 대칭키를 암호화하여 서버에 전송

 

* TLS/SSL이 http에만 적용되는 건 아니다. 모든 응용 프로토콜에서 하위 레이어로 요청할 때 ssl은 사실 상 세션 layer에 존재하기 때문에 ftp, telent 등도 가능하다. 

 

 

 

Server Key Exchange / ServerHello Done

 

 

"Server Key Exchange" 메시지에서는 Server의 공개키가 SSL 인증서 내부에 없는 경우, Server가 직접 전달함을 의미합니다. 공개키가 SSL 인증서 내부에 있을 경우에는 "Server Key Exchange" 메시지는 생략됩니다. 인증서 내부에 공개키가 있다면 Clinet가 CA의 공개키를 통해 인증서를 복호화한 후 Server의 공개키를 확보할 수 있기 때문입니다.

 

Server Key Exchange 패킷을 확인하면, EC Diffie-Hellman Server Params의 key를 확인할 수 있습니다. 

서버와 클라이언트가 ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)를 사용하기로 합의했기 때문에 ECDHE 알고리즘에서 사용하는 공개 키를 교환해야 합니다. 그렇기 때문에 Server Key Exchange 메시지를 Server에서 전송한 것입니다.

 

• Name Curve : 서버가 계산을 위해 선택한 타원 곡선
• pubkey : 클라이언트가 사용할 서버의 공개키입니다.
• Signature : 서명 값은 서버의 개인 RSA 키를 사용하여 서명되므로 클라이언트는 이 전송된 메시지가 실 요청 서버인지, 혹은 공격자의 서버로 부터온 것인지 확인할 수 있습니다. 이때 복호화를 위해서는 인증서의 공개키를 사용합니다.

Server Hello done 메시지는  Server Hello 메시지의 끝을 나타내면서 종료됩니다.

 

 

Client Key Exchange

 

이전까지 클라이언트는 서버의 인증서를 검증하고, 서버의 공개키를 획득했습니다.  비대칭키 암호화 방식은 안전한 대신 속도가 매우 느리다는 걸 체감하실 수 있을 것입니다.

 

이제 Client는 인증서 내부에서 추출한 혹은 Server부터 받은 공개키를 통해 대칭키를 암호화한 후 Server에게 전달합니다.  이 정보를 pre-master secret이라고 합니다. 서버로 부터받은 난수 값과 클라이언트의 난수 값을 조합하여, 서버의 공개키로 암호화하여 전달합니다.
여기서 전달된 대칭키가 SSL Handshake의 목적이자 데이터를 실제로 암호화할 대칭키(비밀키)입니다. 

 

8.1 RFC 5246에 따라 대칭키의 공식은 다음과 같습니다.

 

master_secret = PRF(pre_master_secret, "master secret", 
                          ClientHello.random + ServerHello.random)

 

PRF(Pesudo Random Function)는 실제로 HMAC-SHA256입니다.  또한 master_secret은 48바이트입니다.

 

이 경우 TLS/SSL record protocol에서 수행되는 master_secret에 대한 수행을 아는 것이 중요합니다. 

Record Protocol은 상위 프로토콜 데이터를 실제로 암호화하여 전송하는 데 사용되는 별도의 하위 프로토콜입니다. master secret은 TLS Record Protocol의 PRF를 사용하여 더 확장됩니다. 

 

     client_write_MAC_key[SecurityParameters.mac_key_length] 
      server_write_MAC_key[SecurityParameters.mac_key_length] 
      client_write_key[SecurityParameters.enc_key_length] 
      server_write_key[SecurityParameters.enc_key_length] 
      client_write_IV[SecurityParameters.fixed_iv_length] 
      server_write_IV[SecurityParameters.

write_key는 데이터 암호화에, write_MAC는 응용 프로그램 수준 데이터의 MAC을 계산하는데, IV는 암호 제품군이 필요한 경우에만 계산됩니다. 클라이언트와 서버 모두 확장된 키를 가지고 있기 때문에 메시지의 무결성을 해독하고 확인할 수 있습니다.

 

 

Change Cipher Spec / Finished

 

 

클라이언트, 서버 모두가 서로에게 보내는 Packet으로 교환할 정보를 모두 교환한 뒤 통신할 준비가 다 되었음을 알리는 패킷입니다. 그리고 Finished Packet을 보내어 SSl Handshake를 종료하게 됩니다.

 

"Change Cipher Spec"은 후속 메시지가 협상된 키 및 알고리즘을 사용하여 암호화되어 전송될 것임을 나타내는 데 사용되는 TLS의 별도 하위 프로토콜입니다.

 

 

"Encrypted Handshake Message"는 최종 완료된 암호 제품군을 Change Cipher Spec 메시지 직후에 전송되는 Fininshed Message를 사용하여 보호합니다. 

만약 서버 또는 클라이언트가 handShake 메시지의 무결성을 확인할 수 없으면 TLS handshake가 실패합니다.

 

 

Encrypted Application Data

 

 

TLS 1.2 까지는 상위 계층 (TLS 레코드 프로토콜)에서 데이터 무결성을 암호화하고 보호하기 위해 MAC-then-Encrypt 기술이 사용되었습니다.  클라이언트는 Client_write_MAC_key 를사용하고 서버는 Server_write_MAC_key를 사용하여 메시지의 MAC을 생성합니다. 이후 실제 데이터와 MAC은 각각 클라이언트와 서버에서 Clinet_write_key, server_write_key를 사용하여 암호화됩니다.

 

 

* 메시지 인증 코드 (Message Authentication Code, MAC)이란?

 암호화된 데이터를 서로 주고받는다 하더라도 이 데이터의 무결성을 확인할 수 없습니다. 이를 확인하기 위해 특정 알고리즘을 사용해 원본 데이터를 일정한 길이의 암호화된 문자열로 변경합니다.

이 특정 알고리즘은 원본 데이터마다 일정한 결괏값을 도출하며 원본 데이터가 변경되면 결괏값 또한 달라지는 특성을 지닙니다. 마치 checksum검사와 비슷합니다. 

이 특정 알고리즘을 hash 알고리즘이라고 부르며 해시 알고리즘이 적용된 암호화된 문자열을 Hash 값이라고 부릅니다. 

해시 알고리즘의 종류에는 MD5, SHA-128, SHA-256, SHA-512 등등 존재합니다. 

 

송신자는 원본 데이터와 해시 알고리즘이 적용된 데이터를 함께 전송하고 수신자는 약속한 해시 알고리즘을 이용해 원본 데이터와 비교해봅니다. 만약 해시 알고리즘이 적용된 원본 데이터가 상대방이 보낸 해시값과 결과가 동일하다면 변조되지 않았음을 증명할 수 있습니다.

 

 

암호화 알고리즘 (블록 암호화 방식)

 

Client와 Server가 공유하는 대칭키와 SSL handshake 과정에서 협의된 암호화 알고리즘을 가지고 데이터를 암호화하여 데이터를 송/수신하게 됩니다. 블록 암호화 방식으로 불리는 이유는 데이터를 일정 길이의 블록으로 나누어 암호화하기 때문입니다.  대칭키의 길이가 길면 길 수록 암호의 강도가 강하다고 합니다. 이 키의 길이는 어떤 암호화 알고리즘을 사용하느냐에 따라 달라집니다. 

 

 

CA( Certificate Authority, 인증기관 )

 

여러 서버들이 자신의 서버를 인증하기 위해서 인증기관에게 SSL 검토 요청을 통해 인증서를 발급받습니다.

그럼 클라이언트는 CA를 통하여 이 전달받은 인증서가 진짜인지 아닌지 확인을 하고 해당 서버와 데이터를 송/수신할 수 있는 것입니다.

 

1. Root CA (최상위 기관)

2. Intermediate CA (중간 기관)

 

계층 구조의 가장 위에는 브라우저, 플랫폼 모두가 신뢰하기로 합의한 최상위 인증기관인 Root CA가 존재합니다.

그 아래에는 중간 기관인 Intermediate CA가 존재합니다.

 

SSL 인증서를 생성하기 위해 서버의 각종 정보와 공개키를 Intermediate CA에 제출합니다.
이후 Intermediate CA는 서버가 제출한 각종 정보를 Intermediate CA의 개인키로 암호화합니다. 

중간 기관은 다시 상위 기관의 검증을 받게 됩니다.  Intermediate CA는 자신의 공개키를 상위 기관에 제출하면 상위 기관이 인증서를 생성하고 암호화 합니다.
마지막으로 Root CA는 스스로 인증서를 생성하고 자신이 암호화 합니다.

 

이러한 인증서의 계층을 인증서 체인 Certificate Chain이라고 합니다. 이러한 하위부터 상위까지의 검증은 서버의 인증서가 중간에 변경됐다고 해도 인증서가 올바른 Intermediate CA, Root CA를 가리키고 있다면 해당 인증서가 진짜라는 것을 증명할 수 있는 것입니다.