protocol-ssl

Posted on 2021-04-16 Edited on 2023-08-16 In protocol , ssl

TLS, RSA, AES

Overview

Handshake

SSL/TLS handshake is different between TLS1.2 and TLS1.3, but they have common concept.

The purpose of the SSL/TLS handshake is to perform all the cryptographic work needed to have a secure connection. This includes authenticating the SSL certificate being used, and generating an encryption key.

The TLS handshake accomplishes 3 main things:

Exchanging cipher suites and parameters
Authenticating one or both parties
Creating/Exchanging symmetric session keys

Negotiating Cipher Suites
The first step of the TLS handshake requires the client and server to share their capabilities so they can find the cryptographic features they mutually support.

Once a client and server agree on the exact encryption methods they will use, this is called a cipher suite – the server sends the client its SSL certificate

Authentication SSL certificate
Upon its receipt, the client checks to make sure the certificate is “authentic.” This is an extremely important step. To truly have a secure connection, you can’t just encrypt your data, you also need to know it’s being sent to the right website/organization. SSL/TLS certificates provide that authentication.

During the authentication portion of the TLS handshake, the client performs several cryptographically secure checks to make sure the certificate provided by the server is authentic. This includes checking the digital signature and making sure the certificate originates from a trusted CA.

With the most common public key cryptosystem, RSA, the client will encrypt random data(pre-master-key) with the public key that needs to be used to generate the session key. The server will only be able to decrypt and use that data if it has the private key, which provides proof of possession.

Key Exchange
The last part of the TLS handshake involves creating the “session key,” which is the key that will actually be used for secure communication, both client and server compute the session key by them self based on (client random number, server random number, pre-master key)

Session keys are “symmetric,” meaning the same key is used for encryption and decryption. These keys can achieve strong encryption much more efficiently than asymmetric keys, making them appropriate for sending data back and forth in an HTTPS connection。

The exact method for generating the key varies based on the cipher suite that was chosen, with the two most common schemes being RSA and Diffie-Hellman.

To end the handshake, each party lets the other know they have done all the necessary work, then both run check-sums to make sure the handshake occurred without any malicious tampering or corruption.

TLS 1.2 Handshake

Please note this is just the logical process, several steps combine together and may send in one TCP packet.

TLS 1.2 handshake

The first message is called the “ClientHello.” This message lists the client’s capabilities so that the server can pick the cipher suite that the two will use to communicate. It also includes a large, randomly picked prime number called a “client random.”
The server politely responds with a “SeverHello” message. In this message it tells the client what connection parameters it has selected from the provided list and returns its own randomly selected prime number called a “server random.” If the client and server do not share any capabilities in common, the connection terminates unsuccessfully.
In the “Certificate” message, the Server sends its SSL certificate chain (which includes its leaf certificate and intermediate certificates) to the client. To provide authentication to the connection an SSL certificate is signed by a CA, which allows the client to verify that the certificate is legitimate. Upon receipt, the client performs several checks to authenticate the certificate. This includes checking the certificate’s digital signature, verifying the certificate chain, and checking for any other potential problems with the certificate data (expired certificate, wrong domain name, etc). The client will also make sure the server has possession of the certificate’s private key. This is done during the key exchange/generation process.
(OPTIONAL)[Server Key Exchange]This is an optional message, only needed for certain key exchange methods (Diffie-Hellman) that require the server provides additional data.
The “Server Hello Done” message tells the client that it has sent over all its messages.
[Client Key Exchange] The client then provides its contribution to the session key. The specifics of this step depend on the key exchange method that was decided on in the initial “Hello” messages. In this example we’re looking at RSA, so the client is going to generate a random string of bytes called a pre-master secret, then encrypt it with the server’s public key and transmit it.
The “Change Cipher Spec” message lets the other party know that it has generated the session key and is going to switch to encrypted communication.
The “Finished” message is then sent to indicate that the handshake is complete on the client side. The Finished message is encrypted, and is the first data protected by the session key. The message contains data (MAC) that allows each party to make sure the handshake was not tampered with.
Now it’s the server’s turn to do the same. It decrypts the pre-master secret and computes the session key. Then it sends its “Change Cipher Spec” message to indicate it is switching to encrypted communication.
The server sends its “Finished” message using the symmetric session key it just generated, it also performs the same check-sum to verify the integrity of the handshake.

