TLS(v1.2) - RFC5246 정리 (2)

1. TLS Handshake Overview

 

이 페이지에서는 TLS Handshake에 대해서 다루도록 한다.

 

TLS Handshake과정은 크게 분류하자면

1) 서버와 클라이언트의 Cryptographic alogorithm을 확인하고 선택하는 단계

2) 클라이언트와 서버를 신분을 확인하는 인증단계

 

1)의 과정은 TLS Record Layer에서 사용될 실제 Security Parameter를 결정하기 위한 과정이고

2)의 과정은 1)의 과정 중에 기밀을 요하는 정보를 주고 받기 위해서 필요한 과정으로 이해가 된다.

2)의 과정에 대표적으로 RSA 알고리즘이 쓰는 것으로 보여진다.

 

TLS Handshake 과정에 사용되는 메세지 형식에 대해서 살펴본다.

 

2. TLS Handshake

 

TLS Handshake 임무를 완수하기 위해서 아래와 같은 메세지들을 상호 교환한다.

 

2.1. hellow_request

 

Server단에서 발행하는 것으로 신규 TLS Handshake이 필요함을 알리기 위한 메세지이다.

 

2.2. client_hellow

 

Server에 처음 접속할 때 또는 hellow_request을 받았을 때 전송. 아래와 같은 정보를 서버에게 전달한다.

 

client_version	client가 지원가능한 최신 TLS 버전
random	client가 생성한 랜덤값
session_id	empyt이면 신규로 새로 Cryptographic Algorithm 협상  값이 존재하면, 기존 설정값 유지 요청(서버가 거부 가능)
cipher_suits	client가 선호하는 순으로 Cryptographic Algorithm 리스트
compression_methods	client가 지원하는 compression method 리스트
extensions	서버에게 추가로 전달해야 할 경우 사용

 

2.3. server_hellow

 

client_hellow을 받은 서버가 회신해야 할 정보이다.

 

