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

Security 2019. 7. 13. 00:11

1. TLS Handshake Flow

 

Full Handshake 과정에 대한 전체 흐름은 아래 그림과 같고, TLS Handshake의 session_id가

empty 상태로 처음부터 모든 cipher suites 협의를 새로하는 경우이다.

 

https://www.websequencediagrams.com/#open=522525

(A) Client가 지원하고 선호하는 cipher suits 및 compression 방법들은 서버에게 전달

     구체적인 내용은 RFC5246 정리(2) 참조

  • client_version : client TLS 지원 버전
  • random : client가 생성한 랜던값
  • session_id : Session ID
  • cipher_suites : client가 지원하고 선호하는 cipher suites
  • compression_methods : client가 지원하는 compression method 들
  • extension : 추가정보

(B) (A)에서 client가 전달한 것들 중에 서버가 지원하는 것을 하나 골라 회신

    여기까지가 hellow protocol이고 결국 cipher suites에서 Key Exchange Method를 결정하는 단계이다.

 

(C) *는 옵션항목이다. 옵션항목들은 서버 및 Client 인증과 관련된 동작이다.

    서버의 인증서를 Client에 전달해야 할 필요 시, 서버의 인증서를 실어서 보낸다.

    (A) ~ (B) hellow protocol에서 결정된 Key Exchange Algorithm에 따라서 여기서 전달되는 인증서 내의

    public key (Certificate Key Type) 사용 목적은 정해져 있고 이는 RFC5246 정리(2) 참조

 

(D) (C)에서 전달된 메세지만으로는 premaster secret를 결정할 수 없는 경우에 (C)이 후에 즉각적으로 전달된다.

    보통 Key Exchange Algorithm으로 Diffie-Hellman을 사용할 경우에 해당되고,

    Diffie-Hellman 파라미터가 인증서에 포함되어서 전달되면 implicit 방식이라고 해서 이 과정이 생략되지만

    인증서에 존재하지 않는다면 explicit 방식으로 이 과정을 통해서 파라미터를 전달해야 한다.

    이런 관점에서 인증서 전달만으로 불충분할 때 추가 과정이라고 이해하면 된다.

 

(E) Client에 대한 인증이 필요할 때, 서버가 전달하는 과정이다. 메세지의 Protocol을 이해하기 쉽지 않다.
    서버가 선호하는 Client 서명 방식과 Hash 알고리즘에 대한 정보를 전달하면, 이에 맞게 Client는 응답해야 한다.

    TLS도 상호 인증서 인증을 지원하고 있다고 볼 수 있다.

 

(F) 여기까지 Cipher Suite에서 Key Exchange Algorithm 및 Authentication까지 완료되었다는

    의미로 이 메세지가 서버에서 클라이언트로 전달된다.

 

(G) (E) 과정에서 서버가 클라이언트에 클라이언트 인증서를 요청했다면 서버가 요청한 양식에 맞게 회신해야 한다.

 

(H) 서버 때와 동일하게 클라이언트 인증서만으로 충분한 메세지가 전달되지 않을 경우,

     추가 메세지에 해당한다. 동작 방식과 의미는 서버때와 동일하다.

 

(I) 이 과정 전까지 전달된 메세지들에 대해서 무결성 검사를 수행하는 단계이다.

   이 과정 전까지 전달된 메세지를 다 모아서 메세지의 무결성 검사를 수행한다고 보면된다.

 

change_cipher_spec은 TLS Handshake과정에 있는 것은 아니고 TLS Record 과정에서 있다.

이것의 의미는 지금까지 전달된 내용에 동의함을 나타내고, 새로 동의된 cipher suites로

TLS Record과정을 수행하겠다는 것이다.

 

(J)(K) 완료된 것을 의미하고, TLS Record를 본격으로 전송하기 전에 미리 전송해 보고 문제 없다는

의미로 모두 cipher suites 동의가 완료된 상태이다.

 

즉 아래 cipher suites 중에 하나가 선택된 것이다.

 

 

2. TLS Handshake Flow

 

Resumed Handshake 과정에 대한 전체 흐름은 아래 그림과 같다.

이 경우에는 TLS Handshake의 session_id가 empty상태가 아니고 client가 session_id가

전에 연결 시 사용하였던 값을 서버에 전달하고 서버가 이에 동의한 경우에 해당한다.

 

https://www.websequencediagrams.com/#open=522530

 

3. 마무리

 

TLS 1.2에 대해서 부족하지만 세 페이지 걸쳐 살펴보았다.

TLS 세부 동작에 대한 명확한 이해가 있어야 보안취약점도 도출할 것으로 판단된다.

TLS 보안취약점 관련 내용이 TLS 문서상에 있다. 전반적으로 이해를 한 후에 보니

이제 좀 이해가 되는 듯 하다.

'Security' 카테고리의 다른 글

TLS(v1.2) - RFC5246 정리 (2)  (0) 2019.07.12
TLS(v1.2) - RFC5246 정리 (1)  (0) 2019.06.28
OAuth2.0 - RFC6749 정리 (2)  (0) 2019.06.27
OAuth2.0 - RFC6749 정리 (1)  (0) 2019.06.26
openssl 대칭키 기반 암복호화  (0) 2018.12.24
: