The need for network encryption.

Let’s talk about postcards. You go on holiday. You buy one with a pretty sunset picture, address it to your friend, write a pithy saying, put an international stamp on it, and drop it in a mailbox, hoping that it gets home before you do. But the thing you do not think about is that a postcard because it is not inside an envelope, can be read by everybody that is along the route that it takes to get to its destination.

In the early days of the Internet and the web, websites were the functional equivalent of a bunch of postcards. There was not really a need to encrypt data that you allow anybody to see. And this was great for sharing information—a lot of data could be grabbed across the network between you and the webserver:

• Your username and password
• Your login token/cookie
• Your credit card details
• Your Personally Identifiable Information, such as phone number and address
• Any content behind a login wall

People even built tools like dSniff to demonstrate how much data was exposed. At hacking conferences like Defcon, they have a “Wall of Sheep” with a large display to show passwords that were captured recently across the network. All these tools do one thing: they read the back of the postcard while they pass it along to the destination.

The digital equivalent of postcards does not work if you want to buy and sell things online. They do not work if you want to look at your bank account statement. They do not work if you want to register for a doctor’s appointment.

To solve this problem, Secure Sockets Layer (SSL) was created. It is a method by which a web browser (or any other client application like an email reader) negotiates an encrypted session (sometimes called a tunnel) between itself and a server. 

You will also see people refer to this as a “TLS handshake” as if you are introducing a web browser to a server. This involves a certificate exchange, where the client validates that they are talking to the correct server. 

The negotiation also creates a session key used to encrypt data in the conversation. Lastly, the server presents a list of encryption and hash algorithms that it supports, and the client picks the best one that it is capable of doing.

Certificates and certificate authorities.

A huge part of TLS is the use of certificates to identify computers. These are also called X509 certificates after the standard, which explains their composition and layout. A certificate is a combination of a public encryption key, a set of identification information, and a signature chain originating at a Certificate Authority, or CA.

For example, you can see that vercara.com uses a certificate signed by the CA Digicert.

You can generate a certificate by yourself. That is called a “self-signed certificate”, and it might work for your home lab, where you know that you issued it. However, it will not be accepted by any browser and will display an error to the user. 

The reason is that TLS clients have a list of CAs that they accept as “trusted”. You can view this list of certificates in either your browser settings or your operating system. For example, inside of Google Chrome on some operating systems, your CA certificates are stored in chrome://settings/certificates. 

When the client is given a certificate during TLS negotiation, they see that the certificate is signed by another certificate, which is in turn signed by another certificate, and so on, until the signature chain results in a CA certificate that the client trusts. 

For example, if we look at the certificate chain for vercara.com, we see that our browser trusts the CA certificate for “DigiCert Global Root C2,” which has signed the “RapidSSL TLS RSA CA G1” which has signed the “*.vercara.com” certificate.

To create a certificate, you perform the following actions:

1. Generate a private key on the server that you want the certificate for.
2. Use the private key to generate a Certificate Signing Request or CSR.
3. Submit your CSR to the CA that you wish to use.
4. The CA validates that you own the domain and website.
5. The CA will sign the CSR and generate a certificate with a signature chain.
6. You deploy the signed certificate to your server and pair it with the private key.

For a long time, the IT industry did the TLS certificate requests and renewals manually. When you only need to do it once every 5 years (the expiration dates on the first certificates), it is not that much effort. A lot of organizations would just use TLS for their transactional websites and sensitive data.

Then, some things happened in 2013 and 2014 that made people realize that they should switch to using TLS for all their websites and that they should rotate certificates much more frequently:

• The Heartbleed vulnerability could have compromised private keys, so some organizations like CDNs and cloud WAF providers had to create new private keys and certificates for all customers.
• It was discovered that intelligence agencies were using cookies to track users’ browsing across multiple websites.
• Organizations continued to make the error of setting session cookies that are valid for both the HTTP and HTTPS versions of the site, making them able to be intercepted.
• The industry realized that there was a need for TLS certificate issue and renewal to become automated, faster, and more reliable. 

One of the outcomes of this was the creation of Let’s Encrypt, which is an open and free CA with automation plugins for many server platforms. It allows you to validate that you own a domain or website by either adding a TXT record to DNS or adding a file with a specified name and content to your web server. 

Most importantly, Let’s Encrypt has automation tools built around it so that a certificate can be issued and renewed every 3 months without any manual intervention aside from installing the tools. This has reduced the barriers to using TLS on every website.

Certificate details.

Certificates have several data fields inside of them that are visible.

• Canonical Name: This is the primary FQDN or hostname that the certificate is for.  Sometimes, this begins with a “*.” like the Vercara certificate which has the canonical name of “*.vercara.com”.  This is called a wildcard certificate and means that the certificate is valid for all FQDNs and subdomains inside of the domain. 
• Organization: The company that owns the site.
• Subject Alternate Names: These are other FQDNs or wildcard domains that the certificate is valid for.
• Not Before: The issue date of the certificate.
• Not After: The expiration date of the certificate.
• Issuer: The Certificate Authority that signed the certificate.

