핸드 쉐이크 프로토콜

핸드 쉐이크 프로토콜

• 서버와 클라이언트가 상호 인증
• 암호, MAC 알고리즘, SSL 레코드 안 데이터를 보호하는 데 사용할 암호키 협상
• 핸드 쉐이크 프로토콜은 클라이언트와 서버가 교환한 ;연속 된 여러 메시지로 구성 된다
  • 각 메시지는 아래 3개의 필드로 구성
  • 길이(Length)(3바이트)
  • 내용(Content)(≥0바이트)
  • 유형(Type)(1바이트)

단계 1. 보안 기능 설정

이 단계는 논리적 연결을 시작하고 이 연결과 연관될 보안 기능을 설정합니다

클라이언트는 아래 매개 변수를 갖는 client_hello_message를 보내는 것으로 교환을 시작한다

• 버전 : 클라이언트가 수용할 수 있는 가장 높은 SSL 버전
• 랜덤
  • 클라이언트가 생성한 랜덤값
  • 32-비트 타임스탬프와 안전한 난수 생성기로 생성한 28바이트로 구성된다
  • 이 값은 비표 역할을 하고 재전송 공격을 막기 위해 키 교환 동안 사용
• 세션 ID : 가변 길이의 세션 식별자
  • 값이 0이 아닌 경우의 목적
    • 클라이언트가 기존 연결의 매개 변수 갱신
    • 기존 세션에서 새 연결 생성을 원한다
  • 값이 0인 경우
    • 클라이언트가 새 세션으로 새 연결을 설정하기 원한다
• 암호 도구
  • 클라이언트가 지원하는 암호 알고리즘 도구를 포함하는 목록
  • 선호도가 감소하는 순서로 나열한다
  • 목록의 각 요소는 키 교환 알고리즘과 암호 명세를 정의
• 압축 방법 : 클라이언트가 쓸 수 있는 압축 방법 목록

client_hello_message를 보낸 다음, 클라이언트는 같은 매개 변수를 갖는 server_hello_message를 기다린다

client_hello_message는 다음 규칙이 적용 된다.

• 버전 필드
  • 클라이언트가 제시한 버전의 가장 낮은 것을 선택
  • 서버가 지원하는 가장 높은 버전을 택해서 버전 필드에 포함 시킴
• 랜덤 필드 : 클라이언트의 랜덤 필드와 무관하게 생성
  • 클라이언트의 세션 ID 필드가 0이 아니면 서버는 동일한 값을 사용
  • 세션 ID가 0이라면,서버는 새 세션을 가지기 위한 값을 갖는다
• 암호 도구
  • 클라이언트가 제안한 것들 중에서 서버가 선택한 한 개의 도구를 포함
• 압축 필드 : 큺라이언트가 제안한 것들 중에서 서버가 선택한 압축 방법 포함

암호화 도구 - 키 교환 방법 지원 사항

• RSA는 무엇인가?
• 고정된 Diffie-hellman
• 임시 Diffie-hellman
• 익명 Diffie-hellman
  키 교환 방법 - 암호 명세
• 암호화 알고리즘 : RSA는 무엇인가?,DES Overview,3중 DES Overview
• MAC 알고리즘
• Cipher Type : 스트림 혹은 블록
• IsExportable : 참 또는 거짓
• Hash Size
• Key 요소
• IV Size

단계 2. 서버 인증과 키 교환

서버는 인증이 필요하면 자신의 인증서를 보내는 것으로 단계 2를 ㄹ시작한다.

메시지는 한 개 혹은 연속된 X.509 인증서를 포함한다

인증서 메세지는 익며 Diffie-hellman만 제외하고, 모두 필요로 한다.

아래 상황에서는 server_key_exchange message를 보낼 수있다.

• 익명 Diffie-hellman
• 임시 Diffie-hellman
• RSA는 무엇인가? 키 교환, 이 경우 서버는 RSA를 사용하지만, 서명만하는 RSA 키를 갖는다

아래 2가지 상황에서는 server_key_exchange message를 사용하지 않는다

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

서명

일반적으로 서명은 메시지에 해시를 취하고, 송신자의 개인키를 이용하여 그 해시를 암호화해서 새성한다.

hash(ClientHello.random || ServerHello.random) || ServerParams)

그래서 해시는 Diffie-hellman이나 RSA는 무엇인가? 매개 변수뿐만 아니라 초기 hello message에서 얻은 두 개의 비표까지 포함시켜 적용한다.

이것을 통해 재전송 공격과 위장된 개체를 확실히 막을 수 있다.

• DSS 서명의 경우 해시는 SHA-1 알고리즘을 이용해서 수행한다.
• RSA는 무엇인가? 서명의 경우 MD5와 SHA-1로 해시를 계산하고, 이 2개의 해시를 이어붙인 것을 서버의 개인키로 암호화 한다

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

인증서 유형(Certificate_type) : 공개 키 알고리즘과 그 사용 목적을 나타낸다.

• RSA는 무엇인가?
• DSS
• 고정된 Diffie-hellman에 대한 RSA
• 고정된 Diffie-hellman에 대한 DSS
  Certificate_authorities : 수용할 수 있는 인증 기관의 이름 목록

결론적으로 2 단계의 마지막 메세지는 Server_done Message이다.
이 메시지는 서버 hello와 연관된 메시지의 끝을 나타내기 위해 서버가 보낸다
이 메시지는 매개 변수는 없다

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

server_done message를 수신하면, 인증서를 요구했을 때 클라이언트는 서버가 확실한 인증서를 제공했는지 확인해야 한다.

server_hello 매개 변수가 수용할 만한지를 검사한다.
만일 모든 조건이 만족되면, 클라이언트는 메시지를 서버로 되돌려 보낸다.

certificate message

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

client_key_exchange message
해당 메시지의 유형에 따라 다르다

• RSA는 무엇인가?
  • 사전 마스터 비밀(pre-master secret)을 생성 후, 서버의 인증서로부터 얻은 공개 키를 이용
  • server_key_exchange message에서 얻은 임시 RSA를 이용해 암호화 한다.
• 임시 혹은 익명 Diffie-hellman
  • 클라이언트는 공개 Diffie-hellman 매개 변수를 보낸다
• 고정된 Diffie-hellman
  • 클라이언트의 공개 Diffie-hellman 매개 변수는 인증 메시지 안에 보내진다
  • 이 메시지의 내용은 비어있다.

certificate_verify message
마지막으로, 이 단계에서 클라이언트는 자신의 인증서가 정확하다는 것을 확실히 하기 위해 certificate_verify message를 보낼 수 있다

이 메시지를 보내려면 서명 능력이 있는 클라이언트 인증서가 꼭 있어야 한다.

단계 4. 종료

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

이 메시지는 핸드쉐이크 프로토콜의 일부로 여겨지지는 않지만, 암호 명세 변경 프로토콜을 사용해서 보낸다
클라이언트는 새 알고리즘, 키 그리고, 비밀하에 finished message를 보낸다. 키 교환과 인증 과정이 성공적으로 이루어졌음을 확인한다.

이 두 메시지에 대한 응답으로 서버는 자신의 change_cipher_spec message를 보내고, 계류 상태를 현재 상태 암호 명세로 전송한다.
그리고 자신의 finishied message를 보낸다.

이 시점에서 핸드쉐이크가 완료되면 클라이언트와 서버는 응용 계층 데이터 교환을 시작할 수 있다

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