SSL handshake / TLS handshake

 

이번 포스팅에선 흔히 SSL handshake로 알려져있는 프로토콜에 대해서 알아보도록 하겠습니다. 

 

여러분이 HTTPS URL을 사용한 적이 있으시다면 SSL handshake를 반드시 진행했을겁니다. SSL handshake의 목적은 서버와 클라이언트간 통신에서 데이터 무결성과 클라이언트의 프라이버시를 지켜주기 위한 것입니다. 

 

포스팅에 진행하기 앞서 공개키 암호화에 대한 내용을 알고 계시면 더 나은 이해가 될 것 같습니다. 아래의 링크를 통해 공개키 암호화에 대한 내용을 확인하시면 됩니다!

https://coding-review.tistory.com/329

공개키 암호화

 

그럼 지금부터 본격적으로 SSL handshake에 대해서 알아보도록 하겠습니다. 

 

 

SSL handshake / TLS handshake

SSL handshake는 one-way SSL 과 two-way SSL 이렇게 두가지로 나뉘는데요. 

 

one-way SSL 은 서버의 신원을 클라이언트만 검증합니다. two-way SSL 은 각각의 신원을 서버와 클라이언트 모두가 검증하는 방식입니다. HTTPS 웹사이트에서 보통 사용되는 것은 two-way SSL이라고만 알아두시면 됩니다. 

 

그럼 TLS는 뭐냐?

 

TLS는 Transport Layer Security의 약자로 기존 SSL이 낙후된 기술이기 때문에 새롭게 나온 기술입니다. 그래서 요즘은 SSL이라고 말하기 보다는 TLS라고 말한다고 하네요. 

 

그럼 이제 본격적으로 handshaking에 대해서 알아보죠

 

1. Client Hello

클라이언트는 HTTPS 연결을 시작하기위해서 서버에 요구되는 정보를 보내는 것입니다. 

 