Evolving Encryption Standards

Throughout the years, SSL has evolved as different use cases and fixes to vulnerabilities have been incorporated. After version 3.0 of SSL, it changed its name to Transport Layer Security or TLS. The current version is TLS 1.3. 

Wikipedia lists the published and deprecated dates of the various incarnations of SSL and TLS.

SSL 1.0 Unpublished Unpublished

SSL 2.0 1995 Deprecated in 2011 (RFC 6176)

SSL 3.0 1996 Deprecated in 2015 (RFC 7568)

TLS 1.0 1999 Deprecated in 2021 (RFC 8996)

TLS 1.1 2006 Deprecated in 2021 (RFC 8996)

TLS 1.2 2008 In use since 2008

TLS 1.3 2018 In use since 2018

Configuring TLS.

TLS configuration is complicated. It has a lot of levers and switches that change because encryption is an online version of an arms race. As computers get faster and cryptographers build new attacks against cryptography and hashing, some algorithms lose their effectiveness. 

The good news is that modern web browsers and operating systems use automatic updates to keep themselves current. The bad news is that servers need to be updated periodically. A phenomenally good resource for understanding the Qualys SSL Labs, which tests all of the configurable items and tells you which options to modify, enable, or disable to better secure your server.

TLS algorithms and protocols.

TLS uses many algorithms for encryption and computing hash values (used for signatures and for validation checksums). It also uses a protocol for negotiation.  These are specified in the server settings and offered as part of the TLS handshake.

• Encryption algorithms: These specify which algorithms are used to encrypt data and can be either symmetric like AES or asymmetric like RSA or ECC.
• Hashing algorithms: These specify which algorithms, like SHA-256, are used to compute hashes, or digests of data.  These are used for signatures and other integrity checks.  
• Key exchange protocols: These are used in the TLS handshake to generate a session key, which is then used for encryption throughout the session.

Server name indicator.

Early SSL was built to be paranoid. Clients would validate the server certificate after they had received it. But servers could only have one certificate per IP address and service port. If you wanted to have different certificates on the same IP address, you would have to use a different port. 

Server Name Indication (SNI) is an addition to the TLS negotiation where the client adds the hostname that it wants to negotiate with. This allows servers to hold multiple certificates (and sites) on the same IP address and service port and leads to a larger amount of scalability across proxies and virtual hosts.

Perfect forward secrecy.

The TLS handshake requires a lot of computing power to complete.  As a result, 2 endpoints of a TLS connection reused the session key for subsequent sessions.  

However, if an attacker has access to that session key, they could decrypt all past and future sessions with it.  Perfect Forward Secrecy is a TLS capability, occasionally implemented as a configuration checkbox, that forces each session to create a new session key to limit the impact of a compromise to just one session.

Renegotiation.

In the middle of a TLS session, either endpoint can request a renegotiation for a new session key and set of algorithms.  In older versions of SSL, this process had vulnerabilities that have since been fixed.  However, older protocols still have configurable options for old, insecure renegotiation, disable renegotiation, and to enable only new, secure renegotiation.
HTTP Strict Transport Security (HSTS).

HSTS is a policy applied during the handshake which tells the client to come back in the future using only TLS and to not use unencrypted HTTP. HSTS is a policy that is sent from a website inside of an HTTP response header.

Strict-Transport-Security: max-age=300
Testing your TLS configuration.

Because TLS settings are complicated and because encryption algorithms are, The company Qualys built SSL Labs, which allows anybody to test the settings of a website. You can go to the site, put in a URL, and SSL Labs will test all of the options available and give you a letter grade. It will also show you the configuration items that you need to fix to get a better grade.
You can also test your settings, see what certificate is being used, etc., with a curl command, which will make a TLS handshake and show the HTTP request and response headers.

To most people, TLS and cryptography seem like black art. But throughout the course of this blog post, we have shown you what TLS is, how it evolved from SSL, how to use it, an overview of configuration settings, and how to test your own configuration.  

We’ve also discussed the importance of keeping your TLS version up to date, as well as staying on top of any vulnerabilities that may arise. By following these guidelines, you can ensure that your data and communication remain secure and protected from malicious attacks.

Embrace the future of secure online performance.

The future of secure online communications and robust web protection is here. With Vercara’s UltraDDoS Protect and UltraWAF, you gain not only the latest TLS 1.3 support for your proxy services but also the efficiency of a GraphQL API, ensuring your security measures are as advanced as the threats they protect against. 

Don’t leave your network security to chance. Take control with the enhanced visibility and operational efficiency our services offer by speaking to our sales team.