After these steps the SSL handshake is complete. Both parties now have a session key and will begin to communicate with an encrypted and authenticated connection.
2, 3, 4, 5 may in one TCP message, 6.7.8 may in one TCP message, 9, 10 may in one TCP message.

Another way to see SSL handshake

TLS1.2 handshake

TLS 1.3 Handshake

Cipher Suite

A cipher suite is a collection of algorithms that determine the parameters of a secure connection.

At the start of any connection, the very first interaction, the Client Hello, is a list of cipher suites that are supported. The server looks for the best, most secure option that is mutually supported and responds with its choice. You can look at a cipher suite and figure out all of the parameters of the handshake and the connection

TLS1.2

four distinct algorithms represented in TLS 1.2 cipher suites:

Key Exchange(how to generate pre-master key)
Authentication(how to valid certificate)
Bulk Cipher(data encryption)
Hashing Algorithm(data integrity check)

Example Format
TLS1.2 Cipher

TLS is the protocol
ECDHE is the key exchange algorithm
ECDSA is the authentication algorithm
AES 128 GCM is the symmetric encryption algorithm
SHA256 is the hashing algorithm.

In the example above, we’re using Elliptic Curve Diffie-Hellman Ephemeral(ECDHE) for key exchange and Elliptic Curve Digital Signature Algorithm(ECDSA) for authentication. DH can also be paired with RSA (functioning as a digital signature algorithm) to accomplish authentication.

TLS 1.2 has 37 available ciphers in total, though not all of them are advisable. Here’s a list of the most widely-supported cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

TLS 1.3

TLS 1.3 has made countless improvements over its predecessors, which is good considering it was in development for about a decade. The IETF removed support for older outmoded algorithms and streamlined everything, shortening the entire handshake from two round trips to one and reducing the sizes of cipher suites from four negotiations/algorithms to two.

The number of supported cipher suites has also dropped from 37 to five. Here’s an example of a TLS 1.3 cipher suite:
TLS1.3 Cipher Suite

TLS is the protocol
AES 256 GCM is the Authenticated Encryption with Associated Data (AEAD) algorithm
SHA384 is the Hashed-Key Derivation Function (HKFD) algorithm

We(TLS 1.3) already know we’re going be using some version of Diffie-Hellman Ephemeral key exchange, we just don’t know the parameters, so that means that the first two algorithms in the TLS 1.2 cipher suite are no longer needed. Those functions are still occurring, they just no longer need to be negotiated during the handshake.

Here are the five supported TLS 1.3 cipher suites:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

SNI

why need SNI

Let’s begin from an example, Let’s say you have two HTTP websites and you want to run them on a single IP address and port, how to config nginx to support this.

http {
    server {
        listen  80;
        server_name www.example.com;
        ...
    }

    server {
        listen  80;
        server_name www.example.org;
        ...
    }
}
# Both server has the same IP and port!!!
# The default_server parameter, if present, will cause the server to become the default server for the specified address:port pair. 
# If none of the directives have the default_server parameter 
# then the first server with the address:port pair will be the default server for this pair

when a user requests a particular site out of two, it uses a unique HTTP header(‘HOST’) that includes hostname.
nginx will use this header to match the request server, hence use that server to serve the request.

but this won’t work in the case of HTTPS, that’s because the HTTPS protocol uses an SSL/TLS handshake to enforce secure communications between the client (browser) and server. The HTTP header will only be sent once the handshake is over. during the handshake, we need to send server’s certificate to client, which server’s certificate should be sent is a problem because we do not have HOST header right now, before SNI, we must listen on different IPs to support different website, so that one IP<—–>one certificate, after SNI was introduced, no need to use different addresses.

what’s SNI

http {
    server {
        listen 443 ssl;
        server_name www.example.com;
        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;
        ...
    }

    server {
        listen 443 ssl;
        server_name www.example.org;
        ssl_certificate     www.example.org.crt;
        ssl_certificate_key www.example.org.key;
        ...
    }
}