*** ClientHello, TLSv1.2
RandomCookie: *** ClientHello, TLSv1.2
RandomCookie: GMT: -1892413556 bytes = { GMT: -351008774 bytes = { 169, 131, 204, 213, 154, 96, 7, 136, 43, 142, 232, 138, 148, 171, 52, 226, 155, 202, 145, 57, 210, 132, 227, 182, 67, 222, 161, 28, 20 }
Session ID: 239, 10, 92, 143, 185, {}
93, Cipher Suites: [Unknown 0x8a:0x8a, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
………………………………………………

 

위의 로그에서 우리는 TLS v1.2라는 것을 볼 수 있습니다. 이것은 클라이언트가 TLS version 1.2를 지원하는 서버라는 것을 알리기위해 서버측에 보내는 메세지라고 보시면 되겠습니다. 

 

여기서 좀 자세히 보셔야 하는 것이 바로 Cipher Suites 인데요. 일단 설명은 잠시 뒤에 하고 이 Cipher Suites 의 리스트중에서 서버가 하나를 선택해야 합니다. 

 

만약 이 부분이 누락되어 있다면 서버는 이 Cipher 들을 무시하게 되고 연결은 끊어지게 됩니다. 

 

참고) Cipher Suites 란?

Cipher Suites란 SSL 혹은 TLS를 통해 네트워크를 어떻게 안전하게 할지에 대한 구조들의 집합입니다. 

 

Cipher Suites는 HTTPS, FTPS, SMTP나 달느 네트워크 프로토콜을 사용할 때 데이터를 어떻게 안전하게 커뮤니케이션 할것인지에 대한 본질적인 정보를 제공하고 있습니다. 

 

이 정보들에는 어떻게 웹서버가 클라이언트의 트래픽을 안전하게 할것인지 결정하는 것을 도와주는 알고리즘이나 프로토콜에 대해서 적혀있습니다. 

 

또한 Cipher Suites에는 이러한 알고리즘으로 서버가 신뢰성있는 연결을 제공하기위한 방법들이 제시되어있습니다. 

 

 

2. Server Hello

서버는 handshake를 위해 진행하기위한 정보들이 담겨있는 Client Hello 로부터 선택된 설정들을 응답합니다. 

 

*** ServerHello, TLSv1.2
RandomCookie: GMT: 1518335451 bytes = { 19, 150, 56, 42, 168, 202, 151, 43, 174, 226, 187, 53, 135, 67, 244, 170, 59, 176, 105, 150, 50, 112, 167, 83, 192, 48, 171, 64 }
Session ID: {91, 128, 246, 219, 26, 93, 46, 172, 85, 212, 221, 79, 20, 186, 108, 134, 200, 239, 150, 102, 172, 24, 125, 171, 137, 53, 5, 130, 53, 228, 2, 195}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
**

 

서버는 클라이언트가 보내온 Client Hello 패킷을 받아서 Cipher Suite 중 하나를 선택한 다음 클라이언트에게 이를 알립니다 또한 자신의 SSL 프로토콜 버전 등도 같이 보냅니다. 

 

또한 Server Hello 패킷 안에서 서버는 certificate chain과 함께 서버의 인증서를 같이 보냅니다. 이 certificate chain은 클라이언트가 신뢰하는 기관 안에 있는 인증서로 검증됩니다. 

 

** Certificate chain
chain [0] = [
[
 Version: V3
 Subject: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
 Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

Key: Sun RSA public key, 2048 bits
 modulus: 17397562757879783124811507432494159361243533796048391161052829821122241422546147907779583980536886743765496985274573369668302996974964349098220930856827026983442125212118340479175872257401994146576001849503528844021528618702289642320157895787705650513758990004411195572445830613057931701313142946380207623174021376881040589912594451781207558263630010509870784494298596448861811827669869221033031956053367890915692918086795954628465637743034777850129818069833958463245749899713073673871721233098662285260745282530972322499603703844901496085490388703767606182211892402117158287170480970610942364235511256363933850852797
 public exponent: 65537
 Validity: [From: Sat Jul 28 09:08:48 IST 2018,
 To: Sun Jul 28 09:08:48 IST 2019]
 Issuer: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
 SerialNumber: [ 7d834874]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C7 24 EA C3 1E 3E 58 8E BD E3 AE A9 17 01 00 51 .$…>X……..Q
0010: B0 83 D4 68 …h
]
]
]
 Algorithm: [SHA256withRSA]
 Signature:
0000: 4B FA 93 D8 56 78 05 D8 89 BC 2A 3A B6 C3 7F A5 K…Vx….*:….
0010: 03 D8 56 3B E6 9F 0B 17 B5 A2 61 AE 43 46 A4 85 ..V;……a.CF..
0020: 3F 60 2E 04 41 0D C2 7A 35 0D 56 F5 FE 9D 05 51 ?`..A..z5.V….Q
0030: 4A 0B BB 5B 30 ED 85 AF 1C 95 13 15 7D A0 2C DE J..[0………,.
0040: B4 A1 7A D0 5D E4 C0 91 37 C2 ED 37 39 65 7D 02 ..z.]…7..79e..
0050: B5 A4 72 FF EB 6C D5 F4 FD BC 32 FD 9F C8 3A 49 ..r..l….2…:I
0060: 53 64 F8 C6 A0 D6 DB 89 2C 36 60 97 8B 33 8F 95 Sd……,6`..3..
0070: 18 9C 1A F2 F8 F1 66 5E F3 0B 76 54 08 AB A9 88 ……f^..vT….
0080: 5D E9 2D 6B AE 6D 98 09 57 A0 2A 9E C6 6B 89 53 ].-k.m..W.*..k.S
0090: 8E B3 58 C3 8D 73 C5 D3 58 2F 68 F0 4E 0A EF 29 ..X..s..X/h.N..)
00A0: 54 95 00 34 6A C4 D2 56 22 64 05 F9 9F A4 81 44 T..4j..V"d…..D
00B0: 44 77 95 A7 86 5A D3 EE EA 8E 06 19 ED 94 F1 83 Dw…Z……….
00C0: F4 A1 F4 A0 76 94 02 40 30 C0 95 6A F2 4F 32 BB ….v..@0..j.O2.
00D0: 79 A2 1B 40 F5 EB 37 5B B7 0C FA 18 DE 04 18 7D y..@..7[……..
00E0: 5A 1A 95 D7 E7 00 4C 7F 3C 71 CE 8E 03 07 BD 50 Z…..L.<q…..P
00F0: 6D 49 52 75 66 D2 CA 45 AB B8 EE B1 C2 C9 72 8A mIRuf..E……r.
]
***

 

