Directory
Introduction
TLS (English: Transport Layer Security, abbreviated as TLS) transport layer security protocol, and its predecessor Secure Sockets Layer (Secure Sockets Layer, abbreviated as SSL) is a security protocol, the purpose is to provide security and data integrity for Internet communications Assure.
When Netscape launched the first version of the web browser, Netscape Navigator, in 1994, it launched the HTTPS protocol, encrypted with SSL, which is the origin of SSL. The IETF standardizes SSL and published the first version of the TLS standard document in 1999. This was followed by RFC 5246 (August 2008) and RFC 6176 (March 2011). This protocol is widely supported in applications such as browsers, mailboxes, instant messaging, VoIP, and Internet fax. Major websites, such as Google and Facebook, also use this protocol to create secure connections and send data. It has become the industry standard for secure communication on the Internet.
Development History
| protocol |
years |
| SSL 1.0 |
unknown |
| SSL 2.0 |
1995 |
| SSL 3.0 |
1996 |
| TLS 1.0 |
1999 |
| TLS 1.1 |
2006 |
| TLS 1.2 |
2008 |
| TLS 1.3 |
2018 |
TLS Record Protocol
The Transport Layer Security (TLS) record protocol protects application data using keys created during the handshake. The protocol of record is responsible for securing application data and verifying its integrity and provenance. It manages the following:
- Divide outgoing messages into manageable chunks and reassemble incoming messages.
- Compress outgoing blocks and decompress incoming blocks (optional)
- Applies a Message Authentication Code (MAC) to outgoing messages and uses the MAC to authenticate incoming messages.
- Encrypt outgoing messages and decrypt incoming messages.
After the record protocol is complete, outgoing encrypted data is passed down to the Transmission Control Protocol (TCP) layer for transmission.
The TLS record protocol is a simple encapsulation of the TLS high-level protocol, and the data format is as follows:
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;- Content type: 1 byte, which records the type 1 of the inner layer protocol (higher layer protocol) :
0:illegal field20:Key Exchange Protocol (change_cipher_spec)21:Alarm protocol (alert)22:Handshake protocol (handshake)23::Application layer data (application_data)
- Major version: 1 byte, typically
0x03, for SSL 3 - Minor version: 1 byte, depending on the version, it may be
0x01,0x02,0x03, which represent TLS 1.1, TLS 1.2, and TLS 1.3 respectively (from here it also reflects the inheritance of TLS and SSL) - Data length: 2 bytes
- Message verification code: It is mentioned in many places that there is a message verification code field in the record layer protocol, which occupies 0, 16, and 20 bits in length
TLS handshake protocol
The handshake phase is implemented using the TLS handshake protocol. The format of the handshake protocol is as follows
- Handshake Type: 1 byte
1: client hello (client_hello)2: Server hello (server_hello)4: new session (new_session_ticket)5: end of early data (end_of_early_data)8: Encrypted extensions (encrypted_extensions)11: certificate13: certificate request (certificate_request)15: certificate verification (certificate_verify)20: Handshake finished (finished)24: key update (key_update)254: message hash (message_hash)
- Length: 3 bytes
- content
According to different sub-protocols, its format will be different
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* remaining bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;The process of the whole handshake phase is as follows:
Client Hello
The request must be initiated from the client, so the first step must be the Hello message sent by the client.
Client Hello is a kind of TLS record protocol, so its outer layer must be
In this step, the client needs to tell the server its own version, supported components and other information
After the original handshake protocol, Client Hello has the following parts:
- version: 2 bytes, contains major and minor version
- Random number: 32 bytes, including 4 bytes timestamp
- Session Length: 1 byte
- session id
- Number of cipher suites: 2 bytes
- List of cipher suites: 2 bytes per suite
- Number of compression methods: 1 byte
- List of compression methods: 1 byte per method
- Number of plugins: 2 bytes
- Plugin list:
- Plug-in type: 2 bytes
- Length: 2 bytes
- content
If the connection is established for the first time, the session ID here is empty. And if a connection has been established within a certain period of time, the two ends will cache the corresponding information and reuse the previous parameters. This form that does not require all handshakes is called SSL session recovery .
Server Hello
When the server receives the client's greeting, it needs to return its own greeting. From the list of parameters supported by the client, the server needs to choose the safest one. If a certain parameter list is not supported by the server, and the server cannot support it, it needs to return a handshake failure.
Discussing the aforementioned SSL session recovery again , there is a problem here: for servers with high traffic, they need to maintain a very large session list. Since this part is a limitation of the protocol layer, it is difficult to optimize.
In order to solve this problem, you can use Session Ticket to store relevant data on the client. Since the content is encrypted by the server, there will be no data leakage.
At this point, the two ends of the communication have determined which cipher suites need to be used later, and the relevant pre-parameters (two random numbers)
Certificate
The SSL/TLS system server needs an X.509 certificate to verify its identity
Generally speaking, the root certificate of the certificate chain should be the root certificate recognized by everyone. The root certificate generally does not directly issue certificates for communication, but issues some secondary certificates for issuing communication certificates. During the communication process, the certificate chain except the root certificate should be sent together with the request for peer verification.
At this point, the client can think that the server is the server it really wants to request, not faked by other third parties (identity confirmation needs to use the domain name, ip and other information in the certificate)
Server Key Exchange
In the previous greeting step, the various algorithms used have been determined. Here, the corresponding methods (RSA, DH) and two random numbers are used for key exchange.
If DH key exchange is used, there is a fixed base 3 for each specific calculation method, such as for common secp256r1, uncompressed G is:
04
6B17D1F2 E12C4247 F8BCE6E5 63A440F2
77037D81 2DEB33A0 F4A13945 D898C296
4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
2BCE3357 6B315ECE CBB64068 37BF51F5And the compressed G is:
03
6B17D1F2 E12C4247 F8BCE6E5 63A440F2
77037D81 2DEB33A0 F4A13945 D898C296The server calculates the public key and private key according to the set base, and sends the selected curve (or other parameters) and the public key to the client.
client certificate request
If the server still needs to verify the identity of the client, the subsequent server needs to send a "Certificate Request" to request a certificate
Tell the client the type of certificate it supports, and the list of supported root certificates
End of server greeting
At this point, the server greeting is over
client certificate
If a client certificate needs to be sent, the client needs to follow the same steps as the server to send the certificate, and the server will verify it
Client Key Exchange
Same as the server, the client uses the same parameters to calculate its own public key and private key, and sends the public key to the other party
key exchange protocol
When the key negotiation between the two parties is completed, the client needs to send a key agreement agreement, declaring that it has switched to the negotiated cipher suite, and then use the new cipher suite for encrypted transmission
client end
Before the end of the handshake phase, the client needs to send a Client Finished notification (encrypted using the negotiated cipher suite)
end of server
In response to the end of the client response, the server needs to send the end of the server (it also needs to send a key agreement agreement to inform the client to switch the cipher suite)
key exchange protocol
The key exchange protocol is used to inform the peer that it is ready to switch to a new protocol, which has only one byte. But because it is actually redundant data, it has been removed in TLS 1.3
Alarm protocol
The alarm protocol is a notification protocol that tells the other party that an error has occurred and will no longer receive data
enum { warning(1), fatal(2), (255) } AlertLevel;
struct {
AlertLevel level;
AlertDescription description;
} Alert;application protocol
The actual data to be sent is encrypted and sent in the application protocol
The original application layer protocol will segment, calculate MAC, encrypt and transmit
X.509 certificate
Typically, certificates are stored in the format, and the contents of the certificate .cer can be viewed with openssl
openssl x509 -in F2giRo29iMlijZg5U.cer -inform der -text -noout
A certificate contains the following key information
- issuer
- user
- Issue time
- Expiration
- serial number
- signature algorithm
- Encryption Algorithm
To verify a certificate, do the following recursively:
- Check if the certificate has expired?
- If the certificate has not expired, check whether the issuer is in the trusted certificate list
- If the issuer is in the trusted certificate list, use the corresponding certificate public key to verify the validity of the certificate; if it is not in the trusted list, you need to check the previous certificate of the certificate chain from 1 (sent by the server)
- Check whether the serial number of the certificate is in the expiration list
key exchange
RSA key
Since the public and private keys themselves can ensure security, after the client selects a symmetric key cipher, it can use the public key in the certificate to encrypt the symmetric cipher, and after sending it to the server, the server uses its own private key to decrypt it
On the premise that the RSA system itself is secure, this scheme can ensure security
Diffie-Hellman key exchange
If there is no need to consider authentication, Diffie-Hellman can be used to exchange keys in an insecure channel
Both communication parties exchange a public base GG, prime number pp, and then both parties set a random number aa and bb respectively. Both
parties exchange their own public information A = (g^{a} \mod p)A=(gamodp) and B = ( g^{b } \mod p)B=(gbmodp)
In this way, both parties can use each other's data to calculate an identical symmetric key s = B^a \mod p = A^b \mod ps=Bamodp=Abmodp
Since pp is a large prime number, and solving discrete logarithms is very complicated, even if it is observed by a third party, it can still be safe
However, the Diffie-Hellman system itself cannot ensure authentication, so it usually requires the cooperation of RSA
In order to further increase the difficulty of calculation, there is also Diffie-Hellman based on elliptic curves, referred to as EC-DH