A Comprehensive Guide to TLS: Exploring Its Phases and the Changes Between TLS 1.2 and 1.3
Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over the internet. When you browse and interact with any website, it is crucial to ensure that your most valuable data, such as credit card numbers, bank account usernames, and passwords, remain uncompromised. TLS plays a vital role in this regard by encrypting your data during transmission, thereby securing it from any potential threat.
By implementing TLS on a website, users can enjoy a safer browsing experience, as their sensitive data is protected from cyber-attacks and data breaches. This ensures that the website is compliant with the latest security standards and helps to establish trust between the website and its users.
Then, what is SSL? The term SSL stands for Secure Sockets Layer, and it is often used interchangeably with TLS, as both refer to protecting your data during transmission over the internet. SSL is an older encryption method adopted in the late 1990s, and it has since been replaced by TLS, which offers better security.
The transformation from SSL 1.0 → SSL 2.0 → SSL 3.0 → TLS 1.0 → TLS 1.1 → TLS 1.2 → TLS 1.3 is briefly explained in the History section of this article. However, for the purposes of this discussion, we will focus on TLS 1.2 and TLS 1.3 since they are the most commonly used versions. If you are working on any projects currently, they will most likely fall under one of these versions.
You may have noticed a small lock icon 🔒 in the browser URL tab, indicating a secure connection during online transactions. This means that the URL starts with https:// which stands for Hypertext Transfer Protocol Secure. In simpler terms, HTTPS is a secure version of HTTP that encrypts the data being exchanged between your browser and the website you’re visiting. So, whenever you see the lock icon and https:// in the URL, you can rest assured that your online activity is being conducted securely.
What is an SSL/TLS certificate? An SSL/TLS certificate is an X.509 digital certificate that provides secure communication over the internet. It is issued by a Certificate Authority (CA) such as DigiCert, Symantec, Let’s Encrypt, etc… These companies offer a range of certificates, some of which are free while others require payment, depending on your needs.
The role of a CA is to verify the identity of the website and ensure that it is genuine and trustworthy. By obtaining an SSL/TLS certificate from a trusted CA, website owners can assure their users that their data is secure and protected from potential threats.
In a while, we’ll take a closer look at how SSL/TLS certificates provide enhanced security and protection for users, exploring the specific ways in which they do so. For now, let’s discuss how TLS works and what things you should know about TLS.
From 10 Miles above, TLS has two phases
- Handshake :- This phase is the most complicated and most researched phase where the client and server agree on a symmetric key which is then used to encrypt and decrypt the data during the transmission.
- Secure data transmission :- This phase of secure communication is a simpler process than the first, as it doesn’t require key generation or distribution. Instead, it focuses on securely transferring data using the symmetric key from phase one. However, there are still complexities to consider, such as ensuring proper ordering and preventing replay attacks, which we’ll discuss further in this article.
TLS Deep Dive
There are so many things to discuss about TLS, including the differences between the workflow of TLS 1.2 and TLS 1.3, various encryption algorithms, and why some companies still support older versions of TLS etc… We will cover some of the main aspects of TLS that you should know when dealing with it, and we will touch briefly on encryption algorithms which itself is a topic for a more in-depth discussion. As usual, let’s dig in by asking the questions that pop into our mind
1. What exactly is happening during the handshake?
The handshake process is a critical and constantly evolving component of TLS, and it is perhaps the main point of difference between all the TLS versions. During this process, the actual key used to encrypt the data is exchanged between the client and server, making it a crucial step that demands higher security. The handshake period of older TLS versions has been vulnerable to well-known security attacks, such as the BEAST and POODLE attacks.
Handshake process itself has 4 main aspects
1Negotiation
During this step, the client sends a request known as the “Client Hello” to the server, which includes all the SSL/TLS versions that the client supports, a suite of cryptographic algorithms that the client is willing to use, as well as other relevant information for the remainder of the handshake process or the application. The negotiation process is the most complex aspect of Handshake and has been the source of many attacks in the past, such as FREAK, LOGJAM, DROWN, etc… that took advantage of security vulnerabilities present in older versions to break more recent versions of the protocol. More on this in the later part of this article.
Note: ** In the above picture, the 5th point include some optimization introduced in TLS 1.3 for a faster handshake. More on this will be discussed later in this article.
The suit of cryptographic algorithms in the request is categorized as follows
- Key exchange algorithms :- During the handshake process, cryptographic algorithms are used to securely exchange keys between the client and server. These algorithms ensure that only the client and server have access to the keys, preventing unauthorized access to sensitive information.
Previously, both key exchange and data transmission was encrypted using the same algorithm. However, the option to use different algorithms was added in TLS 1.2 onwards. As a result, in most transactions that occur in TLS 1.2 or later, different algorithms are used for key exchange and data transmission unless the strongest algorithm from the key exchange suite and data transmission suite of the client and server are the same and it is very unlikely.
Most well-known TLS implementations, such as OpenSSL, Microsoft SChannel, and Java Secure Socket Extension (JSSE), support almost all of the algorithms that are supported by the latest version of TLS.
Elliptic Curve Diffie-Hellman (ECDH), RSA (Rivest-Shamir-Adleman), Diffie-Hellman (DH), and Secure Remote Password (SRP) are the most popular and commonly used key exchange algorithms, listed in order. - Digital signature algorithms :- Used to verify the authenticity of digital certificates, which are used to authenticate the identity of the server to the client during the TLS negotiation. This ensures that the client is communicating with the intended server and not an imposter.
The process of digital signature in TLS involves a combination of private and public keys. The private key is used to sign the message, and the public key is used to verify the signature. This process ensures that the message has not been tampered with or altered during transmission.
TLS uses a variety of digital signature algorithms, including RSA, DSA, and ECDSA. These algorithms are used to sign and verify digital certificates, which contain the public key of the server or client. More on this later in this article.
RSA (Rivest-Shamir-Adleman) signatures, Elliptic Curve Digital Signature Algorithm (ECDSA), and Digital Signature Algorithm (DSA) are the most popular and commonly used key exchange algorithms, listed in order. - Hash functions :- Hash functions are used in both the handshake and data transmission phases of TLS. Only the initial calls in the handshake (Negotiation phase) are an exception to it as there is no mutual agreement on the choice of the hash function between the client and server yet. once the server and client agreed on the cipher suite then the remaining handshake process and data transmission use the hash function for data integrity.
During the handshake phase, hash functions are used to compute a message digest of the handshake messages exchanged between the client and server. This message digest is used as input to the key derivation function, which generates the master secret key used for encryption and decryption of the data exchanged between the client and server.
In the data transmission phase, hash functions are used to compute the message authentication code (MAC), which is a fixed-length value that is sent along with the data. The MAC is computed using a hash function and a secret key shared between the client and server. The receiver can use the same hash function and secret key to compute the MAC and compare it with the received value to ensure that the data has not been modified during transmission.
SHA-256, SHA-384, and SHA-512 are the most popular and commonly used key exchange algorithms, listed in order. - Authenticated encryption algorithms :- This algorithm combine both encryption and integrity checking, ensuring that the transmitted data is both confidential and has not been tampered with during the transmission.
TLS uses symmetric encryption algorithms, such as Advanced Encryption Standard (AES), to encrypt the data exchanged between the client and server. However, symmetric encryption alone does not provide authentication or integrity protection, which means that an attacker could potentially modify or tamper with the data in transit without detection.
To address this issue, TLS uses authenticated encryption algorithms that combine encryption and message authentication codes (MACs) to provide both confidentiality and data integrity protection. These algorithms encrypt the data using a secret key shared between the client and server, and they also compute a MAC over the encrypted data using a separate secret key.
AES-GCM (Advanced Encryption Standard – Galois/Counter Mode), ChaCha20-Poly1305, and AES-CBC (Advanced Encryption Standard – Cipher Block Chaining) are the most popular and commonly used key exchange algorithms, listed in order.
2Key exchange
Key exchange is the crucial phase in the handshake where the client and server negotiate a common key which then is used to transfer the data. The algorithm which TLS uses for negotiating keys is kind of more secure and might be more expensive in terms of computation time. So this is one of the reasons why most of the latest TLS implementations do not use the key exchange algorithms for data transfer. TLS uses Session Resumption to minimize the impact on performance caused by such an expansive algorithm in the handshake phase. More about this is in the later part of this article.
In TLS 1.2 the key exchange happens after the negotiation ie; after the server and client agree on the Key exchange algorithm. The detailed steps are given in the below image.
TLS 1.3 came up with a possible improvement in the handshake by passing the public keys themselves in “Client Hello” and “Server Hello”. This is equivalent to combining both the Negotiation and Key Exchange phases of the handshake together into a single phase. Let’s look at how it’s done.
If somebody reads this article, they may think, “Oh wait a minute! Even key exchange requires an algorithm. Then how on earth can the client send a public key before negotiating an algorithm with the server?”
This is a valid question. Actually, the client picks one of the strongest algorithms from the list of algorithms it will send to the server for negotiation, encrypts the public key with that algorithm, and sends it to the server under the assumption that the server may support the same algorithm. Trust me, this works most of the time as most of the modern clients and servers are up to date with the latest TLS versions and algorithms.
Then what happens if the server does not support the algorithm which the client used to encrypt the public key? let’s look at that flow
In this case, the server sends a “Hello Retry Request” with the algorithm it supports (chosen from the list of algorithms that the client sent), and the client repeats the “Client Hello” call, sending the encrypted public key along with it. However, this time, the public key is encrypted using the algorithm that the server sent along with the “Hello Retry Request”.
If you carefully observe the difference between TLS 1.2 and TLS 1.3 with the extra round trip, the no of calls are same. So that is why this is a possible improvement but not a guaranteed one. As I mentioned earlier the modern client and server interaction we get to see this saving of extra round trip most of the time.
3Authentication
Authentication is used to verify the identity of a website and to ensure that the communication between a client and a server is not tampered with or modified in transit. The verification process uses digital signatures to guarantee that the data has not been altered or corrupted, thus ensuring data integrity.
The problem at our hands is how do we verify that we are talking to the right server and not to anybody in the middle like an attacker? Since the internet is an open network and the messages we send go through several hops, anybody in middle can mimic the actual server and replay on behalf of your server.
In the above image the boy is sending money to his girlfriend and the hacker hacks the communication between the boy and the bank. Since the hacker is communicating with the boy, the hacker can easily decrypt the messages of the boy, which includes the credentials and OTP, etc… and talk to the real banking server on behalf of the boy. Now the hacker can do whatever he wants to do with the boy’s bank account.
So what do we do? How can we tackle this problem? This is where the SSL/TLS certificate comes into play. In the overview section of this article, we briefly touched upon the certificate and CA (Certificate authorities, etc…). Now let’s understand what is a certificate and how it is going to help to solve the above situation.
Every browser trusts a list of CAs, which includes the CAs from the browser’s trusted list and the CAs from the System list. For example, in Chrome, if you navigate to chrome://settings/security you can see two options below where you can explore the CAs that your system and browser trust.
Additionally, the server keeps the public key as part of the CA list, which is then used to verify the signature. So, now the question is what is a signature? and where are we using it?
In short, the signature is a digital signature signed by the CA using its private key and can only be validated through the public key of the CA. In detail, when a user requests a certificate for their server, they need to prove that they have control over the domain name for which the certificate is being requested, and upon proving this the CA will generate a new certificate and give it to the user.
The picture above shows how a CA asks the owner of scribbledtech.com to prove that they own the domain. Different CAs use one or more protocols like ACME (Automated Certificate Management Environment) protocol, Certificate Management Protocol (CMP), Simple Certificate Enrollment Protocol (SCEP), Online Certificate Status Protocol (OCSP), etc…
In the above example, we used the ACME protocol that allows the user to prove domain ownership by demonstrating control over the domain’s DNS records or by serving a challenge file from the web server at a specific URL. Once the domain ownership is verified, the CA issues a certificate for the domain.
Let’s take a closer look at how the CA signs the TLS certificate and how the signing process works. First, the website owner provides the public key of the server, which is a long-lasting key and not an ephemeral key. After verifying domain ownership, the CA generates a certificate that includes the public key and other relevant information. Then, it generates a one-way hash value of the entire content and uses its private key to encrypt it. This encrypted value is known as the digital signature. The final content of the certificate includes the public key of scribbledtech, other relevant information, and the digital signature.
When we examine certificates, we often encounter multiple chained certificates. It is unlikely to find a TLS certificate that is directly signed by trusted ROOT CAs. This is because the trust is transitive, meaning that if person A trusts person B, and person B trusts person C, then person A trusts person C.
To understand the chaining process and how we can confirm the server’s authority, let’s examine a sample TLS certificate.
In the image above, there are 3 certificates that form a chain. The TLS certificate verification process begins with the leaf certificate, also known as the server certificate. In some cases, there may be multiple intermediate certificates in the chain, and it ends with a ROOT certificate. Let’s take a closer look at the step-by-step process of certificate verification.
- Verification starts with the leaf/server certificate, to verify the digital signature of the leaf certificate, the client checks its expiration date and status, as well as performs certificate verification. To do this, the client uses the public key in the intermediate CA certificate because the digital signature is signed with the private key of the issuer. In the case of the leaf certificate, the issuer is the intermediate CA. Keep in mind that the public key present in the leaf certificate is not used for any verification purpose it is used in the further steps of Handshake.
- During verification, the client generates a SHA of the certificate content using the hash algorithm negotiated in the negotiation phase. It then uses the public key of the intermediate CA to decrypt the digital signature and obtain another SHA value. The two SHA values are then compared to confirm the validity of the certificate.
- Once the client is done with the verification process of the leaf certificate, it checks whether the CA is present in the list of trusted CAs. In this case, the intermediate CA (R3) is not a trusted one, so the client starts the verification process of the intermediate CA certificate in the same way it did for the leaf certificate. This involves checking the validity, status, and verification of the signature using R3’s issuer’s public key, which is the public key of the ROOT CA (ISRG Root X1) in this case.
- The process will continue until the client encounters a trusted certificate in the chain. However, if someone manually added the R3 certificate, the verification chain would have stopped at the first step and would not proceed to verify the ROOT certificate. The Trusted/Root certificate is self-signed and the client does a similar verification process on the root certificate as others but uses the public key of the ROOT itself as ROOT does not have any issuer hence no issuer public key.
4Session Resumption
You may have already realized that the process of handshaking in TLS can be expensive and have a significant impact on performance. However, modern systems have implemented a solution to this problem called Session Resumption.
Session Resumption involves reusing the already negotiated handshakes from previous sessions for new sessions, which helps to reduce the overhead of additional handshakes. In other words, the client and server can use a previously established session key to quickly establish a new secure connection without having to perform a full handshake again. This technique significantly improves the performance and scalability of TLS, especially for systems handling heavy traffic and load.
There are two commonly used ways to do this
- Session Identifiers :- During the full TLS negotiation, the server creates and sends a 32-byte session identifier as part of its “ServerHello” message. This session ID allows both the client and server to store the previously negotiated session parameters, keyed by session ID, and reuse them for a subsequent session.
Once the session ID is created and stored, the client can use it in the next “ClientHello” message to let the server know that it remembers the previous handshake and can reuse the negotiated cipher suite and keys. If the server finds the session parameters associated with the ID in its cache, it can proceed with an abbreviated handshake. Otherwise, a full new session negotiation is needed, which will generate a new session ID.
The Session Identifiers mechanism has a practical limitation where the server needs to create and maintain a session cache for every client, because of this it is also called “session caching“. This results in memory consumption, cache, and eviction policies, and deployment challenges for sites with many servers. But with careful planning and architecture, many high-traffic sites are using them successfully today.
- Session Ticket :- Unlike the session identifier, the Session Ticket replaces the need for the server to maintain a per-client session state. If the client supports session tickets, the server can send a New Session Ticket record with all session data encrypted using a secret key known only to the server.
The client stores both the session parameters and session ticket, and includes the session ticket in the ClientHello message of the next session. The ticket is decrypted at the server end to reuse the session, this way, session data is stored only on the client, making it safe. Since nothing is saved on the server side, it is also called “Stateless Resumption”.
Deploying session tickets across a set of load-balanced servers requires careful planning and architecture. All servers need to have the same session key, and an extra mechanism is needed to securely and periodically rotate the shared key across all servers.
In modern TLS, session tickets are used more often than session identifiers. Session tickets provide a stateless resumption mechanism whereas session tickets offer better security by allowing the server to rotate encryption keys frequently, making it harder for attackers to decrypt stored session data.
2. How does TLS ensures both security and performance during data transmission?
In the Data Transmission phase, things are pretty straightforward. The application data is encrypted and decrypted using a symmetric key that was shared during the handshake phase.
1Security
Even though this sounds simple there are some more things TLS does for additional security, let’s look at some of them here
- Forward Secrecy :- This is something that ensures the confidentiality of past communications remains intact even if the secret key used to encrypt those communications is compromised in the future. This is not something that is achieved during the Data Transmission phase of TLS. Instead, it is a by-product of the key generation algorithm used during the handshake phase.
Without Forward secrecy, an attacker can record all data transmitted through the channel and decrypt it later if they obtain the private key.
Forward secrecy using ephemeral keys generates temporary and unique session keys for each session in TLS, making it harder for an attacker to decrypt data in the future. This adds an extra layer of security to the process. As a result, popular browsers prefer ciphers that enable forward secrecy such as Diffie-Hellman key exchange, and may only enable certain protocol optimizations when forward secrecy is available, such as 1-RTT handshakes via TLS False Start. The RSA handshake is being actively phased out due to this preference. - Message Authentication Codes (MACs) :- We have mentioned MAC early in this article, It is a way to check if a message is real and not changed. It uses a secret key that only the sender and receiver know. The MAC is made by using an algorithm on the message and the secret key. Then, the MAC is added to the message and sent to the receiver. The receiver can also use the same key and algorithm to check the MAC and make sure the message is safe during travel.
Commonly used MAC algorithms, such as HMAC-SHA256, produce a 256-bit MAC, while others may produce a 128-bit or 512-bit MAC. The larger the size of the MAC, the more secure it is against attacks. However, a larger MAC also requires more processing power and may increase the message size, which can impact performance in some cases. - Nonce :- It is a random or pseudo-random number unique for each connection that starts at a fixed value and is incremented for each new message. This helps to prevent replay attacks and ensures that messages are received in the expected order. If a message is replayed or reordered, the nonce will not match the expected value and decryption will fail. In such a case, the TLS connection is terminated to prevent any further communication with the potentially compromised session.
The nonce is often referred to as an IV (Initialization Vector) and is used in conjunction with the encryption algorithm to ensure the confidentiality and integrity of data. The length and format of the nonce field in TLS may vary depending on the specific cryptographic algorithm being used. - Message Padding :- It is a technique used in data transmission that involves adding extra bytes to the message. It serves two primary purposes, firstly, it ensures that the length of the plaintext message being encrypted conforms to the block size of the encryption algorithm used. Secondly, the extra bytes added to the message make its length less predictable, making it harder for attackers to deduce information about the message or the encryption key.
To support message padding, the TLS protocol offers various padding techniques, including the PKCS#7 padding scheme. This scheme adds bytes to the message in a specific way, allowing the padding to be removed after decryption. The padding bytes themselves are not part of the original message and are discarded after decryption.
2Performance
In order to enhance TLS performance and reduce server-client communication, various techniques are employed such as caching handshake information and combining multiple calls into a single one. Before delving into performance enhancement, it is important to examine all the calls involved in a complete handshake, including the TCP handshake, TLS handshake, and data transmission.
Let’s look at some commonly used techniques one by one and see the how the TLS gradually evolved to perform better.
- TLS False Start :- It is an optional protocol extension where the client starts sending data to the server before the handshake is complete, which reduces the round trip time required for the handshake. This is possible when both client and server support a shared cipher suite and the client is confident that the server will accept the connection.
- TCP Fast Open :- It is a mechanism that allows a client to include data in the initial SYN packet to the server, which can be immediately processed by the server before the TCP connection is fully established. This can potentially reduce the latency of the TCP handshake and improve overall performance, especially for short-lived connections.
In this when a “Fast Open capable” client connects to a server it sends an empty cookie in the TCP SYN message, Server treats this one as a Cookie request and sends back a valid cookie in the response
After the initial connection is established, the client will include the cookie in the TCP SYN message of subsequent connections and begin sending data right away. If the server confirms the validity of the data, it will receive and transfer it to the application.
Enabling TCP Fast Open allows for the sending of data before the complete connection is established, resulting in an immediate arrival of responses. By combining TCP Fast Open and TLS False Start, key negotiation and the initial TCP handshake can be performed simultaneously. - 0-RTT with TLS 1.3 :- TLS 1.3 introduces a zero round-trip time (0-RTT) mode, which allows the client to send data to the server in the first flight of the handshake, without waiting for the server to confirm its credentials. This reduces the latency for the first request.
While 0-RTT can provide faster and more efficient data transmission, it should be used with care as it comes with potential pitfalls such as replay attacks, limited use cases, the need for a pre-shared key (PSK) and forward secrecy, increased complexity, and others.
If we compare the time taken for each of the above method, you can see t1>t2>t3>t4>t5 Some studies have shown that the difference between t1 and t5 is around 30 to 50%, meaning that t5 takes significantly less time than t1.
3. How can I, as a developer or architect, improve the security and performance of TLS?
While the above mentioned options can help improve security and performance, it’s worth noting that there are various TLS implementations and not all follow the same standards, meaning that these options may not always be enabled by default or standardized across different implementations.
Let’s review a checklist to ensure that we’re maximizing the benefits of TLS in terms of security and performance, and optimizing it for our specific needs. We’ll focus on the server side, as the client side is often outside of our control. We’ll use Nginx as an example, as it’s one of the most popular web servers.
1TLS Version :- Try upgrading the TLS to the latest on the server and client sides if possible. For some of the below points, we are going to assume that the client and server are using the same, and the latest, TLS 1.3.
21-RTT and 0-RTT / TLS False Start :- To check if 1-RTT is enabled on the server, look for the ssl_early_data option and make sure it’s set to off. Enabling 0-RTT (TLS 1.3) or TLS False Start (<TLS 1.3) requires different settings. For 0-RTT, set the ssl_early_data directive to on to enable sending application data in the initial handshake. For False Start, configure the ssl_early_data_chunk_size and ssl_early_data_size directives to specify the amount of data that can be sent in each chunk.Here’s how to enable 1-RTT / TLS False Start in Nginx
server {
listen 443 ssl;
server_name scribbledtech.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
ssl_early_data on;
...
}
Note that enabling 1-RTT can increase the risk of certain attacks, such as replay attacks, so it’s important to carefully evaluate the risks and benefits before enabling this feature.
3TLS record size :- Optimizing TLS record size can improve the performance of TLS connections by reducing the number of network round trips needed to transfer data. Here’s how to optimize TLS record size in Nginx
http {
listen 443 ssl;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
ssl_buffer_size 4k;
}
You can experiment with different buffer sizes to find the optimal size for your application. Keep in mind that larger buffer sizes can increase memory usage on the server, so it’s important to balance performance and resource usage.
4Session Caching And Stateless Resumption :- you can configure both session caching and session tickets . When both are enabled, server will use session tickets for stateless resumption by default, but it will fall back to session caching for stateful resumption if a session ticket is not available or valid. Here’s how to enable it in Nginx
server {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
}
The above configuration enables the SSL session caching with shared cache among worker processes (shared:SSL) and a size of 10 MB (10m), setting SSL session timeout to 10 minutes, and enabling SSL session tickets for alternative session resumption mechanism with potential security implications
There are somany other things there that you can add in your checklist, such as configuring OCSP stapling, HSTS, HPKP, CSP policies, HTTP/3 etc. Will save these options for some other day.
4. How can I inspect the entire TLS handshake and configuration of existing server?
To check your server’s TLS configuration, you can use online tools or run the OpenSSL command in your terminal. Using OpenSSL you can inspect the TLS handshake process and will give an idea about the configurations of your server.
For example, you can connect to your website on the default TLS port (443) and perform a TLS handshake. Some of the fields mentioned in this article are emphasized in the Result for easy review.
📂 ~ ▶︎ openssl s_client -state -CAfile root.ca.crt -connect scribbledtech.com:4434314891820:error:02FFF002:system library:func(4095):No such file or directory:/AppleInternal/Library/BuildRoots/a0876c02-1788-11ed-b9c4-96898e02b808/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2.8/crypto/bio/bss_file.c:122:fopen('root.ca.crt', 'r')
4314891820:error:20FFF080:BIO routines:CRYPTO_internal:no such file:/AppleInternal/Library/BuildRoots/a0876c02-1788-11ed-b9c4-96898e02b808/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2.8/crypto/bio/bss_file.c:125:
4314891820:error:0BFFF002:x509 certificate routines:CRYPTO_internal:system lib:/AppleInternal/Library/BuildRoots/a0876c02-1788-11ed-b9c4-96898e02b808/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2.8/crypto/x509/by_file.c:248:
CONNECTED(00000005)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.webhostingservices.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/CN=*.webhostingservices.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA
i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGUTCCBTmgAwIBAgIQJfXTj1qG93EmRIsQktrwHzANBgkqhkiG9w0BAQsFADCB
jzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQD
Ey5TZWN0aWdvIFJTQSBEb21haW4gVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENB
MB4XDTIyMTAwNDAwMDAwMFoXDTIzMTEwNDIzNTk1OVowIzEhMB8GA1UEAwwYKi53
ZWJob3N0aW5nc2VydmljZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEApSeSIfSYE1qv8QbAczFBOY/PA4yw4E8dSSIpNKGATCC1TFltfrx/pcyM
tem0KGt+8S4JJ/t88PE9nbK3fxP8SfV8Af6MtIvd9h7S2H9LWS/k1/LrkH6wu2cg
nisNl8YiZXL+WQ683MKjMy+5oC0IFYMJL+QRUL1Xp0sgCGVb1iNFAKi21zOvyaEc
YNS04u6ePyI87EbGb3/6IS6COsaLwhqltAFzROBJW1qOaY4Hec77ON1ML/41yfA4
kUvNY7seWf/u6CgbA8cbmjjxOqTeZIVGR89vyhRuLbQmvgd5e7oyvZhYsRW8ZWf5
e8kZNH1atBE+Tssn8H/oCja0gArqsQIDAQABo4IDEjCCAw4wHwYDVR0jBBgwFoAU
jYxexFStiuF36Zv5mwXhuAGNYeEwHQYDVR0OBBYEFKhp8de05XvyBL+M6Z8WAXNM
tBsUMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjBJBgNVHSAEQjBAMDQGCysGAQQBsjEBAgIHMCUwIwYI
KwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMAgGBmeBDAECATCBhAYI
KwYBBQUHAQEEeDB2ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LnNlY3RpZ28uY29t
L1NlY3RpZ29SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3J0MCMG
CCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTA7BgNVHREENDAyghgq
LndlYmhvc3RpbmdzZXJ2aWNlcy5jb22CFndlYmhvc3RpbmdzZXJ2aWNlcy5jb20w
ggF+BgorBgEEAdZ5AgQCBIIBbgSCAWoBaAB3AK33vvp8/xDIi509nB4+GGq0Zyld
z7EMJMqFhjTr3IKKAAABg6QijNYAAAQDAEgwRgIhAOSfjMsYAEFkfIlozmj+Q+jd
o+kzU3iileNwj9R2MgPwAiEA27jMmVSwr7Vkovw7uM99QG9/2WytZ3uS9ZsCK/DB
ysMAdQB6MoxU2LcttiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYOkIoy5AAAE
AwBGMEQCIFLnaY3k3NZQmsJJIoOAhNHZJXj6g8UGPcXMDUvcoWhMAiB10LXbgmk1
RC8i9UvA+OcHTHbYQi/NApFTRxGavHUxAwB2AOg+0No+9QY1MudXKLyJa8kD08vR
EWvs62nhd31tBr1uAAABg6QijHwAAAQDAEcwRQIhANQGeXFB+TPnVeNMOaOTSvB6
hLilHErk31m0jf7pU1p8AiBQX5N9j/OXsmNuQhip92EoN5gXnTFYfrfK/aTUe2Uq
mTANBgkqhkiG9w0BAQsFAAOCAQEAvs6GBTHxFrgDtPQOM+rAs3eGW3BdCB4yXKZ+
JLkBhB46ZbrFdKg8iPOqyt4dcYhJ3MHbE/OicFLWqfTKymlkzEcoDIuezSqlzsLb
PelNHGnfDwDEul+/DAZLdvhPVZg41xKx5ynrM/XgXChdJGuNgB9hOXGBvmUUD51d
Ru/R3YDiuOLW8Sb6SVbhb1LMgzq8uNDPqLVr0hLmyxwiIoAquIpw9PaVmrIKai92
nBkqiWDnqoHQeNKFjiUMusoGG7EOGrdmkd7SKznY0aKjyyeQixVrP2oNSdhw8kHi
6mIIfdi9ZWgg5RHPHFO3b9mEWw2qLdToA1XijtvXIV7Kv183Rw==
-----END CERTIFICATE-----
subject=/CN=*.webhostingservices.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 5252 bytes and written 289 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 96030A4D505A354A4DC5B2F999FD0F8284A77C452BD9E8573192197AB8EAEA86
Session-ID-ctx:
Master-Key: DEE83975A7FD88C422F7E8B4B07FEB63782F8FFBC35FB162D79025C2464EDE17C2AD4383E83EAC8F6E76B076BB660186
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 08 01 28 11 07 ab 64 d5-08 fe f9 d8 a4 8b 40 b9 ..(...d.......@.
0010 - b3 c2 2d db 82 c1 ec 1e-8e 90 ac 7a 86 2b 26 aa ..-........z.+&.
0020 - 9b 1b a6 29 e5 b4 34 15-56 42 d4 63 a5 19 f8 9b ...)..4.VB.c....
0030 - 11 18 fc 2a de ab 14 8c-88 b3 c6 5f de 22 9e 58 ...*......._.".X
0040 - 79 32 4c b3 a3 5b 78 88-bd 1e a8 cf 9d d0 be 00 y2L..[x.........
0050 - 11 e0 62 01 da d3 6a 78-1d 86 e7 8c c4 7e 17 ee ..b...jx.....~..
0060 - 32 9a 99 e6 53 c5 4b 49-b2 d1 73 02 ca bd 97 4b 2...S.KI..s....K
0070 - 55 c5 84 f9 d4 73 1e 01-d8 c5 4d 91 bf 20 53 6a U....s....M.. Sj
0080 - 66 fb 8e 0d ae d0 57 ba-99 6c 52 01 86 00 50 34 f.....W..lR...P4
0090 - fa 4d 32 e4 4e aa d9 e0-0b f3 65 f4 a2 15 1b c9 .M2.N.....e.....
00a0 - 46 b6 17 2a 49 b9 ca a6-cf 13 f1 cc 52 f9 0b 35 F..*I.......R..5
00b0 - af 53 a6 cf 7e 66 ce 73-a5 8a 9e 69 ac 8d 23 e8 .S..~f.s...i..#.
Start Time: 1679548305
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
SSL3 alert read:warning:close notify
closed
SSL3 alert write:warning:close notifyBy following best practices for TLS configuration, you can ensure your website or application is protected from cyber threats.
History
The World Wide Web (WWW) was introduced to world by Berners-Lee in 1990s and became so popular in short time. By 1995 there were around 16 million users in the world and was counting. Obviously, this caught the eye of many companies. When they began using the internet, they realized that data transmission was not secure and could be intercepted. At that time, only HTTP was available, and HTTPS did not exist yet.
This is when the Secure Sockets Layer (SSL) is came into existance. SSL was introduced by company known as Netscape with the help of their renowned cryptographer Taher Elgamal also know as the father of SSL. SSL 1.0 is never released as it had severe security volnurabilites. SSL 2.0 is the first one is released in 1995 and the Secure HTTP (HTTPS) came into existence too. However, the internet community soon realized that SSL 2.0 also had security vulnerabilities, which led to the release of SSL 3.0 by the Internet Engineering Task Force (IETF) in 1996.
Then what is TLS? TLS and SSL are often used interchangeably, but technically they refer to different versions of the protocol. When the SSL protocol was standardized by the IETF in 1999, it was renamed to Transport Layer Security (TLS). There weren’t many changes between SSL3.0 and TLS 1.0.
After the initial release of TLS, three subsequent versions have been introduced, the first of which was TLS 1.1 in 2006. TLS 1.1 included several significant improvements over its predecessor, such as enhanced protection against cipher-block chaining (CBC) attacks and the capability to support Internet Assigned Numbers Authority (IANA) registration parameters. However, both TLS 1.0 and 1.1 were subsequently discovered to be susceptible to vulnerabilities, and they were scheduled to be phased out in March 2020.
TLS 1.2 was released in 2008 after TLS 1.1, brought significant security improvements, including better hash and algorithm specifications. Its quick release prompted users to upgrade directly to TLS 1.2, making it the most widely used SSL/TLS protocol.
TLS 1.2 is widely considered one of the most secure SSL/TLS protocols, and it remains the preferred choice for most systems. However, TLS 1.3 was introduced in 2018 and brings even more robust security and performance enhancements, such as eliminating support for MD5 and SHA-224, enabling Perfect Forward Secrecy, offering 0-RTT capabilities etc…
TLS is constantly evolving with ongoing research and development. Some of the areas of research include post-quantum cryptography, improving TLS performance and security, and exploring new encryption techniques for data privacy etc… So, still there are so much os things that we can expect in the TLS world and hopefully will discuss those topics in another article.
