TLS 지정 프로토콜

TLS 지정 프로토콜

암호 명세 프로토콜

이 프로토콜은 한 바이트로 구성되고, 값 1을 갖는 한 개의 메시지로 구성 된다.
이 메시지의 유일한 목적은 계류 상태를 현재 상태에 복사하는 것이다.
최종적으로 연결에 사용할 암호도구(cipher suites)를 갱신한다

경고 프로토콜

대등 개체에게 TLS 관련 경고를 할 때 사용한다.
TLS 경고 메시지는 현재 상태에 의해 압축되고 암호화 된다

이 프로토콜은 2바이트로 구성 된다ㅓ.

1번째 바이트 : 경고/심각
레벨이 심각이면, TLS는 즉시 연결을 단절한다
동일한 세션 중 다른 연결은 계속 될 수 있지만, 이 세션에는 어떤 새로운 연결을 설정하지 못한다.

2번째 바이트 : 특정 경고 표시

• 특정 경고 표시는 매우 많아서, 자세한 코드 내용까지는 필요할 때 찾아보자

핸드 쉐이크 프로토콜

핸드 쉐이크 프로토콜은 TLS에서 가장 복잡한 부분이다.

핸드 쉐이크 프로토콜의 용도

• 서버와 클라이언트가 서로를 인증

• 암호화 및 MAC 알고리즘, TLS 레코드 안에 보낸 데이터를 보호하는데 사용할 암호 키를 협상

• 메시지는 3개의 필드로 구성

  • 유형(Type)(1바이트)
  • 길이(Length)(3바이트)
  • 내용(Content)(≥0바이트)

핸드 쉐이크 프로토콜 동작 과정을 이제 알아보자

1. 보안 기능 설정

이 단계는 논리적인 연결을 시작하고, 연결과 연관될 보안 기능을 설정하는데 사용 된다.

클라이언트가 client_hello message 를 보내는 것으로 교환을 시작한다.

• 버전 : 클라이언트가 수용 할 수 있는 가장 높은 SSL 버전
• 랜덤 : 비표 및 재전송 공격 방어 용도
• 세션 : 가변-길이 세션 식별자
• 암호 도구 : 클라이언트가 지원하는 암호 알고리즘(도구) 목록
• 압축 방법 : 클라이언트가 사용할 압축 방법

서버는 응답으로 server_hello message 를 반환한다

• 버전 필드 : 클라이언트가 제시한 가장 낮은 버전, 서버가 지원하는 가장 높은 버전 선택
• 랜덤 필드 :
• 암호 도구 : 클라이언트가 제안한 것들 중 서버가 선택한 한 개의 암호 도구
• 압축 필드 : 클라이언트가 제안한 것들 중 서버가 선택한 압축 방법

암호 도구 매개 변수

• 첫 번째 요소 : 키 교환 방법
• 2 번째 요소 : 암호 명세

2. 서버 인증과 키 교환

서버는 인증이 필요하면, 자신의 인증서(certificate)를 보내는 것으로 이 단계를 시작한다
오가는 메시지에는 X.509 인증서가 포함 된다 (익명 Diffie-hellman을 제외하고는 무조건 포함)

다음으로 클라이언트가 요구한다면, server_key_exchange 를 보낼 수도 있다.
단, 아래 두 경우에는 요구하지 않는다

1. 서버가 고정된 Diffie-hellman 매개 변수와 함께 인증서를 보냈을 경우
2. RSA는 무엇인가? 키 교환을 사용한 경우

다음으로, 익명이 아닌 서버(익명 Diffie-hellman을 사용하지 않는 서버)는 클라이언트에게 인증서를 요구할 수 있다.
certificate_request message 는 매개변수로 certificate_type과 certificate_authorities를 사용한다.

• 인증서 유형(타입)은 공개 키 알고리즘과 그 것의 사용 목적을 나타낸다
• certificate_authorities는 수용할 수 있는 인증 기관의 이름 목록이다

2단계의 마지막에는 server_done message 를 전송한다.

3. 클라이언트 인증과 키 교환

server_done message 를 수신하면, 인증서를 요구했을 때 클라이언트는 서버가 확실한 인증서를 제공했는지 확인해야 한다.
그리고, server_hello 매개변수가 수용할 만한지를 검사한다.

만일 모든 조건이 만족되면, 클라이언트는 받은 메시지를 서버로 되돌려 보낸다

서버가 인증서를 요구했다면, 클라이언트는 certificate message 를 보내는 것으로 이 단계를 시작한다.
적합한 인증서가 없으면, 클라이언트는 대신에 no_certificate 경고를 보낸다

다음은 client_key_exchange message 이다.
마지막으로, certificate_verify message 를 보냄으로서 자신의 인증서가 정확하다는 것을 서버에게 알린다

4. 종료

이 단계는 안전한 연결 설정을 완성하는 단계이다.
클라이언트는 change_cipher_spec emssage 를 보내고, 계류 상태 암호 명세(CipherSpec)을 현재 상태 암호 명세에 복사한다

이 메시지는 핸드 쉐이크 프로토콜의 일부로 여겨지지 않지만, 암호 명세 변경 프로토콜로서 보낸다

클라이언트는 새 알고리즘, 키, 그리고 비밀 하에 즉시 finished message 를 보낸다.
finished message 는 키 교환과 인증 과정이 성공적으로 이루어졌음을 알린다
서버가 이 메시지를 보내면, 핸드쉐이크가 완료되며 클라이언트와 서버는 응용 계층 데이터 교환을 시작 할 수 있다

부족한 점이나 잘못 된 점을 알려주시면 시정하겠습니다 :>