The TLS handshake is a process that allows two parties, typically a client and a server, to establish a secure communication channel. It is a critical part of many internet protocols, including HTTPS, which is used to secure web traffic.
The TLS handshake works by exchanging a series of messages between the client and the server. These messages contain information such as the supported TLS versions, the cipher suites, and the digital certificates of the two parties.
The following is a simplified overview of the TLS handshake:
- The client sends a ClientHello message to the server. This message contains the client's supported TLS versions, cipher suites, and digital certificate.
- The server selects a TLS version and cipher suite from the list provided by the client. The server then sends a ServerHello message to the client containing the selected TLS version, cipher suite, and digital certificate.
- The client verifies the server's digital certificate. If the certificate is valid, the client sends a CertificateVerify message to the server.
- The server generates a pre-master secret and encrypts it with the client's public key. The server then sends the encrypted pre-master secret to the client in a PreMasterSecret message.
- The client decrypts the pre-master secret using its private key. The client and server then use the pre-master secret to generate a master secret.
- The client and server use the master secret to generate session keys. The session keys are used to encrypt and decrypt the data that is transmitted during the communication session.
Once the TLS handshake is complete, the client and server can begin communicating securely.
The TLS handshake is a complex process, but it is essential for establishing secure communication channels on the internet. Without the TLS handshake, our online data would be vulnerable to interception and tampering.
- explain how tls handshake works
The Transport Layer Security (TLS) handshake is a crucial part of securing network communication, commonly used to establish secure connections for protocols like HTTPS. The TLS handshake ensures encryption, data integrity, and authentication between a client (typically a web browser) and a server (a web server). Here's how the TLS handshake works:
Client Hello:
- The TLS handshake begins with the client (e.g., a web browser) sending a "ClientHello" message to the server.
- This message includes the client's supported cryptographic algorithms and a random value (ClientHello.random).
Server Hello:
- The server receives the ClientHello message and responds with a "ServerHello" message.
- The ServerHello message includes the server's selected cryptographic algorithms, a random value (ServerHello.random), and the digital certificate of the server.
Server Certificate:
- The server sends its digital certificate to the client. This certificate contains the server's public key and is typically signed by a trusted Certificate Authority (CA).
- The client checks the certificate's authenticity and may perform a series of checks to ensure the certificate is valid.
Key Exchange:
- After verifying the certificate, the client generates a "pre-master secret," encrypts it with the server's public key from the certificate, and sends it to the server.
- Both the client and server independently generate the same "master secret" using the pre-master secret, which will be used to derive session keys for encryption and decryption.
Client Finished:
- The client sends a "ClientFinished" message that is encrypted using the session keys. This message indicates that the client part of the handshake is complete.
Server Finished:
- The server also sends a "ServerFinished" message, encrypted with the session keys, to signal the end of the handshake process.
Secure Data Exchange:
- At this point, both the client and server have established secure session keys based on the master secret.
- All data exchanged between the client and server is encrypted and decrypted using these session keys, ensuring the confidentiality and integrity of the communication.
Session Resumption (Optional):
- For efficiency, TLS supports session resumption. If the client and server agree, they can reuse previously established session keys for subsequent connections without repeating the entire handshake process.
In summary, the TLS handshake is a series of steps that establish secure communication between a client and server. It includes negotiation of cryptographic algorithms, exchange of digital certificates, key exchange, and ultimately enables encrypted and authenticated data exchange. This process ensures the security and privacy of data transmitted over the network.
- Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over the Internet.
They use X.509 certificates and hence asymmetric cryptography to authenticate the counterpart with whom they are communicating, and to exchange a symmetric key.
This session key is then used to encrypt data flowing between the parties.
As a consequence of choosing X.509 certificates, certificate authorities and a public key infrastructure are necessary to verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity of certificates
Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection.
There are two main ways of achieving this.
One option is to use a different port number for TLS connections (for example port 443 for HTTPS).
The other is for the client to request that the server switch the connection to TLS using a protocol-specific mechanism (for example STARTTLS for mail and news protocols).
Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure.
1) The client sends to the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
2) The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.
3) The client uses the information sent by the server to authenticate the server
e.g., in the case of a web browser connecting to a web server, the browser checks whether the received certificate's subject name actually matches the name of the server being contacted, whether the issuer of the certificate is a trusted certificate authority, whether the certificate has expired, and, ideally, whether the certificate has been revoked.
If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.
If the server can be successfully authenticated, the client proceeds to the next step
4) Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
(an optional step in the handshake) - client authentication
5) If the server has requested client authentication , the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
(an optional step in the handshake) - client authentication
6) If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
7) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
8) The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished
9) The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
https://community.fortinet.com/t5/FortiGate/Technical-Note-Differences-between-SSL-Certificate-Inspection/ta-p/192301
SSL Certificate Inspection
When using SSL Certificate Inspection, the SSL Handshake is not interrupted, but the FortiGate reads the CN part of the certificate. This CN part, has the URL for the certificate was signed to
the FortiGate has an URL to check into its categories database
But the TLS/SSL content is not read in any way
Once the SSL/TLS session is established, there's no way to read its content.
Full SSL Inspection
When using this kind of inspection, the FortiGate unit takes place of the server (from the point of view of the client) and for the server, the client is the FortiGate, not the PC.
In this schema, is clear that the SSL/TLS handshake is interrupted, and the FortiGate is required to present a certificate for the URL requested by the real client.
This certificate is signed by the FortiGate itself.
As the FortiGate is usually not a recognized Certificate Authority (CA) to sign certificates a warning message will be shown to the client stating that the signer of the certificate is not a recognized entity.
When using this inspection, the traffic flows from server to the FortiGate encrypted, and from the FortiGate to the client is also encrypted. The only part where the traffic is unencrypted is into the FortiGate for inspection purposes.
This is the purpose for Full SSL Inspection, to inspect the downloaded content.
While SSL Certificate Inspection inspects only the URL (which suites perfect for web filtering only), is not designed to identify attacks, viruses or applications.
This features are available on Full SSL Inspection.
But it is needed to be clear that the Full SSL Inspection the certificate used to sign those sites (by default SSL_Proxy_Inspection into the FortiGate) is needed to be recognized as a valid CA. Otherwise, the warning message will be shown everytime an SSL/TLS connection is made.
This certificate (SSL_Proxy_Inspection) must be installed in each PC to be used by their Operating System and/or for browsers/applications (Mozilla Firefox or Java JRE) which has its own Certificate repository.
If webfilter only is required, SSL Certificate Inspection is the correct option.
If webfilter, identify attacks, viruses and application control are required, then Full SSL Inspection is the best option.
https://community.fortinet.com/t5/FortiGate/Technical-Note-Differences-between-SSL-Certificate-Inspection/ta-p/192301
- What happens in a TLS handshake?
TLS is an encryption protocol designed to secure Internet communications. A TLS handshake is the process that kicks off a communication session that uses TLS encryption. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the encryption algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works.
TLS vs. SSL handshakes
SSL was replaced by TLS, or Transport Layer Security
SSL handshakes are now called TLS handshakes
When does a TLS handshake occur?
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 handshakes occur after a TCP connection has been opened via a TCP handshake.
What happens during a TLS handshake?
During the course of a TLS handshake, the client and server together will do the following:
Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
Decide on which cipher suites they will use
Authenticate the identity of the server via the server’s public key and the SSL certificate authority’s digital signature
Generate session keys in order to use symmetric encryption after the handshake is complete
What are the steps of a TLS handshake?
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 is used most often
RSA handshake proceeds as follows:
The 'client hello' message: The client initiates the handshake by sending a "hello" message to the server. The message will include which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the "client random."
The 'server hello' message: In reply to the client hello message, the server sends a message containing the server's SSL certificate, the server's chosen cipher suite, and the "server random," another random string of bytes that's generated by the server.
Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
The premaster secret: The client sends one more random string of bytes, the "premaster secret." The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server. (The client gets the public key from the server's SSL certificate.)
Private key used: The server decrypts the premaster secret.
Session keys created: Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results.
Client is ready: The client sends a "finished" message that is encrypted with a session key
Server is ready: The server sends a "finished" message encrypted with a session key.
Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.
All TLS handshakes make use of asymmetric encryption (the public and private key), but not all will use the private key in the process of generating session keys.
an ephemeral Diffie-Hellman handshake proceeds as follows:
Client hello: The client sends a client hello message with the protocol version, the client random, and a list of cipher suites.
Server hello: The server replies with its SSL certificate, its selected cipher suite, and the server random.
Server's digital signature: The server uses its private key to encrypt the client random, the server random, and its DH parameter*. This encrypted data functions as the server's digital signature, establishing that the server has the private key that matches with the public key from the SSL certificate.
Digital signature confirmed: The client decrypts the server's digital signature with the public key, verifying that the server controls the private key and is who it says it is. Client DH parameter: The client sends its DH parameter to the server.
Client and server calculate the premaster secret: Instead of the client generating the premaster secret and sending it to the server, as in an RSA handshake, the client and server use the DH parameters they exchanged to calculate a matching premaster secret separately.
Session keys created: Now, the client and server calculate session keys from the premaster secret, client random, and server random, just like in an RSA handshake
Client is ready:
Server is ready
Secure symmetric encryption achieved
DH parameter: DH stands for Diffie-Hellman. The Diffie-Hellman algorithm uses exponential calculations to arrive at the same premaster secret. The server and client each provide a parameter for the calculation, and when combined they result in a different calculation on each side, with results that are equal.
https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake
When the SSL protocol was standardized by the IETF, it was renamed to Transport Layer Security (TLS). Many use the TLS and SSL names interchangeably, but technically, they are different, since each describes a different version of the protocol.
Let’s Encrypt
A common objection and roadblock towards widespread adoption of HTTPS has been the requirement to purchase certificates from one of the trusted authorities—see Chain of Trust and Certificate Authorities. The Let’s Encrypt project launched in 2015 solves this particular problem:
"Let’s Encrypt is a free, automated, and open certificate authority brought to you by the Internet Security Research Group (ISRG). The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention."
Visit the project website to learn how to set it up on your own site. There are no restrictions, now anyone can obtain a trusted certificate for their site, free of charge.
TLS Handshake
Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated: the client and the server must agree on the version of the TLS protocol, choose the ciphersuite, and verify certificates if necessary. Unfortunately, each of these steps requires new packet roundtrips (Figure 4-2) between the client and the server, which adds startup latency to all TLS connections.
RSA, Diffie-Hellman and Forward Secrecy
Due to a variety of historical and commercial reasons the RSA handshake has been the dominant key exchange mechanism in most TLS deployments: the client generates a symmetric key, encrypts it with the server’s public key, and sends it to the server to use as the symmetric key for the established session. In turn, the server uses its private key to decrypt the sent symmetric key and the key-exchange is complete. From this point forward the client and server use the negotiated symmetric key to encrypt their session.
The RSA handshake works, but has a critical weakness: the same public-private key pair is used both to authenticate the server and to encrypt the symmetric session key sent to the server. As a result, if an attacker gains access to the server’s private key and listens in on the exchange, then they can decrypt the the entire session. Worse, even if an attacker does not currently have access to the private key, they can still record the encrypted session and decrypt it at a later time once they obtain the private key.
By contrast, the Diffie-Hellman key exchange allows the client and server to negotiate a shared secret without explicitly communicating it in the handshake: the server’s private key is used to sign and verify the handshake, but the established symmetric key never leaves the client or server and cannot be intercepted by a passive attacker even if they have access to the private key.
Best of all, Diffie-Hellman key exchange can be used to reduce the risk of compromise of past communication sessions: we can generate a new "ephemeral" symmetric key as part of each and every key exchange and discard the previous keys. As a result, because the ephemeral keys are never communicated and are actively renegotiated for each the new session, the worst-case scenario is that an attacker could compromise the client or server and access the session keys of the current and future sessions. However, knowing the private key, or the current ephemeral key, does not help the attacker decrypt any of the previous sessions!
Combined, the use of Diffie-Hellman key exchange and ephemeral sessions keys enables "perfect forward secrecy" (PFS): the compromise of long-term keys (e.g. server’s private key) does not compromise past session keys and does not allow the attacker to decrypt previously recorded sessions
Performance of Public vs. Symmetric Key Cryptography
Public-key cryptography is used only during initial setup of the TLS tunnel: the certificates are authenticated and the key exchange algorithm is executed.
Symmetric key cryptography, which uses the established symmetric key is then used for all further communication between the client and the server within the session. This is done, in large part, to improve performance—public key cryptography is much more computationally expensive. To illustrate the difference, if you have OpenSSL installed on your computer, you can run the following tests:
$> openssl speed ecdh
$> openssl speed aes
Note that the units between the two tests are not directly comparable: the Elliptic Curve Diffie-Hellman (ECDH) test provides a summary table of operations per second for different key sizes, while AES performance is measured in bytes per second. Nonetheless, it should be easy to see that the ECDH operations are much more computationally expensive.
The exact performance numbers vary significantly based on used hardware, number of cores, TLS version, server configuration, and other factors.
Application Layer Protocol Negotiation (ALPN)
Application Layer Protocol Negotiation (ALPN), as the name implies, is a TLS extension that addresses this need. It extends the TLS handshake (Figure 4-2) and allows the peers to negotiate protocols without additional roundtrips. Specifically, the process is as follows:
The client appends a new ProtocolNameList field, containing the list of supported application protocols, into the ClientHello message.
The server inspects the ProtocolNameList field and returns a ProtocolName field indicating the selected protocol as part of the ServerHello message.
The server may respond with only a single protocol name, and if it does not support any that the client requests, then it may choose to abort the connection. As a result, once the TLS handshake is finished, both the secure tunnel is established, and the client and server are in agreement as to which application protocol will be used; the client and server can immediately begin exchanging messages via the negotiated protocol.
Server Name Indication (SNI)
An encrypted TLS tunnel can be established between any two TCP peers: the client only needs to know the IP address of the other peer to make the connection and perform the TLS handshake. However, what if the server wants to host multiple independent sites, each with its own TLS certificate, on the same IP addres
To address the preceding problem, the Server Name Indication (SNI) extension was introduced to the TLS protocol, which allows the client to indicate the hostname the client is attempting to connect to as part of the TLS handshake. In turn, the server is able to inspect the SNI hostname sent in the ClientHello message, select the appropriate certificate, and complete the TLS handshake for the desired host.
Leverage Early Termination
we may not be able to make our packets travel faster, but we can make them travel a shorter distance. By placing our "edge" servers closer to the user (Figure 4-9), we can significantly reduce the roundtrip times and the total costs of the TCP and TLS handshakes.
A simple way to accomplish this is to leverage the services of a content delivery network (CDN) that maintains pools of edge servers around the globe, or to deploy your own. By allowing the user to terminate their connection with a nearby server, instead of traversing across oceans and continental links to your origin, the client gets the benefit of "early termination" with shorter roundtrips. This technique is equally useful and important for static and dynamic content: static content can also be cached and served by the edge servers, whereas dynamic requests can be routed over established connections from the edge to origin.
https://hpbn.co/transport-layer-security-tls/
- DIFFIE-HELLMAN KEY EXCHANGE VS. RSA
DH securely generates a unique session key for encryption and decryption that has the additional property of forwarding secrecy.
The algorithm has a high processor overhead; it is not used for bulk or stream encryption but rather to create the initial session key for starting the encrypted session.
Afterward, under the protection of this session key, other cryptographic protocols negotiate and trade keys for the remainder of the encrypted session
Think of DH as an expensive method of passing that initial secret.
Uses of Diffie-Hellman
DH is one of the most popular key exchange protocols.
While using DH key exchange, the sender and receiver have no prior knowledge of each other.
Communication can take place through an insecure channel.
Public Key Infrastructure (PKI)
Secure Socket Layer (SSL)
Transport Layer Security (TLS)
Secure Shell (SSH)
Internet protocol security (IPsec)
Limitations of Diffie-Hellman
Does not authenticate either party involved in the exchange.
It cannot be used for asymmetric exchange.
It cannot be used to encrypt messages.
It cannot be used to digital signature
What is RSA Algorithm?
RSA Algorithm is used to perform public-key cryptography.
Uses of RSA
Assures confidentiality, integrity, and authentication of electronic communication.
Secure electronic communication.
RSA is used in security protocols such as IPsec, TLS/SSL, SSH.
Used for signing digital signature.
High-speed and straightforward encryption.
Easy to implement and understand.
It prevents the third party from intercepting messages.
Limitations of RSA
Prolonged key generation.
Vulnerable when it comes to Key exchange if poorly implemented.
Slow signing and decryption process.
RSA doesn’t provide perfect forward secrecy
https://www.encryptionconsulting.com/diffie-hellman-key-exchange-vs-rsa/