3. Server Key Exchange Message

이 메세지는 pre-master secret을 만들기위해 서버에대한 세부사항을 요청하는 클라이언트에게 서버가 보내는 메세지입니다. 이 메세지는 RSA 키 교환 알고리즘이나 다른 키 교환 알고리즘이 아니라면 보내지지 않는데요. 

 

즉, 서버의 공개 키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달한다는 얘기입니다. 공개 키가 SSL 인증서 내부에 있을 경우 Server Key Exchange는 생략됩니다. 

 

인증서 내부에 서버의 공개 키가 있다면, 클라이언트가 인증기관의 공개 키를 통해서 인증서를 복호환 한 후 서버의 공개 키를 확보할 수 있습니다. 그리고 서버가 행동을 마쳤음을 전달하죠. 

 

 

4. Certificate

서버가 자신의 SSL 인증서를 클라이언트에게 전달합니다. 인증서 내부에는 서버가 발행한 공개 키가 들어있습니다. 클라이언트는 서버가 보낸 인증기관의 개인키로 암호화된 이 SSL 인증서를 이미 모두에게 공개된 인증기관의 공개키를 사용하여 복호화합니다. 

 

복호화에 성공하면 인증서는 인증기관이 서명한 것이 맞으니 진짜임을 검증할 수 있습니다. 

 

** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Cert Authorities:
<CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB>
<CN=client, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB>
*** ServerHelloDone

 

위에서 보면 SSL 인증서가 무슨 알고리즘으로 암호화되어있고, 무슨 Hash 알고리즘으로 서명되었는지 확인할 수 있습니다. 

 

 

5. Client Key Exchange 

클라이언트는 데이터 암호화에 사용할 대칭 키를 생성한 후 SSL 인증서 내부에서 추출한 서버의 공개키를 암호화한 후 서버에게 전달합니다. 

 

여기서 전달된 대칭 키가 SSL handshake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 대칭키입니다. 이제 키를 통해 클라이언트와 서버가 실제로 교환하고자 하는 데이터를 암호화합니다. 

 

 

6. ChangeCipherSpec / Finished

ChangeCipherSpec 패킷은 클라이언트와 서버 모두가 서로에게 보내는 패킷으로 교환할 정보를 모두 교환한 뒤 통신할 준비가 다 되었음을 알리는 패킷입니다. 그리고 Finished 패킷을 보내어 SSL handshake를 종료하게 됩니다. 

 

 

 

이제 모든 handshaking 과정을 알아봤습니다. 이제 정리할겸 그림으로 정리해보도록 하겠습니다. 

 

그림으로 보는 SSL handshake

1. 사이트는 인증기관에 사이트의 정보와 공개 키를 보낸다

 

 

2. 인증기관은 자신의 개인키로 사이트의 정보와 공개 키에 대해 암호화하여 인증서를 생성한 뒤 인증서를 사이트에게 전달한다

 

3. 사용자는 인증기관의 공개 키가 브라우저에 내장되어 있다고 가정한다.

4. 사용자는 사이트에 접속을 요청한다 (Client Hello)

5. 사이트는 사용자의 Cipher Suite중 하나를 고르고, 자신의 SSL 프로토콜 버전을 사용자에게 알린다. (Server Hello)

6. 사이트는 자신의 사이트 인증서를 사용자게에 전송한다 (Certificate)

 

