SSL 프로토콜

1. Handshake

 - SSL이 암호화 처리를 하기 위해서 정보를 결정하는 단계이다.

 - TCP에서의 3-Way Handshake(SYN-SYN/ACK-ACK)와는 다른 것이다.

 - TCP의 3-Way Handshake가 수행된 후, 이 Handshake를 이용하여 암호화 방식, 키, 해쉬 함수 등을 암호화를 위한 정보를 결정한다. 그 정보를 사용해 데이터를 암호화하여 전송한다.

2. 사용 방식 결정

 - 어떤 방식을 사용해서 작업할 것인지 결정한다.

  

a. Client Hello

  . Client는 서버로 'Client Hello'로 클라이언트가 사용할 수있는 조합 리스트를 제시한다.

  . 암호화 방식, 압축알고리짐과 함께 앞서 설명한 다이제스트 생성을 위한 해쉬 함수등의 리스트를 제시한다.

Client Hello. The client initiates a session by sending a 'Client Hello' message to the server. The Client Hello message contains:

• Version Number. The client sends the version number corresponding to the highest version it supports. Version 2 is used for SSL 2.0, version 3 for SSL 3.0, and version 3.1 for TLS. Although the IETF RFC for TLS is TLS version 1.0, the protocol uses 3.1 in the version field to indicate that it is a higher level (newer and with more functionality) than SSL 3.0.
  
  
• Randomly Generated Data. ClientRandom[32], the random value, is a 4-byte number that consists of the client’s date and time plus a 28-byte randomly generated number that will ultimately be used with the server random value to generate a master secret from which the encryption keys will be derived.
  
  
• Session Identification (if any). The sessionID is included to enable the client to resume a previous session. Resuming a previous session can be useful, because creating a new session requires processor-intensive public key operations that can be avoided by resuming an existing session with its established session keys. Previous session information, identified by the sessionID, is stored in the respective client and server session caches.
  
  
• Cipher Suite. The A list of cipher suites available on the client. An example of a cipher suite is TLS_RSA_WITH_DES_CBC_SHA, where TLS is the protocol version, RSA is the algorithm that will be used for the key exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC mode), and SHA is the hash function.
  
  
• Compression Algorithm. The requested compression algorithm (none currently supported).

 b. Server Hello

  . Server는 Client에서 전달 받은 리스트 중에서 서버에서도 사용가능한 알고리즘 중 최상위 버전의 암호화 방식을 선택하여 통신에 사용할 알고리짐을 결정한다.

Server Hello. The server responds with a Server Hello message. The Server Hello message includes:

• Version Number. The server sends the highest version number supported by both sides. This is the lower of: the highest version number the server supports and the version sent in the Client Hello message.
  
  
• Randomly Generated Data. ServerRandom[32], the Random Value, is a 4-byte number of the server’s date and time plus a 28-byte randomly generated number that will be ultimately used with the client random value to generate a master secret from which the encryption keys will be derived
  
  
• Session Identification (if any). This can be one of three choices.
  
  
  • New session ID – The client did not indicate a session to resume so a new ID is generated. A new session ID is also generated when the client indicates a session to resume but the server can’t or won’t resume that session. This latter case also results in a new session ID.
    
    
  • Resumed Session ID– The id is the same as indicated in the client hello. The client indicated a session ID to resume and the server is willing to resume that session.
    
    
  • Null – this is a new session, but the server is not willing to resume it at a later time so no ID is returned.
    
    
• Cipher Suite. The server will choose the strongest cipher that both the client and server support. If there are no cipher suites that both parties support, the session is ended with a “handshake failure” alert.
  
  
• Compression Algorithm. Specifies the compression algorithm to use (none currently supported).

3. 통신 상대 인증

 - 올바른 서버와 통신하고 있는지를 서버 인증서를 사용해 확인한다. 앞서 설명한 SSL의 사용 목적중 '위장' 부분이 이로 인해 검증된다. 

 - 위의 단계에서 알고리즘 방식을 결정했다고 하더라도 중간데 다른 서버로 데이터를 중간에 낚아 채서 처리할수 도 있다. 그래서 서버에서는 'Server Certificate'를 Client로 전송하여 올바른 서버임을 어필한다.

 - 'Server Hello Done'으로 서버는 모든 정보는 전송 했음을 알린다. 

 - Client 는 루트 인증서를 이용해 서버로 부터 전달 받은 인증서를 검증한다. 

 - 루트 인증서라 함은 인증서의 인증처로 기본적으로 OS와 브라우저에는 루트 인증서가 처음 부터 포함되어 있다. 

 - 검증 단계에서는 인증서의 유효기간과 접속한 URL도 확인한다. 

4. 키 교환

 - 이 단계에서는 데이터 전송에 사용하는 공통키를 교환한다. SSL에서 실제로 데이터 전송 시 사용하는 키는 공통키이다. 이 공통키를 공개키로 암호화하여 전달한다.

 - Client가 서버의 인증서를 통하여 올바른 서버라고 판단이 되면 'Premaster Secret'라는 공통키 재료를 만들어서 서버에 보낸다. 

 - 실제 공통키는 'Premaster Secret'와 Client Hello시 취득한 'client random'과 Server Hello시 취득한 'server random'을 가지고 생성한다. 

 - 뒤의 Random값은 이미 Handshake를 통하여 이미 알고 있고 재료가 되는 값만 되면 양방향에서 공통키를 만들수 있다. 

 - 'Premaster Secret'값은 공개키로 암호화를 하여 전송하고 서버에서 암호화된 값을 비밀키로 공통키의 재료를 추출한다.

5. 암호화 통신 시작

 - 이 단계에서는 실제로 사용할 암호화 알고리즘 확인 작업이다. 'Change Cipher Spec'을 서로가 교환해 암호화 알고리즘을 선언한다. 이 작업이 끝나야 암호화한 데이터를 전송하는 단계로 진입하게 된다.

6. 클라이언트 인증(양방향인증, 양자인증)

 - 서버측에서 Client가 올바른 Client 인지 확인하기 위하여 Client에 설치된 Client 인증서를 가지고 올바른 사용자인지 판단하고 인증하게 된다. 앞서 설명한 SSL인증단계안에서 Client에게 인증서를 요구하고 Client는 인증서를 정송하고 서버는 그 인증서를 가지고 접속을 허가한다. 양방간의 인증을 함으로써 안정성을 더욱 높여 준다.

 - 서버 인증서를 Client로 보내는 'Server Certificate'까지는 동일하고 서버가 서버의 인증서를 보낸후 'Certificate Request'로 Client 인증서를 요구하고 신뢰할 수 있는 인증처 리스트를 제시한다.

 - Client는 'Client Certificate'로 자기에세 설치된 클라이언트 인증서를 전송하고 서버 요구에 적합한 클라이언트 인증서를 가지고 있지 않다면 'no certificate' 메시지를 전송하고 서버와의 연결을 끊는다.

 - 'Client Key Exchange'로 Premaster Secret을 전송한다. 이 단계는 일반적인 처리와 동일하며, 그 다음 단계인 'Certificate Verify'로 지금까지 작업한 해쉬값을 비밀키로 암호화해 전송한다. 서버는 전송된 'Certificate Verifty'를 전달받은 Client의 인증서에 있는 공개키로 복원한 수 자신의 해쉬값과 비교하여 변조됨을 확인한다. 

참고 사이트

- http://technet.microsoft.com/en-us/library/cc785811(v=ws.10).aspx