asaf g

Posted on Oct 4, 2020 • Originally published at turtle-techies.com on Jul 11, 2020

Analyzing SSL Handshake Logs

Analyzing SSL handshake logs

SSL 101

Currently, we are in an era of online businesses and for good or bad, we are in a path of becoming an online life form. Meanwhile, cyber crimes and attacks are becoming more of a threat to businesses at each passing day.

If you are an online business owner or stakeholder, one of your main goals is to create a trusted environment for your consumers. You have to win the faith of customers that their money and sensitive details are secured with you. Consumers won’t purchase unless they feel safe with their money and have the trust of receiving the purchased product or service.

In the modern era, the SSL is one of the key elements that create the foundations of trust by establishing a secure connection.

The SSL ensures that the internet connection between two systems and the sensitive data transferring between those two systems is secure which prevents cyber criminals from compromising any information transferred. If you visit an SSL secured website, you will receive a visual indication as below.

So what is this SSL?

The SSL stands for Secure Socket Layer.

Let me give you some insightful details on where this SSL protocol runs.

You might have heard that TCP/IP (Transmission Control Protocol/Internet Protocol) governs the transport and routing of data over the internet. The HTTP protocol runs on top of TCP/IP to support application tasks such as presenting web pages and running relevant functionalities.

The SSL protocol runs above the TCP/IP and below the HTTP. The SSL uses TCP/IP on behalf of HTTP and establishes an encrypted secure connection between two communicating parties (client and server). With the SSL protocol in place, an eavesdropper can only see the connection endpoints but cannot read or modify any of the actual data. Hence it protects users' sensitive data.

Let’s see how the SSL does that?

That is where the SSL-Handshake comes into play.

Deep Dive into SSL Handshake

The SSL-Handshake allows an SSL-enabled server to authenticate itself to an SSL-enabled client and also allows the client to authenticate itself to the remote server. During the handshake, both parties exchange important and unique information that establishes the aforementioned secured connection.

There are two types of SSL-Handshakes:

One-way SSL
Two-way SSL (Mutual SSL)

There is a major difference between these two types of handshakes.

In a one-way SSL, the client validates the identity of the server whereas, in two-way SSL, both the server and the client validate the identity of each other.

Let’s discuss the steps of SSL-Handshake in more detail.

The SSL-Handshake mainly consists of the following steps.

Client Hello
Server Hello
Certificate Chain
Server Key Exchange
Certificate Request (only in two-way SSL)
Server Hello Done
Client Key Exchange
Client Change Cipher Spec
Client Finished
Server Change Cipher Spec
Server Finished

The following diagram illustrates more on the flow.

Let me explain what each step means.

1. Client Hello

The first message is called ‘ClientHello’ which is sent from the client to the server. ClientHello is responsible for sending the fundamental details required by the server to establish a secure connection.
The ClientHello message carries the details such as:

SSL or TLS version
Cryptographic algorithms
Data compression methods supported by the client
Client random

The given handshake logs show that the ClientHello has been sent with TLS v1.2 which tells the server of the supported and preferred TLS version. Also, it shows the list of ciphers that are supported by the client.

Forgot to mention.