7. 사용자는 브라우저에 내장된 인증기관의 공개키를 이용하여 사이트 인증서를 복호화하면서 인증서가 유효한지 검증하고, 사이트의 공개 키를 가져온다. 참고로 현재 사이트의 공개 키가 있으므로 Server Key Exchange 과정은 생략된다. 

 

만약 맨처음 사이트가 인증기관에게 인증서를 받을 때 공개키를 주지 않았다면 이 떄 Server Key Exchange가 일어납니다. 

 

 

8. 사용자는 자신이 전달한 데이터를 암호화 할 대칭키를 만들고, 그 대칭 키를 사이트의 공개키로 암호화한다. 

 

9. 암호화한 대칭 키를 사이트에게 전달한다.

10. 사이트는 자신의 개인 키를 사용하여 사용자의 대칭 키를 복호화하여 사용자 대칭 키를 얻어낸다. 

 

11. 이렇게 얻은 대칭 키를 활용하여 서로가 서로의 데이터를 안전하게 복호화 하면서 통신할 수 있다. 

 

 

 

여기까지 SSL handshake에 대해서 알아봤습니다. 공개키, 개인키, 암호화, 복호화, 인증서 엄청 복잡하실겁니다. 저도 지금 엄청 복잡한데요... ㅜㅜ 

 

조금 쉽게나마 이해를 위해 첨언하자면 

 

참고)

위의 방법은 대칭키 암호화와 비대칭키 암호화를 섞어서 사용하는 방식입니다. 대칭키는 서로 같은 키로 암호화와 복호화를 진행하고 그렇기 때문에 속도가 빠르다는 장점이 있는데요. 그래서 이해하기도 좀 쉬운 편입니다. 

 

하짐나 비대칭키는 서로 다른 키로 암호화와 복호화를 진행하기 때문에 어떤 키로 암호화를 하느냐에 따라서 목적이 달라집니다. 

 

위의 링크에서 공개키 암호화에 대해 어느정도 알고 계시다는 전제하에 말씀드리겠습니다. 

 

개인키로 암호화 = 공개키로 복호화가 가능하다는 얘기 = 공개키는 모두에게 공개되어있다. = 보안적으로는 썩 달가운 상황은 아님

 

즉, 개인키로 암호화는 이 데이터를 보안을위해 암호화하는 의미가 없습니다. 때문에 개인키로 암호화를 한다는 것은 인증에 좀 더 신경쓴 방식이라는 얘기입니다. 

 

공개키로 암호화 = 개인키로 복호화가 가능하다는 얘기 = 개인키는 개인에게 귀속된 키라 폐쇄적 = 보안적으로 굉장히 강력하다는 의미

 

그래서 공개키로 암호화를 한다는 얘기는 이 데이터를 짝이되는 개인키가 아니고서는 절대 열어볼 수 없도록 설계된 것입니다. 

 

때문에 위에서 사이트가 본인의 사이트 정보와 공개 키를 인증기관에 넘기면 인증기관이 "개인키"로 암호화하여 인증서를 보낸다. 라는 의미는 "인증"을 위한 "인증서"이기 때문에 "개인키"로 암호화 한것입니다. 

 

마지막 사용자가 대칭키를 본인의 공개키로 암호화하여 사이트에 보내는 장면이 있습니다. 그리고 이를 받은 사이트는 본인의 개인키로 복호화하여 대칭키를 획득하죠. 이는 대칭키가 유출되면 곤란한 상황이기 떄문에 "공개키"로 암호화를 한것입니다. 

 

 

이렇게 설명하면 이해가 되실런지 모르겠네요. 아무튼 여기까지 글 마쳐보도록 하고 오늘도 즐거운 하루 되세요~ 저는 다음 포스팅에서 뵙겠습니다. 

 

 

출처

https://steady-coding.tistory.com/512

[네트워크] TLS & SSL Handshake

https://medium.com/@kasunpdh/ssl-handshake-explained-4dabb87cdce

SSL Handshake explained

 

https://venafi.com/blog/what-are-cipher-suites/

What Are SSL Cipher Suites? | Venafi