as Server Name Indication (SNI), an extension to the SSL/TLS protocol, allows multiple SSL certificates to be hosted on a single unique IP address. SNI does this by inserting the HTTP header (virtual domain) in the SSL/TLS handshake. As the server is able to see the virtual domain at ssl handshake phase, hence send correct certificate and serves the client with the website he/she requested.

SSL certificate

Certificate is used for identification, like you’re a good man, I trust you, Or it’s good company, I can send my personal info to it!!

How to identify the certificate to know you’re good man?
As certificate is issued by CA encrypted with its private key(popular CA’s public key is always installed at PC), if we can decrypt the certificate and valid the field in it, Ok, you’re good man!!!

certificate contains company’s info and its public key! and encrypted with CA’s private key!!!

certificate

Actually, certificate contains two parts, one is CSR(public key+ basic info), the other is signature(CA signed use CA private key), then encode these two with BASE64. that means you can get the basic info and public key,without verify it, but you can’t trust them until you verify it(use CA public key)

Everyone should have a certificate if he/she needs to be identified by others. First he/she gives his/her certificate(like an ID) to the one she/he wants to talk, then the one ASKs CA(certificate authority ), if this guy is a good man(good company), did he register at CA? CA checks his db, ok, he is good man(good company), you can talk with he/her, or trust he/her. but be sure talk with encryption, so that others can NOT know what you’re saying!

Before SSL, what client/server needs to do?
client/server need to get their certificates and install CA, for two direction identification!

Install CA
Always the computer(OS) pre installed commonly used CA, organized like a tree(CA tree)
1
2
3
4
root(CA)
| |
| |
CA1 CA2
Note: each CA entry contains CA’s public key! key point!!
(certificate is encrypted by CA’s private key)
Get certificate
server(client) generates its own public/private keys, then send a CSR(certificate signing request) which contains its public key/company name, website etc to CA, CA encrypts these info with CA’s private key to issue a certificate! now server(client) has its certificate(encrypted with CA’s private key) which contains his public key, company info and signature.

Certificate format

X.509 - 这是一种证书标准,主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准.

目前有以下两种编码格式(实现方式).(PEM, DER编码格式)

PEM

Privacy Enhanced Mail,打开看文本格式,以”—–BEGIN…”开头, “—–END…”结尾,内容是BASE64编码.

查看PEM格式证书的信息:$ openssl x509 -in certificate.pem -text -noout
Apache和NGINX服务器偏向于使用这种编码格式.

PEM – Openssl使用 PEM(Privacy Enhanced Mail)格式来存放各种信息, 它是 **openssl 默认采用的信息存放方式**。
Openssl 中的 PEM 文件一般包含如下信息:

内容类型:表明本文件存放的是什么信息内容,它的形式为“——-BEGIN XXXX ——”,与结尾的“——END XXXX——”对应。
头信息:表明数据是如果被处理后存放,openssl 中用的最多的是加密信息,比如加密算法以及初始化向量 iv。
信息体:为 BASE64 编码的数据。可以包括所有私钥（RSA 和 DSA）、公钥（RSA 和 DSA）和 (x509) 证书。
它存储用 Base64 编码的 DER 格式数据，用 ascii 报头包围，因此适合系统之间的文本模式传输。

使用PEM格式存储的证书：

—–BEGIN CERTIFICATE—–
MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCVVMx
………
1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=
—–END CERTIFICATE—–

使用PEM格式存储的私钥：

—–BEGIN RSA PRIVATE KEY—–
MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCVVMx
………
1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=
—–END RSA PRIVATE KEY—–

使用PEM格式存储的证书请求文件：

—–BEGIN CERTIFICATE REQUEST—–
MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCVVMx
………
1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=
—–END CERTIFICATE REQUEST—–

Here is a certificate(encode with base64)