The TLS stands for Transport Layer Security who is the successor of SSL. The later versions of SSL come under the TLS.

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1593979669 bytes = { 106, 130, 143, 152, 153, 26, 144, 152, 168, 252, 70, 107, 162, 143, 98, 21, 191, 157, 185, 58, 130, 231, 165, 65, 33, 110, 224, 91 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension extended_master_secret
Extension renegotiation_info, renegotiated_connection: <empty>
***

Once the server receives this message, it selects a suitable cipher suite that it supports from the given cipher suite list by the client. The server will ignore other ciphers that are not recognized or supported. The selection process that happens here leads to the second step, ServerHello.

2. Server Hello

As the name indicates, the ServerHello is sent by the server. The ServerHello message tells the client what are the connection parameters that have been selected by the server from the provided list.

The server considers the received TLS version with the ClientHello and selects the highest supported version which is equal or lower to the client's suggestion. Also, it will select a cipher suite from the presented list of ciphers.

Generally, the ServerHello consists of:

Agreed SSL/TLS version
Session ID
Agreed cipher suite and other relevant details
Server random

*** ServerHello, TLSv1.2
RandomCookie:  GMT: 1593979669 bytes = { 204, 192, 95, 44, 21, 64, 253, 87, 10, 239, 52, 190, 190, 61, 186, 51, 125, 16, 68, 141, 170, 91, 232, 205, 148, 128, 78, 185 }
Session ID:  {95, 2, 51, 21, 21, 21, 188, 149, 248, 189, 8, 38, 152, 164, 142, 100, 130, 187, 177, 23, 237, 154, 136, 93, 124, 112, 147, 126, 43, 86, 219, 51}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension extended_master_secret
***

If the client and server don’t have any common attributes the SSL handshake fails at this point.

3. Server Certificate Chain

The Certificate Chain message is sent by the server along with the ServerHello. This particular message consists of the server's SSL certificate and it’s the intermediate certificate chain.

To establish the trust between both parties, the server should have a valid SSL certificate signed by a Certificate Authority (CA).

Once the certificate is received, the client contacts the server's CA and verifies the server's digital certificate thus confirming the authenticity of the server. The verification process might consist of:

Validating the certificate’s digital signature
Verifying the certificate chain
Checking for certificate details such as domain name, expiration date, etc.

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, ST=AMQ, C=AMQ
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  modulus: 17909370440277738952478021743432069490529460393959126050805622971590660765692586361919607268411957926196894593987779661515762234267984346200511739419991266042217515340629051394016939807213747552584949772262005902231184424962174373631762755583097509054166650866644125680436982880019781047492697566821940066615518316518157033101020228431401518000223024317668304190076399662045036184270398732773568597958342161459714296835776954926256734783011948914891588288449919569310898632115411415768934785779564943363123191032516179643589537811762899108471543653043311642283642184737727344704476726058553680310548513037215719011553
  public exponent: 65537
  Validity: [From: Sun Jul 05 22:36:37 IST 2020,
               To: Sat Oct 03 22:36:37 IST 2020]
  Issuer: CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, ST=AMQ, C=AMQ
  SerialNumber: [    341a9018]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 19 D8 C4 B1 B1 85 FA E1   65 97 80 90 EF 6C AE 56  ........e....l.V
0010: 14 6E DA E1                                        .n..
]
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 44 E5 D4 3F E8 7C 15 E7   B1 E8 F0 45 AB A3 EA 77  D..?.......E...w
0010: 1D 67 3C FC 5B 95 D0 98   F1 B9 28 6C E4 FC D1 6B  .g<.[.....(l...k
0020: CD 7D 9F C3 4C D8 8F CB   E1 A1 63 24 EC E5 A3 5B  ....L.....c$...[
0030: E6 18 12 46 7D 0F E4 14   25 08 B8 3B AB AF E2 CE  ...F....%..;....
0040: A3 FE 93 8E 88 EB 97 62   59 71 3D 5D 92 D0 99 55  .......bYq=]...U
0050: 68 E3 13 1A 7E AD 41 9E   32 DD C0 58 C7 08 81 E4  h.....A.2..X....
0060: C7 8B CF 57 69 A8 0C EA   74 5F 45 8C 6E D9 E2 D1  ...Wi...t_E.n...
0070: B6 E4 B4 D2 5F D0 BD FA   BA CB 98 7B B6 1D 9D E4  ...._...........
0080: 45 DA C9 09 19 71 BD B4   7C 44 CE 6A 48 13 75 A1  E....q...D.jH.u.
0090: 6D DD DC 48 65 0E 05 3B   BA AF 63 42 2E 9F 3B 29  m..He..;..cB..;)
00A0: FE 8E 3D 07 03 04 C4 D7   65 DB 7A FA 45 C1 62 6B  ..=.....e.z.E.bk
00B0: E8 E7 D1 A7 8E 6F 0D 1D   7F 3E 83 66 75 5B 60 45  .....o...>.fu[`E
00C0: 0E BC A1 8B B3 2D 50 1A   E5 3D 02 A5 37 D6 76 DB  .....-P..=..7.v.
00D0: 5A A5 EE 26 B1 06 DC 57   F4 68 3F DA 0F C9 D4 30  Z..&...W.h?....0
00E0: BA B0 DA AD 94 24 B4 15   FF E5 DC 6E 1D 5D F9 58  .....$.....n.].X
00F0: D4 ED 31 9C 11 C0 C9 E8   29 5D F0 45 AF 93 9B CB  ..1.....)].E....

]
***

If the client finds a valid certificate, you will receive a ‘Found trusted certificate’ message followed by the ‘Certificate chain’ at the client side logs.

Found trusted certificate:
[
[
  Version: V3
  Subject: CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, ST=AMQ, C=AMQ
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  modulus: 17909370440277738952478021743432069490529460393959126050805622971590660765692586361919607268411957926196894593987779661515762234267984346200511739419991266042217515340629051394016939807213747552584949772262005902231184424962174373631762755583097509054166650866644125680436982880019781047492697566821940066615518316518157033101020228431401518000223024317668304190076399662045036184270398732773568597958342161459714296835776954926256734783011948914891588288449919569310898632115411415768934785779564943363123191032516179643589537811762899108471543653043311642283642184737727344704476726058553680310548513037215719011553
  public exponent: 65537
  Validity: [From: Sun Jul 05 22:36:37 IST 2020,
               To: Sat Oct 03 22:36:37 IST 2020]
  Issuer: CN=ActiveMQ Artemis Server, OU=Artemis, O=ActiveMQ, L=AMQ, ST=AMQ, C=AMQ
  SerialNumber: [    341a9018]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 19 D8 C4 B1 B1 85 FA E1   65 97 80 90 EF 6C AE 56  ........e....l.V
0010: 14 6E DA E1                                        .n..
]
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 44 E5 D4 3F E8 7C 15 E7   B1 E8 F0 45 AB A3 EA 77  D..?.......E...w
0010: 1D 67 3C FC 5B 95 D0 98   F1 B9 28 6C E4 FC D1 6B  .g<.[.....(l...k
0020: CD 7D 9F C3 4C D8 8F CB   E1 A1 63 24 EC E5 A3 5B  ....L.....c$...[
0030: E6 18 12 46 7D 0F E4 14   25 08 B8 3B AB AF E2 CE  ...F....%..;....
0040: A3 FE 93 8E 88 EB 97 62   59 71 3D 5D 92 D0 99 55  .......bYq=]...U
0050: 68 E3 13 1A 7E AD 41 9E   32 DD C0 58 C7 08 81 E4  h.....A.2..X....
0060: C7 8B CF 57 69 A8 0C EA   74 5F 45 8C 6E D9 E2 D1  ...Wi...t_E.n...
0070: B6 E4 B4 D2 5F D0 BD FA   BA CB 98 7B B6 1D 9D E4  ...._...........
0080: 45 DA C9 09 19 71 BD B4   7C 44 CE 6A 48 13 75 A1  E....q...D.jH.u.
0090: 6D DD DC 48 65 0E 05 3B   BA AF 63 42 2E 9F 3B 29  m..He..;..cB..;)
00A0: FE 8E 3D 07 03 04 C4 D7   65 DB 7A FA 45 C1 62 6B  ..=.....e.z.E.bk
00B0: E8 E7 D1 A7 8E 6F 0D 1D   7F 3E 83 66 75 5B 60 45  .....o...>.fu[`E
00C0: 0E BC A1 8B B3 2D 50 1A   E5 3D 02 A5 37 D6 76 DB  .....-P..=..7.v.
00D0: 5A A5 EE 26 B1 06 DC 57   F4 68 3F DA 0F C9 D4 30  Z..&...W.h?....0
00E0: BA B0 DA AD 94 24 B4 15   FF E5 DC 6E 1D 5D F9 58  .....$.....n.].X
00F0: D4 ED 31 9C 11 C0 C9 E8   29 5D F0 45 AF 93 9B CB  ..1.....)].E....

]

