TLS 를 사용할 경우 매 세션 성립 시 마다 인증서를 주고받고, 확인하면 세션 성립까지 시간이 오래 걸리기 때문에, 최초 세션 성립을 위해서만 full handshake를 수행하고 다음부터는 일부 과정을 생략한 세션 성립(abbreviated handshake) 를 수행한다. 아래는 TLS 프로토콜 및 세션 성립을 위한 절차(full handshake, abbreviated handshake)를 보고자 한다.
아래는 RFC5246 문서의 내용 중 일부인 TLS handshake 과정을 번역한 내용이다.
TLS 는 handshake protocol에 의해 성사되며, 요약을하면 아래와 같다.
클라이언트가 ClientHello 메시지를 보내면 서버는 ServerHello 메시지로 반드시 응답을 줘야하며, 그렇지 않을 경우 치명적인 에러가 발생하고 세션 연결이 실패할 것이다.
ClientHello 와 ServerHello는 클라이언트와 서버 간 향상된 보안기능(security enhancement capabilities)을 설정하기 위해서 사용된다. ClientHello 와 ServerHello는 프로토콜 버전, 세션 ID, Cipher Suite, 압축 방법의 속성들을 설정한다. 추가적으로, ClientHello.random, ServerHello.random 의 두 랜덤 값을 생성하고 교환한다.
키 교환을 위해서는 다음의 4가지 메시지를 사용한다.
(서버)Certificate, ServerKeyExchange, (클라이언트)Certificate, ClientKeyExchange.
새로운 키 교환 방법은 위 4가지 메시지의 형식을 지정하여 클라이언트와 서버가 공유 비밀(shared secret)에 합의 할 수 있도록 메시지의 사용을 정의하여 만들 수 있다. 이 비밀은 반드시 길어야 한다.(현재 정의된 키 교환 방법은 46 bytes 이상의 비밀(secrets)을 교환한다.)
클라이언트와 서버 간 주고받는 Hello 메시지들 다음으로, 인증을 해야하는 경우 서버는 Certificate 메시지에 인증서를 보낼 것이다. 하지만 서버에 인증서가 없거나, 인증서가 사인을 위한 인증서인 경우 ServerKeyExchange 메시지를 전달할 것 이다. 서버가 인증된 경우, 선택된 cipher suite가 맞다면 클라이언트에게 인증서를 요구 할 것이다. 다음으로, 서버는 handshake의 hello-message 단계가 완료되었음을 표시하는 ServerHelloDone 메시지를 보내고 클라이언트의 응답을 기다린다. 서버가 CertificateRequest 메시지를 보냈다면 client는 반드시 Certificate 메시지를 보내야 한다. 그 다음에는 ClientKeyExchange 메시지를 보내며, 메시지의 내용은 ClientHello와 ServerHello 사이에 선택된 공개 키 알고리즘에 따라 달라진다. 만약 클라이언트가 서명능력(?)과 함께 인증서를 보낼 경우,(If the client has sent a certificate with signing ability,) 디지털설명 CertificateVerity 메시지가 명시적으로 인증서의 개인 키 소유를 확인하기 위해 전송됩니다.
이 시점에서, 클라이언트가 ChangeCipherSpec 메시지를 전송하고, 전송한 암호사양(Cipher Spec)을 현재의 암호 사양(Cipher Spec)에 복사한다. 이후, 새로운 알고리즘, 키 값, 그리고 비밀들(secrects) 기반의 Finished 메시지를 즉시 보낸다. 서버는 응답으로 ChangeCipherSpec 메시지를 보내고, 수신한 암호 사양(Cipher Spec)을 자신의 현재 암호 사양(Cipher Spec)으로 이동 시킨 후 Finished 메시지를 새로운 암호 사양(Cipher Spec)에 맞춰 보낸다. 여기서 handshake는 완료되고, 클라이언트와 서버는 application layer의 데이터 교환을 시작한다(아래 flow chart 참조). application data(application layer의 데이터)는 첫번째 handshake 완료 이전에는 절대 보내서는 안된다.(TLS_NULL_WITH_NULL_NULL 이외의 Cipher Suite가 설정되기 전에는 보내선 안된다.)
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
'*' 은 옵션 또는 상황에 따른 메시지를 나타낸 것으로서, 매번 전달(송신)하지는 않는다.
Note: 파이프라인의 막힘을 피하기 위해 ChangeCipherSpec 는 TLS 프로토콜 컨텐츠 타입과 독립적이며, 실제적으로 TLS 세션성립 메시지가 아니다.
서버와 클라이언트가 이전 세션을 재개 또는 존재하는 세션을 복제하기 위해서(새로운 보안 파라미터들을 협상하는 대신) 아래와 같이 사용한다.
클라이언트는 세션 재개를 위해서 현재 세션의 Session ID를 이용하여 ClientHello 메시지를 보낸다. 서버는 세션 캐쉬를 체크하여 Session ID 가 존재하는지 확인하고, 존재하는 경우 지정된 세션 상태에 맞춰 연결을 재성립하기 위해 동일한 Session ID로 ServerHello 를 보낸다. 클라이언트와 서버 양측 모두 반드시 ChangeCipherSpec 메시지를 보내고 바로 Finished 메시지를 진행해야 한다. 세션 재성립이 완료되면, 클라이언트와 서버는 application layer의 데이터교환을 시작한다(아래 flow chart 참조). 만약 Session ID 가 존재하지 않으면 서버는 새로운 Session ID 를 만들고, TLS 클라이언트와 서버는 full handshake를 수행해야 한다.
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2. Message flow for an abbreviated handshake
각 메시지의 내용과 의미는 다음 섹션에서 이어진다.(rfc 5246참조)
[아래는 원문]
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message to
which the server must respond with a ServerHello message, or else a
fatal error will occur and the connection will fail. The ClientHello
and ServerHello are used to establish security enhancement
capabilities between client and server. The ClientHello and
ServerHello establish the following attributes: Protocol Version,
Session ID, Cipher Suite, and Compression Method. Additionally, two
random values are generated and exchanged: ClientHello.random and
ServerHello.random.
The actual key exchange uses up to four messages: the server
Certificate, the ServerKeyExchange, the client Certificate, and the
ClientKeyExchange. New key exchange methods can be created by
specifying a format for these messages and by defining the use of the
messages to allow the client and server to agree upon a shared
secret. This secret MUST be quite long; currently defined key
exchange methods exchange secrets that range from 46 bytes upwards.
Following the hello messages, the server will send its certificate in
a Certificate message if it is to be authenticated. Additionally, a
ServerKeyExchange message may be sent, if it is required (e.g., if
the server has no certificate, or if its certificate is for signing
only). If the server is authenticated, it may request a certificate
from the client, if that is appropriate to the cipher suite selected.
Next, the server will send the ServerHelloDone message, indicating
that the hello-message phase of the handshake is complete. The
server will then wait for a client response. If the server has sent
a CertificateRequest message, the client MUST send the Certificate
message. The ClientKeyExchange message is now sent, and the content
of that message will depend on the public key algorithm selected
between the ClientHello and the ServerHello. If the client has sent
a certificate with signing ability, a digitally-signed
CertificateVerify message is sent to explicitly verify possession of
the private key in the certificate.
At this point, a ChangeCipherSpec message is sent by the client, and
the client copies the pending Cipher Spec into the current Cipher
Spec. The client then immediately sends the Finished message under
the new algorithms, keys, and secrets. In response, the server will
send its own ChangeCipherSpec message, transfer the pending to the
current Cipher Spec, and send its Finished message under the new
Cipher Spec. At this point, the handshake is complete, and the
client and server may begin to exchange application layer data. (See
flow chart below.) Application data MUST NOT be sent prior to the
completion of the first handshake (before a cipher suite other than
TLS_NULL_WITH_NULL_NULL is established).
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not
always sent.
Note: To help avoid pipeline stalls, ChangeCipherSpec is an
independent TLS protocol content type, and is not actually a TLS
handshake message.
When the client and server decide to resume a previous session or
duplicate an existing session (instead of negotiating new security
parameters), the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to
be resumed. The server then checks its session cache for a match.
If a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both
client and server MUST send ChangeCipherSpec messages and proceed
directly to Finished messages. Once the re-establishment is
complete, the client and server MAY begin to exchange application
layer data. (See flow chart below.) If a Session ID match is not
found, the server generates a new session ID, and the TLS client and
server perform a full handshake.
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2. Message flow for an abbreviated handshake
The contents and significance of each message will be presented in
detail in the following sections.
TLS Hanshake(1.0, 1.2) overview
피드 구독하기:
댓글 (Atom)
댓글 없음:
댓글 쓰기
안녕하세요 :)