After decode with base64

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha512WithRSAEncryption
        Issuer: C=us, ST=bj, O=ww, CN=www.as.com
        Validity
            Not Before: Oct 28 15:05:14 2019 GMT
            Not After : Oct 27 15:05:14 2020 GMT
        Subject: C=us, ST=bj, O=ww, CN=www.as.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:d4:fe:ea:0d:7c:6d:7b:39:5d:a0:8b:f9:21:de:
                    e9:ca:51:34:93:72:4c:a9:46:b5:9f:0d:c7:2e:12:
                    13:65:f3:ac:da:4b:7f:86:fa:1e:79:57:2c:39:93:
                    2c:81:7b:47:35:31:d9:08:9a:c0:e8:a8:a5:9c:25:
                    29:25:43:37:aa:12:a3:98:b2:df:44:4f:50:c1:a8:
                    44:6d:df:73:a0:2c:6f:0c:d8:41:ce:d7:31:f1:41:
                    59:2a:d5:f7:a0:eb:58:06:59:96:d9:01:eb:ce:6f:
                    66:1d:f4:5d:b9:81:52:89:1b:0b:c8:c3:b3:79:4f:
                    7c:04:a7:cc:c1:5f:99:75:93
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                5C:F0:30:D1:3D:E5:34:F0:02:27:DD:F2:4D:BF:FD:BC:8A:43:3C:9C
            X509v3 Authority Key Identifier: 
                keyid:5C:F0:30:D1:3D:E5:34:F0:02:27:DD:F2:4D:BF:FD:BC:8A:43:3C:9C

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha512WithRSAEncryption
         0b:1b:cb:ca:96:ce:e2:db:a0:c6:97:20:97:a3:45:b1:8c:7d:
         a4:6c:29:e1:e3:2d:7b:23:d5:6b:5a:6d:16:e4:72:b5:5a:d3:
         c9:5f:c0:3f:7f:7b:9d:ac:d0:f4:cb:26:ee:f1:71:96:61:e3:
         42:85:72:67:6f:5a:e3:d4:13:37:fb:85:02:45:7e:3a:46:6e:
         d1:0a:a3:63:ff:c8:d2:dd:2e:5b:69:43:ff:e8:dd:44:ff:8c:
         2e:dd:9a:56:06:b7:a8:fb:92:f4:36:b1:37:46:f9:d8:33:a8:
         25:32:c2:9a:32:5f:02:97:6b:a9:da:8b:0b:e4:22:39:fc:6b:
         8f:e4

As you can see that it contains basic info and public key and signature(signed with CA private key)

Certificate revocation list(CRL)
In cryptography, a certificate revocation list (or CRL) is “a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted.

Expiration dates are not a substitute for a CRL. While all expired certificates are considered invalid, not all unexpired certificates should be valid

Common Name(CN) vs Subject Alternative Name(SAN)
CN vs SAN

DER – 辨别编码规则 (DER) 可包含所有私钥、公钥和证书**

它是大多数浏览器的缺省格式，并按 ASN1 DER 格式存储。它是无报头的－ PEM 是用文本报头包围的 DER。

DER - Distinguished Encoding Rules,打开看是二进制格式,不可读.
查看DER格式证书的信息:$ openssl x509 -in certificate.der -inform der -text -noout
Java和Windows服务器偏向于使用这种编码格式.

证书编码的转换

PEM转为DER $ openssl x509 -in cert.crt -outform der -out cert.der

DER转为PEM $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

(提示:要转换KEY文件也类似,只不过把x509换成rsa,要转CSR的话,把x509换成req…)

Openssl command

# check certificate with .pem format
$ openssl x509 -text -noout -in cert.pem

# create self-signed certificate with openssl
# no extension
$ cat san.cnf
[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
prompt = no
[ req_distinguished_name ]
countryName                 = CN
stateOrProvinceName         = bj
localityName               = bj
organizationName           = cyun 
commonName                 = cyun.com

$ openssl req -config san.cnf -new -x509 -sha256 \
   -newkey rsa:2048 -nodes -keyout private.key -days 365 -out cert.pem

# with extension
$ cat san.cnf
[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt = no
[ req_distinguished_name ]
countryName                 = CN
stateOrProvinceName         = bj
localityName               = bj
organizationName           = cyun 
commonName                 = cyun.com
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = bestflare.com
DNS.2   = usefulread.com
DNS.3   = chandank.com

$ openssl req -config san.cnf -new -x509 -sha256 \
  -newkey rsa:2048 -nodes -keyout private.key -days 365 \
  -out cert.pem -extensions req_ext

REF

SSL handshake