4. Server Key Exchange

The ‘ServerKeyExchange’ message is an optional message which is sent by the server to the client. The client uses the details received from the Server Key Exchange message to generate the pre-master secret.

This message is only required in the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm and won’t be seen in other mechanisms such as RSA key exchange, which don't require the information from the server to generate the pre-master secret. The ECDH key exchange algorithm sends the following public key details to the client.

*** ECDH ServerKeyExchange
Signature Algorithm SHA512withRSA
Server key: Sun EC public key, 256 bits
  public x coord: 46057439580226412250665263866147684562887286117348620148026818665523810505319
  public y coord: 25930488906832570201561097323128777249979681591509199039675514975479400287814
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)

Let’s discuss the differences between these algorithms and handshakes based on them later.

5. Certificate Request

The ‘CertificateRequest’ message is the first indication we get to differentiate the one-way SSL from the two-way SSL. During the one-way SSL, the client validates the authenticity of the server. The authenticity of the client is not checked. However, in two-way SSL, both parties validate the authenticity of each other.

So how does the server validate the client?

It’s kind of the same as how the client does it.

At this step, the server sends the CertificateRequest with the details of expected certificate type, certificate signature algorithms, and certificate authorities. It’s the client's responsibility to send the certificate from its arsenal to the server matching the requirement. However, there is a wild card at this step. If the server sends an empty list of certificate authorities, depending on the client's implementation, it can decide whether to send the certificate or not.

