TLS 핸드셰이크의 원리는 무엇일까요?  | SSL 핸드셰이크

TLS 핸드셰이크란 무엇일까요?

TLS is an encryption and authentication protocol designed to secure Internet communications. A TLS handshake is the process that kicks off a communication session that uses TLS. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the cryptographic algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works.

TLS 핸드셰이크와 SSL 핸드셰이크

SSL, or Secure Sockets Layer, was the original security protocol developed for HTTP. SSL was replaced by TLS, or Transport Layer Security, some time ago. SSL handshakes are now called TLS handshakes, although the "SSL" name is still in wide use.

TLS 핸드셰이크는 언제 발생할까요?

A TLS handshake takes place whenever a user navigates to a website over HTTPS and the browser first begins to query the website's origin server. A TLS handshake also happens whenever any other communications use HTTPS, including API calls and DNS over HTTPS queries.

TLS 핸드셰이크는 TCP 연결이 TCP 핸드셰이크를 통해 열린 후에 발생합니다.

TLS 핸드셰이크 중에는 어떤 일이 발생할까요?

TLS 핸드셰이크 과정 중에는 클라이언트와 서버가 함께 다음을 수행합니다.

• 사용할 TLS 버전(TLS 1.0, 1.2, 1.3 등)을 지정합니다
• 사용할 암호 제품군(아래 참조)을 결정합니다
• 서버의 공개 키와 SSL 인증서 기관의 디지털 서명을 통해 서버의 ID를 인증합니다
• 핸드셰이크가 완료된 후에 대칭 암호화를 사용하기 위하여 세션 키를 생성합니다

TLS 핸드셰이크가 이루어지는 단계는 어떻게 될까요?

TLS 핸드셰이크는 클라이언트와 서버가 교환하는 일련의 데이터그램, 즉 메시지입니다. TLS 핸드셰이크는 여러 단계로 이루어집니다. 그 과정에서 클라이언트와 서버는 핸드셰이크를 완료하고 추가 대화를 가능하게 하는 데 필요한 정보를 교환합니다.

The exact steps within a TLS handshake will vary depending upon the kind of key exchange algorithm used and the cipher suites supported by both sides. The RSA key exchange algorithm, while now considered not secure, was used in versions of TLS before 1.3. It goes roughly as follows:

1. '클라이언트 헬로' 메시지: 클라이언트가 서버로 "헬로" 메시지를 전송하면서 핸드셰이크를 개시합니다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 지원되는 암호 제품군, 그리고 "클라이언트 무작위"라고 하는 무작위 바이트 문자열이 포함됩니다.
2. '서버 헬로' 메시지: 클라이언트 헬로 메시지에 대한 응답으로 서버가 서버의 SSL 인증서, 서버에서 선택한 암호 제품군, 그리고 서버에서 생성한 또 다른 무작위 바이트 문자열인 "서버 무작위"를 포함하는 메시지를 전송합니다.
3. 인증: 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증합니다. 이를 통해 서버가 인증서에 명시된 서버인지, 그리고 클라이언트가 상호작용 중인 서버가 실제 해당 도메인의 소유자인지를 확인합니다.
4. 예비 마스터 암호: 클라이언트가 "예비 마스터 암호"라고 하는 무작위 바이트 문자열을 하나 더 전송합니다. 예비 마스터 암호는 공개 키로 암호화되어 있으며, 서버가 개인 키로만 해독할 수 있습니다. (클라이언트는 서버의 SSL 인증서를 통해 공개 키를 받습니다.)
5. 개인 키 사용: 서버가 예비 마스터 암호를 해독합니다.
6. 세션 키 생성: 클라이언트와 서버가 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호를 이용해 세션 키를 생성합니다. 모두 같은 결과가 나와야 합니다.
7. 클라이언트 준비 완료: 클라이언트가 세션 키로 암호화된 "완료" 메시지를 전송합니다.
8. 서버 준비 완료: 서버가 세션 키로 암호화된 "완료" 메시지를 전송합니다.
9. 안전한 대칭 암호화 성공: 핸드셰이크가 완료되고, 세션 키를 이용해 통신이 계속 진행됩니다.

All TLS handshakes make use of asymmetric cryptography (the public and private key), but not all will use the private key in the process of generating session keys. For instance, an ephemeral Diffie-Hellman handshake proceeds as follows:

1. 클라이언트 헬로: 클라이언트가 프로토콜 버전, 클라이언트 무작위, 암호 제품군 목록을 포함하는 클라이언트 헬로 메시지를 전송합니다.
2. 서버 헬로: 서버가 SSL 인증서, 선택한 암호 제품군, 서버 무작위를 포함하는 응답을 전송합니다. 위에 설명한 RSA 핸드셰이크와 달리, 서버는 이 메시지에 다음 내용도 포함합니다(단계 3).
3. Server's digital signature: The server computes a digital signature of all the messages up to this point.
4. Digital signature confirmed: The client verifies the server's digital signature, confirming that the server is who it says it is.
5. Client DH parameter: The client sends its DH parameter to the server.
6. 클라이언트와 서버가 예비 마스터 암호를 계산: RSA 핸드셰이크의 경우에서처럼 클라이언트가 예비 마스터 암호를 생성하여 서버로 전송하는 대신, 클라이언트와 서버가 서로 교환한 DH 매개변수를 사용하여 일치하는 예비 마스터 암호를 별도로 계산합니다.
7. 세션 키 생성: 이제 클라이언트와 서버가 RSA 핸드셰이크에서와 마찬가지로 예비 마스터 암호, 클라이언트 무작위, 서버 무작위를 사용하여 세션 키를 계산합니다.
8. 클라이언트 준비 완료: RSA 핸드셰이크와 동일합니다.
9. 서버 준비 완료
10. 안전한 대칭 암호화 성공

*DH 매개변수: DH는 Diffie-Hellman을 의미합니다. Diffie-Hellman 알고리즘은 지수 계산을 이용해 동일한 예비 마스터 암호를 생성합니다. 서버와 클라이언트가 각자 계산을 위한 매개변수를 제공하고, 각자 서로 다른 계산 결과가 나오지만, 합치면 결과가 동일해집니다.

임시 Diffie-Hellman 핸드셰이크와 다른 유형의 핸드셰이크 간 차이, 그리고 이들 핸드셰이크가 FS(Forward Secrecy, 순방향 비밀성)에 도달하는 방식에 대한 자세한 내용은 Keyless SSL이란 무엇일까요?를 참고하세요.

What is different about a handshake in TLS 1.3?

TLS 1.3 does not support RSA, nor other cipher suites and parameters that are vulnerable to attack. It also shortens the TLS handshake, making a TLS 1.3 handshake both faster and more secure.

The basic steps of a TLS 1.3 handshake are:

• Client hello: The client sends a client hello message with the protocol version, the client random, and a list of cipher suites. Because support for insecure cipher suites has been removed from TLS 1.3, the number of possible cipher suites is vastly reduced. The client hello also includes the parameters that will be used for calculating the premaster secret. Essentially, the client is assuming that it knows the server’s preferred key exchange method (which, due to the simplified list of cipher suites, it probably does). This cuts down the overall length of the handshake — one of the important differences between TLS 1.3 handshakes and TLS 1.0, 1.1, and 1.2 handshakes.
• Server generates master secret: At this point, the server has received the client random and the client's parameters and cipher suites. It already has the server random, since it can generate that on its own. Therefore, the server can create the master secret.
• Server hello and "Finished": The server hello includes the server’s certificate, digital signature, server random, and chosen cipher suite. Because it already has the master secret, it also sends a "Finished" message.
• Final steps and client "Finished": Client verifies signature and certificate, generates master secret, and sends "Finished" message.
• 안전한 대칭 암호화 성공

0-RTT mode for session resumption

TLS 1.3 also supports an even faster version of the TLS handshake that does not require any round trips, or back-and-forth communication between client and server, at all. If the client and the server have connected to each other before (as in, if the user has visited the website before), they can each derive another shared secret from the first session, called the "resumption main secret." The server also sends the client something called a session ticket during this first session. The client can use this shared secret to send encrypted data to the server on its first message of the next session, along with that session ticket. And TLS resumes between client and server.

암호 제품군이란 무엇일까요?

A cipher suite is a set of algorithms for use in establishing a secure communications connection. There are a number of cipher suites in wide use, and an essential part of the TLS handshake is agreeing upon which cipher suite will be used for that handshake.

TLS/SSL에 대한 자세한 내용은 SSL의 작동 원리는 무엇일까요?를 참고하세요. 웹 사이트가 TLS를 올바로 사용 중인지 테스트하려면 Cloudflare 진단 센터를 방문하세요.