server_version	TLS 버전 (clinet가 전달한 버전보다 작고, 서버가 지원할 수 있는 가장 높은 버전
random	server가 생성한 랜덤값
session_id	client에서 보내준 session_id값을 기준으로 검색해서 기존에 접속한 이력이 유효하면 그 값을 사용하고 그렇지 않으면 신규 값을 발행
cipher_suits	client가 보내준 list에서 server가 선택한 single cipher suit
extensions	client가 제공한 값을 그대로 사용

 

2.4. Hellow Extensions 는 무엇인가?

 

정확한 이해는 아니지만 위의 client/server hellow protocol에 extensions라는 항목이 있다.

이 extension에 들어갈 수 있는 추가적인 protocol들이 존재한다.

그 가능한 리스트는 문서 Section 12에 기술되어 있다.

이 문서에서 대표적으로 소개한 extension protocol은 Signature Algorithms 이다.

 

2.5. certificate 메세지를 보면 Key Exchange Algorithm에 따라서 Default Signature 알고리즘이

정리되어 있다. 이 Default Signature 방식은 extension으로 Client가 변경할 수 있다.

하지만 extension 사용하여 구현 시 주의를 해야 한다.

 

이 extension에서 지원되는 Signature 알고리즘은 Hash + Signature이다. 아래 지원 가능 항목이다.

• Hash Algorithm
  • none, md5, sha1, sha224, sha256, sha384, sha512
• Signature Algorithm
  • anonymous, rsa, dsa, ecdsa

2.5. certificate (server)

 

Client나 Server를 인증할 때, Certification이 필요할 경우, 이 Certification 관련 정보를 전달하는 메세지이다.

• certificate_list
  • certification chain 순으로 list를 구성해서 전달한다.
  • X.509v3 certfication format

이 부분은 추가적인 설명이지만, 아래 표는 클라이언트와 서버간에 키 교환 방식과 이 때 인증서를 사용했다면

인증서 내의 공개키는 어떤 역활을 하는지에 대한 것으로 해석하면 맞을 것 같다.

Key Exchange Alg.에서 RSA_PSK를 예로 들면 앞에 RSA는 키 교환 방식을 의미하고 뒤의 PSK는 서명 방식을

의미한다고 보면 아래 표가 이해가 될 것이다.

 

Key Exchange Alg.	Certificate Key Type	설명
RSA RSA_PSK	RSA public key	Certification에 존재하는 RSA public key는 Key Exchanage 과정에서 암호화에 사용된다.
DHE_RSA ECDHE_RSA	RSA public key	Certification에 존재하는 RSA public key는 Key Exchanage 과정에서 서명 검증에 사용된다.
DHE_DSS	DSA public key	위와 의미는 동일하고 서명에 사용
DH_DSS DH_RSA	Diffie-Hellman public key	서명에 사용
ECDH_ECDSA ECDH_RSA	ECDH-capable public key	서명에 사용
ECDHE_ECDSA	ECDH-capable public key	서명에 사용

 

2.6. server_key_exchange

 

certificate(server) 메세지가 서버에서 client로 전달된 직 후, 서버에서 client에게 전달하는 메세지이다.

모든 경우에 전달되는 것은 아니고 certificate(server)만으로는 충분히 client에게 정보를 제공할 수 없을 경우

이 메세지가 추가적으로 전달된다.

문서 기준 Ephemeral Diffie-Hellman Key Exchange Algorithm 사용 시, 아래 정보가 추가로 전달된다.

• dh_p
  • prime modulus for Diffie_Hellman operation
• dh_g
  • generator for DH operation
• dh_Ys
  • dh_Ys = (dh_g^x mod dh_p) (x는 서버가 선택한 Private 값)

위의 세 값이 그대로 전달되거나 Client와 Server의 Random값과 서명되어 전달될 수 있다.

 

2.7. certificate_request

 

보통은 서버가 인증서를 제공하고 클라이언트가 검증하는 형태가 보통이지만, 이 반대의 경우도 지원할 수 있다.

서버는 클라이언트에게 Certification을 요구할 때 사용하는 메세지이다.

•  certificate_types
  • rsa_sign : RSA Key를 포함하고 있는 인증서
  • dss_sign : DSS Key를 포함하고 있는 인증서
  • rsa_fixed_dh : static DH Key를 포함하고 있는 인증서
  • dss_fixed_dh : static DH Key를 포함하고 있는 인증서
• supported_signature_algorithm
• certificate_authorities

위의 세개의 필드로 구성된 정보를 Client에게 주고 인증서를 요청할 수 있다. 예로 Client에서

제공한 인증서는 certificae_type에 정의된 형태의 인증서 양식이여야 하고,

supported_signature_algorithm에 정의된 서명으로 서명되어 있어야 한다. 라는 형식이다.

 

2.8. server_hellow_done

 

이 protocol은 서버에 의해서 Client에 전달되며, 서버는 이제 hellow 관련 protocol 수행은 완료하였다는 의미이다.

 

2.9. ceritificate (client)

 

이 메세지는 server_hellow_done 완료 후에 Client가 서버에 보낼 수 있는 첫번째 메세지이다.

이 메세지는 서버가 certificate_request 메세지를 Client로 보낼을 때 서버로 보내진다.

certficate (client) 메세지 형식은 certificate_request 메세지와 호환성을 갖는다.

 

2.10. client_key_exchange

 

이 메세지는 certificate(client) 뒤에 이어지는 메시지이고, Client에 의해서 항상 보내지는 메세지이다.

이 메세지가 완료되면 Premaster Secret이 결정되고 아래와 같은 메세지가 전달된다.

• RSA-Encrypted Premaster Secret Message
  • Key agreement와 authentication을 위해 RSA가 사용되었고 48 Byte premaster secret이 생성되었다.
  • 생성된 48 Byte Premaster Secret은 Server의 Certificate Public Key 암호화 되었다.
• Client Diffie-Hellman Public Value
  • Client의 Diffie-Hellman Public Value가 클라이언트 인증서에 포함되어 있지 않다면 전송한다.
  • 즉 Diffie-Hellman Public 값이 인증서에 포함되어 있으면 인증서꺼를 사용하고, 포함되어 있지 않으면 추가로 송출한다. 

2.11. certificate_verify

 

이 메세지는 certificate (client)에 뒤이어 전송되는 메세지이며, Client 인증서를 정확하게 검증하기 위해 전송되는 메세이다.

• handshake_messages
  • client_hellow 메세지를 시작으로 certificate_verify 메세지 전까지 메세지를 모두 모아서 supported_signature_algorithms 에 기술된 서명 알고리즘으로 검증한다.

2.12. finished

 

change_cipher_spec 메세지가 전송된 후에 key exchange와 authentication 과정이 성공한 것을 검증하기 위해서 보내지는 메세지이다.

즉 실제 Application Layer의 데이터를 실제 보내기 전에 시험 운행을 하기위한 메세지라고 보면 이해가 쉽다.

 

3. 마무리

 

여기까지 대략적으로 TLS Handshake 과정에서 사용되는 메세지에 대해서 살펴보았다.

상세한 구조와 Protocol은 문서를 참조하면 더 정확하게 확인할 수 있다.