Here is what a Certificate Request looks like.

*** 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=EI Server, OU=EI, O=EI, L=EI, ST=EI, C=EI>

The client sends its certificate chain matching to the requirements sent in the Certificate Request.

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=EI Server, OU=EI, O=EI, L=EI, ST=EI, C=EI
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  modulus: 20633040407737278567218634330232059050042226479044722496122452505410479273023117031844484746505155564073294892298093888208868315188456270185531088712664441886338425740008444649208646876917816694847967760308554699673706712637838857175549988647511729487971524875773472297556010021422655352423126217625806863759012805189832944776623955038735096318822704111503458955521102855569127337450070103240845157800531714174178998060010010408282365398717630638484524135245861883501920626423778221475087217057744850665905219857063710661918813533021515797130163876841737728794450828239304431761997536237765605147373975769055502409267
  public exponent: 65537
  Validity: [From: Sun Jul 05 23:32:01 IST 2020,
               To: Sat Oct 03 23:32:01 IST 2020]
  Issuer: CN=EI Server, OU=EI, O=EI, L=EI, ST=EI, C=EI
  SerialNumber: [    3ded1c63]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9C 15 A6 4E AC 34 89 2A   8D AD 4E 9A 3B 56 81 73  ...N.4.*..N.;V.s
0010: 05 A3 40 4E                                        ..@N
]
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 5A E1 C2 5B 71 AC 72 50   D8 DE 0E 80 10 10 A6 B4  Z..[q.rP........
0010: D6 EC 39 2E DF 24 1D 81   5E E2 39 0F C0 C2 49 CC  ..9..$..^.9...I.
0020: EE D9 5C 44 0A 07 26 23   EE 7E FC C0 32 01 7C 48  ..\D..&#....2..H
0030: 4C CB 7D 56 CB F9 42 1D   75 06 3B 92 1B 8D DE 45  L..V..B.u.;....E
0040: 4E 66 B6 5C 36 C2 07 1F   1C 7D D9 BC 09 FE F1 91  Nf.\6...........
0050: BB 6B 3D 3B F9 5F 86 FB   B1 27 33 CD D0 5C 4F 5F  .k=;._...'3..\O_
0060: 7A 9D 18 41 E3 32 BA 17   58 23 26 29 F2 A9 AE 00  z..A.2..X#&)....
0070: F7 39 64 37 89 D1 B9 D3   90 94 63 68 99 85 D7 22  .9d7......ch..."
0080: 39 E2 E8 BE BB EA 56 17   AF FC 24 14 3A 6C 23 8F  9.....V...$.:l#.
0090: E6 EC 97 A1 CA 8B 1F 7A   D7 E1 30 57 EE 92 F8 9D  .......z..0W....
00A0: 34 2E D4 CD 86 4C 19 B7   B8 3D 5B 0B 28 32 28 4D  4....L...=[.(2(M
00B0: FA AA 40 38 7D 1B 19 24   67 74 CC AD 82 CA 9E A5  ..@8...$gt......
00C0: 3B A5 36 A7 D7 B0 74 AC   96 8B 49 0B E8 5F E1 EB  ;.6...t...I.._..
00D0: 97 BB A1 DF B8 A6 8C 04   C0 1B 83 02 D2 5E F7 91  .............^..
00E0: 62 01 FC F9 35 81 4A BE   0A DF EE 78 8B 6D 9D 8E  b...5.J....x.m..
00F0: F9 3D 61 3E 93 F0 19 42   A3 7A 7F F8 B5 DF 42 F1  .=a>...B.z....B.

]
***

If the server finds a valid certificate, you will receive a ‘Found trusted certificate’ message followed by the ‘Certificate chain’ message at the server side logs.

Found trusted certificate:
[
[
  Version: V3
  Subject: CN=EI Server, OU=EI, O=EI, L=EI, ST=EI, C=EI
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  Sun RSA public key, 2048 bits
  modulus: 20633040407737278567218634330232059050042226479044722496122452505410479273023117031844484746505155564073294892298093888208868315188456270185531088712664441886338425740008444649208646876917816694847967760308554699673706712637838857175549988647511729487971524875773472297556010021422655352423126217625806863759012805189832944776623955038735096318822704111503458955521102855569127337450070103240845157800531714174178998060010010408282365398717630638484524135245861883501920626423778221475087217057744850665905219857063710661918813533021515797130163876841737728794450828239304431761997536237765605147373975769055502409267
  public exponent: 65537
  Validity: [From: Sun Jul 05 23:32:01 IST 2020,
               To: Sat Oct 03 23:32:01 IST 2020]
  Issuer: CN=EI Server, OU=EI, O=EI, L=EI, ST=EI, C=EI
  SerialNumber: [    3ded1c63]

Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9C 15 A6 4E AC 34 89 2A   8D AD 4E 9A 3B 56 81 73  ...N.4.*..N.;V.s
0010: 05 A3 40 4E                                        ..@N
]
]

]
  Algorithm: [SHA256withRSA]
  Signature:
0000: 5A E1 C2 5B 71 AC 72 50   D8 DE 0E 80 10 10 A6 B4  Z..[q.rP........
0010: D6 EC 39 2E DF 24 1D 81   5E E2 39 0F C0 C2 49 CC  ..9..$..^.9...I.
0020: EE D9 5C 44 0A 07 26 23   EE 7E FC C0 32 01 7C 48  ..\D..&#....2..H
0030: 4C CB 7D 56 CB F9 42 1D   75 06 3B 92 1B 8D DE 45  L..V..B.u.;....E
0040: 4E 66 B6 5C 36 C2 07 1F   1C 7D D9 BC 09 FE F1 91  Nf.\6...........
0050: BB 6B 3D 3B F9 5F 86 FB   B1 27 33 CD D0 5C 4F 5F  .k=;._...'3..\O_
0060: 7A 9D 18 41 E3 32 BA 17   58 23 26 29 F2 A9 AE 00  z..A.2..X#&)....
0070: F7 39 64 37 89 D1 B9 D3   90 94 63 68 99 85 D7 22  .9d7......ch..."
0080: 39 E2 E8 BE BB EA 56 17   AF FC 24 14 3A 6C 23 8F  9.....V...$.:l#.
0090: E6 EC 97 A1 CA 8B 1F 7A   D7 E1 30 57 EE 92 F8 9D  .......z..0W....
00A0: 34 2E D4 CD 86 4C 19 B7   B8 3D 5B 0B 28 32 28 4D  4....L...=[.(2(M
00B0: FA AA 40 38 7D 1B 19 24   67 74 CC AD 82 CA 9E A5  ..@8...$gt......
00C0: 3B A5 36 A7 D7 B0 74 AC   96 8B 49 0B E8 5F E1 EB  ;.6...t...I.._..
00D0: 97 BB A1 DF B8 A6 8C 04   C0 1B 83 02 D2 5E F7 91  .............^..
00E0: 62 01 FC F9 35 81 4A BE   0A DF EE 78 8B 6D 9D 8E  b...5.J....x.m..
00F0: F9 3D 61 3E 93 F0 19 42   A3 7A 7F F8 B5 DF 42 F1  .=a>...B.z....B.

]
check handshake state: client_key_exchange[16]
update handshake state: client_key_exchange[16]
upcoming handshake states: certificate_verify[15](optional)
upcoming handshake states: client change_cipher_spec[-1]
upcoming handshake states: client finished[20]
upcoming handshake states: server change_cipher_spec[-1]
upcoming handshake states: server finished[20]

6. Server Hello Done

The ‘Server Hello Done’ message indicates the end of ‘Server Hello’. By this point, the server has sent over all the details required to the client and is waiting for the client's response. You will see the after the Certificate Request message.

*** ServerHelloDone

7. Client Key Exchange

At this point, the client generates a random string of bytes called ‘pre-master secret’ based on the selected key exchange method selected during the initial ‘Hello’ messages.

If RSA is used, the client generates the pre-master secret. Then the client encrypts the pre-master secret with the server's public key and transmits it to the server. Only the server has the matching private key to decrypt the message and get the pre-master secret generated by the client.

If the Diffie-Hellman is used, the required Diffie-Hellman parameters are transmitted to allow both client and server to generate the same pre-master secret.

Please be noted that the public keys are stored on digital certificates for secure transport and sharing. Hence the client receives the server's public certificate along with a Certificate Chain message.

After having the pre-master key, both sides generate the master-key, or else we can say the symmetric session key, based on it.

*** ECDHClientKeyExchange
ECDH Public value:  { 4, 155, 208, 236, 141, 18, 15, 41, 223, 46, 75, 222, 216, 4, 182, 247, 86, 18, 14, 248, 5, 121, 129, 250, 130, 84, 247, 239, 96, 115, 63, 158, 23, 130, 248, 178, 245, 86, 154, 207, 194, 82, 194, 158, 138, 4, 216, 191, 74, 185, 66, 167, 181, 231, 6, 44, 189, 8, 85, 154, 134, 217, 118, 220, 9 }
SESSION KEYGEN:
PreMaster Secret:
0000: CA 05 DD 3E 70 28 0C 66   33 52 7C CA 3C 09 80 22  ...>p(.f3R..<.."
0010: BC 09 31 C8 D4 30 0B C9   C0 0D 7E 69 0C 4E A9 BE  ..1..0.....i.N..
CONNECTION KEYGEN:
Client Nonce:
0000: 5F 02 33 15 6A 82 8F 98   99 1A 90 98 A8 FC 46 6B  _.3.j.........Fk
0010: A2 8F 62 15 BF 9D B9 3A   82 E7 A5 41 21 6E E0 5B  ..b....:...A!n.[
Server Nonce:
0000: 5F 02 33 15 CC C0 5F 2C   15 40 FD 57 0A EF 34 BE  _.3..._,.@.W..4.
0010: BE 3D BA 33 7D 10 44 8D   AA 5B E8 CD 94 80 4E B9  .=.3..D..[....N.
Master Secret:
0000: 0F 72 A0 5D A8 38 1E 2B   1C C9 09 92 15 AA CE 40  .r.].8.+.......@
0010: 22 AD DA 52 9B B9 C1 50   18 6E 0A 0E 3B C7 5D D5  "..R...P.n..;.].
0020: CE A6 6E F0 9F 07 4D 60   8D E8 6C 49 E3 DD 57 6F  ..n...M`..lI..Wo
Client MAC write Secret:
0000: 6B 3C 42 38 37 85 FE 92   CB 72 62 10 EA 78 22 33  k<B87....rb..x"3
0010: 76 D2 1D 33 A6 D3 C7 8A   83 78 F5 13 13 83 27 61  v..3.....x....'a
0020: 30 12 1D 1C E9 01 75 5D   FA 6B CE 1C 72 EE FB 9A  0.....u].k..r...
Server MAC write Secret:
0000: 85 49 6C 4D F1 9A A7 B6   C4 33 A2 6C 5D EB D0 39  .IlM.....3.l]..9
0010: 35 A7 AF 75 48 40 6E 59   F5 22 A0 37 EB B6 E9 AB  5..uH@nY.".7....
0020: A5 F5 00 29 37 82 5C 87   72 6D CD AC C8 38 D8 EF  ...)7.\.rm...8..
Client write key:
0000: 09 1D A3 90 C1 08 57 80   B5 58 16 69 F8 9E DC AB  ......W..X.i....
0010: 23 B2 47 CD 98 96 E1 27   69 64 E2 6E 68 07 EE E4  #.G....'id.nh...
Server write key:
0000: 77 76 89 F8 93 EE 40 FA   1B 8B AA 31 03 34 D1 16  wv....@....1.4..
0010: 03 33 0A F3 81 65 24 20   D7 EC 8A BE 31 7F B0 8B  .3...e$ ....1...

8. Client Change Cipher Spec

Then the client generates a ‘Change Cipher Spec’ message letting the server know that it’s going to switch to an encrypted communication based on the session key.

Thread-1 (activemq-netty-threads), READ: TLSv1.2 Change Cipher Spec, length = 1

9. Client Finished

The ‘Finished’ message is sent by the client to the server indicating that the client’s side of the handshake has been completed. The client’s ‘Finished’ message is encrypted by the shared session key and it's the first message protected by it.

*** Finished
verify_data:  { 236, 172, 15, 118, 186, 177, 150, 21, 7, 82, 236, 97 }
***

This message consists of required data that provide the guarantee for the server that the handshake hasn’t been compromised.

10. Server Change Cipher Spec

The server decrypts the received message and finds the pre-master secret sent by the client. Then it computes the session key based on the pre-master key, which will be used in the following communication.

At this point, the server generates its own ‘Change Cipher Spec’ message to indicate that it’s also switching to encrypted communication.

Thread-1 (activemq-netty-threads), WRITE: TLSv1.2 Change Cipher Spec, length = 1

11. Server Finished

At last, the server also generates a ‘Finished’ message encrypted by the session key. This marks the end of the server part of the communication as well as a successful SSL handshake.

*** Finished
verify_data:  { 183, 200, 213, 124, 127, 251, 136, 195, 116, 238, 43, 54 }
***

Once this handshake is done, the server and client now can exchange messages that are symmetrically encrypted with the shared session key.

Now you know about the general flow of SSL handshakes. But there can be some slight variations for it based on the used key exchange algorithm. There are mainly two key exchange algorithms used in TLS.

RSA key exchange
Diffie-Hellman key exchange

Let’s have a close look at both.

RSA vs Diffie-Hellman

There are some fundamental differences between Diffie-Hellman and RSA. If we put in simple words, RSA can handle both the authentication based on digital signature and the secure key exchange whereas Diffie-Hellman only handles the key exchange. Hence the RSA can be named as the more capable method from the two.

Often you will see that the Diffie-Hellman is often combined with Elliptic Curves making the Elliptic Curve Diffie-Hellman (ECDH). Including ECDH, there are four main branches of Diffie-Hellman.

Diffie-Hellman (DH)
Diffie-Hellman Ephemeral (DHE)
Elliptic Curve Diffie-Hellman (ECDH)
Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)

Since the Diffie-Hellman is lacking the authentication part, it needs to be paired with a digital signature algorithm. Nowadays you will often see few modern variants of Diffie-Hellman such as ECDH and ECDHE are paired with Elliptic Curve Digital Signature Algorithm (ECDSA) or RSA.

RSA based Authentication and Key Exchange

The authentication and key exchange processes of RSA have been entangled with each other. The key exchange is performed as a part of the RSA’s authentication process.

If the RSA is used and the client receives the server certificate, a set of actions are performed to verify the validity of it.

Validates the digital signature using the public key
Check the certificate chain and verify that the server certificate is available in the client trust store or it descends from a root certificate in the trust store.
Check the validity period of the certificate. If the certificate has been expired the handshake fails.

If the certificate passes all the verifications, the client uses the public key received with the certificate to encrypt the pre-master key and send it over to the server.

What if the client receives a different certificate which is yet to be valid than the actual server certificate.

Since it’s a valid certificate, it passes the client’s verification of the certificate signature. But how does the client know that the server owns the private key that signed the certificate?

The client sends back the pre-master key encrypted with the server’s public key. Hence, it only can be decrypted using the server’s private key. If the server can decrypt and get the correct pre-master key, it validates that the server owns the private and public key pair used in the process.

That explains how the RSA based authentication happens, which lets us move for the key-exchange.

Here is how it happens,

During the Client Hello and Server Hello, both parties exchange two prime numbers called ‘client random’ and ‘server random’ respectively.
The client generates the pre-master key, encrypts it using the server’s public key, and sends it over to the server.
The server decrypts the received pre-master key using the corresponding private key.
At this point, both parties should have client random, server random, and pre-master key.
Using the aforementioned parameters, both client and server generate matching session keys.

It seems to be a good time to know how DH acts to accomplish these tasks.

Diffie-Hellman based Authentication and Key Exchange

As we have mentioned earlier, the DH cannot perform the authentication process by itself. Hence it associates with digital signature algorithms such as ECDSA or RSA.

However, please be noted that, even though RSA uses the key pair for both authentication and key exchange, the DH uses the key pair only for the authentication.

If the DH is in use, similar actions are performed as in the RSA by the client upon receiving the server certificate.

Validate the certificate signature
Check the certificate chain
Check the validity period and other relevant details

How does the client validate the key pair?

During the Client Hello and Server Hello, both parties exchange two prime numbers called ‘client random’ and ‘server random’ respectively. As we have mentioned earlier, the Server Key Exchange step is only specific to the DH handshake. Before the Server Key Exchange, the server takes the server randomly and the client random and the server's DH specific parameters and then encrypts them using the server’s private key which will work as the digital signature. Then the client uses the corresponding public key to verify that the server owns the private and public key pair used in the process.

So how does the DH key exchange happen?

Not like in RSA, the required parameters are transmitted to both parties to generate the same pre-master secret.

Here is what happens,

Both parties exchange two prime numbers called client random (x) and server random (y) respectively during the client and server ‘Hello’ messages.
The client selects a secret number called pre-master secret (a) and applies a modulo function as xa mod y.
Similarly, the server selects its pre-master secret (b) and applies a modulo function as xb mod y.
Let’s name the client’s result as A and server’s result as B.
Both parties then exchange the value and apply another modular function. The client applies Ba mod y and the server applies Ab mod y.

If the functions and values are applied correctly, both parties should have the same value which we called the session key. As we already know, the later communication between these two parties will be encrypted using the retrieved session key.

That’s it then.

Now we know the end to end details of how communication happens between client and server. We have discussed how the one-way SSL differs from the two-way SSL and how to identify it from SSL logs. Also, we have covered how the handshake varies based on the used key exchange method.

The entire process is guaranteed to establish trust between both communicating parties. In the current era, the SSL is considered to be an essential part of secure communication. It’s fascinating to see how users put their faith in this protocol about the safety of their sensitive details that are being transferred through the internet.

Stay safe! Be secure!

DEV Community