What is TLS (Transport Layer Security)?

TLS is a security protocol that provides privacy and data integrity for Internet communications. Implementing TLS is a standard practice for building secure web apps.

What is Transport Layer Security (TLS)?

Transport Layer Security, or TLS, is a widely adopted security protocol designed to facilitate privacy and data security for communications over the Internet. A primary use case of TLS is encrypting the communication between web applications and servers, such as web browsers loading a website. TLS can also be used to encrypt other communications such as email, messaging, and voice over IP (VoIP). In this article we will focus on the role of TLS in web application security.

TLS was proposed by the Internet Engineering Task Force (IETF), an international standards organization, and the first version of the protocol was published in 1999. The most recent version is TLS 1.3 which was published in 2018.

Transport Layer Security, the successor of the now-deprecated Secure Sockets Layer, is a cryptographic protocol designed to provide communications security over a computer network

What is TLS standard encryption?

TLS (standard encryption) Opportunistic TLS (STARTTLS) is a protocol that helps provide privacy between communicating applications and their users during email delivery. When a server and client communicate, TLS ensures that no third party can overhear or tamper with any messages.

How does TLS work?

For a website or application to use TLS, it must have a TLS certificate installed on its origin server (the certificate is also known as an “SSL Certificate” because of the naming confusion described above). A TLS certificate is issued by a certificate authority to the person or business that owns a domain. The certificate contains important information about who owns the domain, along with the server’s public key, both of which are important for validating the server’s identity.

A TLS connection is initiated using a sequence known as the Tls handshake When a user navigates to a website that uses TLS, the TLS handshake begins between the user’s device (also known as the client device) and the web server.

During the TLS handshake, the user’s device and the web server:

• Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
• Decide on which cipher suites (see below) they will use
• Authenticate the identity of the server using the server’s TLS certificate
• Generate session keys for encrypting messages between them after the handshake is complete

The TLS handshake establishes a cipher suite for each communication session. The cipher suite is a set of algorithms that specifies details such as which shared encryption keys or session keys, will be used for that particular session. TLS is able to set the matching session keys over an unencrypted channel thanks to a technology known as public key cryptography

The handshake also handles authentication, which usually consists of the server proving its identity to the client. This is done using public keys. Public keys are encryption keys that use one-way encryption, meaning that anyone with the public key can unscramble the data encrypted with the server’s private key to ensure its authenticity, but only the original sender can encrypt data with the private key. The server’s public key is part of its TLS certificate.

Once data is encrypted and authenticated, it is then signed with a message authentication code (MAC). The recipient can then verify the MAC to ensure the integrity of the data. This is kind of like the tamper-proof foil found on a bottle of aspirin; the consumer knows no one has tampered with their medicine because the foil is intact when they purchase it.

How does TLS affect web application performance?

The latest versions of TLS hardly impact web application performance at all.

Because of the complex process involved in setting up a TLS connection, some load time and computational power must be expended. The client and server must communicate back and forth several times before any data is transmitted, and that eats up precious milliseconds of load times for web applications, as well as some memory for both the client and the server.

However, there are technologies in place that help to mitigate potential latency created by the TLS handshake. One is TLS False Start, which lets the server and client start transmitting data before the TLS handshake is complete. Another technology to speed up TLS is TLS Session Resumption, which allows clients and servers that have previously communicated to use an abbreviated handshake.

These improvements have helped to make TLS a very fast protocol that should not noticeably affect load times. As for the computational costs associated with TLS, they are mostly negligible by today’s standards.

TLS 1.3, released in 2018, has made TLS even faster. TLS handshakes in TLS 1.3 only require one round trip (or back-and-forth communication) instead of two, shortening the process by a few milliseconds. When the user has connected to a website before, the TLS handshake has zero round trips, speeding it up still further.

What is the difference between TLS and SSL?

TLS evolved from a previous encryption protocol called Secure Sockets Layer (SSL), which was developed by Netscape. TLS version 1.0 actually began development as SSL version 3.1, but the name of the protocol was changed before publication in order to indicate that it was no longer associated with Netscape. Because of this history, the terms TLS and SSL are sometimes used interchangeably.

What is the difference between TLS and HTTPS?

HTTPS is an implementation of TLS encryption on top of the HTTP protocol, which is used by all websites as well as some other web services. Any website that uses HTTPS is therefore employing TLS encryption.

Why should businesses and web applications use the TLS protocol?

TLS encryption can help protect web applications from data breaches and other attacks. Additionally, TLS-protected HTTPS is quickly becoming a standard practice for websites. For example, the Google Chrome browser is cracking down on non HTTPS sites, and everyday Internet users are starting to become more wary of websites that do not feature the HTTPS padlock icon.

Transport Layer Security (TLS) is a widely used encryption protocol which enables parties to communicate securely over the internet. Through the use of certificates and Public Key Infrastructure (PKI), parties can identify each other through a trusted intermediary and establish encrypted tunnels for the secure transfer of information.

Using the TLS configuration guidelines outlined in this document will help strengthen encryption and authentication for web and email communications.

HOW TO IMPLEMENT TLS ON A WEBSITE

Encrypting web traffic

TLS and Hypertext Transfer Protocol Secure (HTTPS) are protocols that provide encryption and authentication to reassure people (herein referred to as users) that they are connecting to websites they intend to, and that their interactions are not able to be viewed or modified. These protocols are underpinned by cryptographic documents, known as certificates, which can authenticate the identity of websites.

All public-facing websites and Hypertext Transfer Protocol (HTTP)-enabled application programming interfaces (APIs) should use HTTPS to protect the confidentiality and integrity of website communications.

Encrypting email traffic

Opportunistic TLS can be used with the Simple Mail Transfer Protocol (SMTP) to protect the confidentiality and integrity of email. Using TLS and certificates, mail servers are able to authenticate one another and established encrypted communications before transferring email.

All mail servers should offer and use TLS to protect the confidentiality and integrity of email messages whenever possible.

Public Key Infrastructure

PKI arrangements are a key component of the assurance process that enables websites and mail servers to be authenticated. This is achieved by trusted Certificate Authorities (CAs) that vouch for server identities and attest the public key contained in a certificate belongs to the entity noted on the certificate.

How certificates, TLS, HTTPS and opportunistic TLS work

Certificates

Many internet protocols use X.509 [1] certificates to allow web browsers and systems to authenticate websites and servers using Public Key Cryptography [2]. For example, when a user attempts to access a HTTPS-enabled website, the web server sends the user’s web browser its public key contained in a certificate, and demonstrates it has the corresponding private key. The web browser then checks that the certificate was issued by a trusted CA, is valid and was issued to the domain of the website the user is accessing.

To receive a certificate, a server owner will need to apply to a CA and demonstrate that they have control over the domain for which they are requesting a certificate.

Certificate Authorities in web browsers

Common web browsers (e.g. Google Chrome, Firefox, Microsoft Edge and Safari) maintain their own list of trusted CAs. If a user visits a website which offers a certificate signed by a trusted CA, the web browser will accept the certificate without displaying a trust error. However, if a user visits a website which offers a certificate which is not signed by a trusted CA, the web browser will display an error message and refuse to make an encrypted connection until the user acknowledges the risk.

In practice, common web browsers’ trusted CAs are closely aligned. Further, when one web browser developer chooses to remove a trusted CA they will often coordinate with other web browser developers, or other web browser developers will shortly follow suit.

If the CA which has signed a website’s certificate is removed from a web browsers’ trusted CA list, the website’s users will begin to receive security error messages when attempting to connect to the website. This may cause some disruption and embarrassment to the organisation that owns the website until such time that the certificate is replaced.

When choosing a CA to issue a certificate for a website or HTTP-enabled API, organisations should consider the reputation and history of the CA, and other organisations that support or utilise the CA. Finally, the price of certificates is not an indicator of security, quality or longevity.

Certificate Authorities in mail servers

Mail servers support TLS via a mechanism known as opportunistic TLS. Under opportunistic TLS, any encryption is considered better than no encryption. Consequently, mail servers have historically accepted certificates which were expired, not signed by a trusted CA or didn’t match the name of the receiving mail server. However, new standards and improved server hygiene are beginning to challenge these practices.

As verification of certificates historically was not critical to email flow, mail servers may not have kept their internal list of trusted CAs up to date and aligned with a lists of well-known and trusted public CAs. Hence, mail server operators may find they need to implement processes to ensure the list of acceptable CAs on their mail servers are maintained.

In the absence of their own specific policy, mail server operators can choose one of the well-known web browsers and follow the web browser’s list of approved CAs as trusted root CAs.

TLS handshake process

The following is a simplified explanation of the TLS handshake process:

• the client and server agree on the cryptographic protocol (e.g. TLS 1.3) and cipher suite
• the client authenticates the server:
  • the server offers its certificate and proves that it holds the private key by signing a message which the client can verify using the public key contained in the certificate
  • the client verifies the identity of the server by checking the name of the server matches the name on the certificate
  • the client verifies that the certificate is valid by being in date, not revoked and issued by a CA which the client trusts
• the server and client exchange the symmetric key.

More information on the TLS handshake process is available from Cloudflare 

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is a feature of certain cipher suites that reduces the risk posed by compromised session keys. With PFS, individual sessions have unique session keys. As a result, a compromised session key cannot be used to decrypt other sessions. This means that attacks that rely on long-term storage of encrypted data become infeasible. Organisations should only use cipher suites that support PFS.

Secure renegotiation and client-initiated renegotiation

TLS 1.3 does not use renegotiation, however, if using TLS 1.2 or earlier, renegotiation may be required under certain circumstances. For example, when a session has expired but parties wish to send more data, a peer wants to change cipher suites or there is a need for the parties to perform authentication. Unfortunately renegotiation is susceptible to person-in-the-middle attacks [6]. For TLS 1.2 or earlier, secure renegotiation should be enabled to reduce susceptibility to person-in-the-middle attacks.

Client-initiated renegotiation, secure or otherwise, imposes a performance impact on web servers. A malicious client can send many renegotiation requests to consume server resources causing a Denial of Service [7]. For TLS 1.2 or earlier, client-initiated renegotiation should be disabled to prevent Denial of Service attacks. For more information on this subject see McAfee’s Tips for Securing SSL Renegotiation advice 

TLS compression

TLS compression was used to decrease the bandwidth of TLS communications. However, TLS compression has been found to inadvertently leak information, as illustrated by the CRIME exploit . TLS compression should be disabled.

Review TLS settings regularly

Best practice TLS settings and cipher suites change as new standards are released, computing power increases and security vulnerabilities are discovered. Organisations should review their TLS and cipher suite configurations annually, or whenever major security vulnerabilities are publically disclosed, to ensure that protection remains effective and in line with their customers’ expectations.

Hypertext Transfer Protocol Secure

HTTPS allows for secure communication across an untrusted network, reducing the ability of adversaries to monitor a user’s activity. Importantly, lack of HTTPS can erode trust in a website as common web browsers will alert users when visiting such websites  and again when they try to enter any information on such websites  It should also be noted that some web browsers will block content that is delivered over HTTP when connecting to a website over HTTPS 

All website content should be delivered using HTTPS, and any attempted access to resources using HTTP should be automatically redirected to the same resource over HTTPS. In addition, applications which make use of HTTP-enabled APIs should also use TLS to protect the confidentiality and integrity of information in transit.

There are many myths suggesting reasons for not using HTTPS. These are debunked at Does My Site Need HTTPS 

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps protect users. It achieves this by allowing web servers to tell web browsers that they should only interact with a web server over HTTPS. As such, web browsers will dynamically adjust any HTTP requests to HTTPS requests. HSTS also helps to protect against eavesdropping, person-in-the-middle attacks and active network attacks. Organisations should use HSTS to protect users’ confidentiality.

How to implement certificates, TLS and HTTPS

Which cipher suites and encryption methods to support

Picking strong cipher suites is important for users’ confidentiality. For the certificate signature algorithm, organisations are encouraged to use Elliptic Curve Digital Signature Algorithm (ECDSA) (256-bit or larger) or Rivest-Shamir-Adleman (RSA) (2048-bit or larger). If using elliptic curve cryptography, a curve from Federal Information Processing Standard 186-4 should be used.

Organisations should not use any cipher suite that uses the following algorithms as they have cryptographic weaknesses:

• Rivest Cipher 2
• Rivest Cipher 4
• Message-Digest 5
• Data Encryption Standard
• EXPORT
• NULL
• Secure Hash Algorithm 1
• Anonymous Diffie-Hellman
• Anonymous Elliptic Curve Diffie-Hellman.

Advice on acceptable cipher suites is outlined in Annex A.

Pick and install a certificate

As mentioned previously, the three certificate types provide the same level of security differing only in the level of assurance that a domain is owned by an organisation. Unless there is a business requirement for a higher assurance certificate, a free DV certificate should be used. In addition, using a CA that provides support for the Automated Certificate Management Environment (ACME) protocol  will enable support for HTTPS in a low maintenance manner.

Let’s Encrypt  is an example of a free DV certificate provider that supports ACME. A case study on setting up Let’s Encrypt with automatic renewal of certificates is provided at the end of this document. For more information on Let’s Encrypt see their Getting Started guide 

Automate renewal of certificate

Organisations should endeavour to automate certificate renewal. This can be done using a CA that supports the ACME protocol. Automation of certificate renewal minimises the risk that a website become insecure, or even inaccessible, if its certificate isn’t renewed in time 

Certbot  is a common ACME client that assists in obtaining and installing Let’s Encrypt certificates. It is simple, has comprehensive documentation and works on many platforms. Certbot can setup HTTP redirects, HSTS and load all resources through HTTPS. Alternatively, a list of alternate ACME clients is available on the Let’s Encrypt website 

Manual setup

If choosing to install a certificate manually, a Certificate Signing Request (CSR) will need to be created, the corresponding certificate will need to be ordered and then the certificate will need to be installed.

There are several resources available to assist with this process such as wikiHow’s text tutorial  and GlobalSign’s video tutorials:

• creating a CSR using Microsoft Management Console 
• creating a CSR in Microsoft IIS 10 
• creating a Java Key Store and generating a CSR 
• creating a CSR in Apache OpenSSL 
• installing a TLS certificate on Microsoft IIS 
• installing a TLS certificate on an Apache Tomcat server 
• installing a TLS certificate on an NGINX server 

The SSL Store also has advice on creating a CSR  and installing a TLS certificate 

Once manual setup has been completed, a TLS tester such as SSL Labs  can check the implementation.

Redirect HTTP requests

To ensure that users trying to access a website over HTTP are redirected to HTTPS, the web server’s or reverse proxy’s configuration should be edited. While syntax will differ between web server software, an example for Apache HTTP Server is shown below that causes an HTTP 301 redirect whenever the HTTP version of the website is requested.

• RewriteEngine On
• RewriteCond %{HTTPS} off
• RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Note, rewrite rules can be complex and it is important to test configurations before and after deployment.

Alternatively, redirection can be achieved in IIS by using the Uniform Resource Locator (URL) Rewrite Module  while Let’s Encrypt and Certbot can setup redirects automatically when a certificate is obtained.

Regardless of how HTTP to HTTPS redirects are implemented, websites should redirect to the HTTPS version of the website before redirecting elsewhere. For example, if redirecting requests for website.com.au to www.website.com.au, make sure to first redirect to the HTTPS version of website.com.au before redirecting to www.website.com.au. This is required for HSTS to operate correctly. Once the redirection configuration has been tested and confirmed, it is best to use a 301 (permanent) redirect as this typically improves search engine rankings.

Check for mixed content

While users may be able to access a website over HTTPS, parts of the website may still be retrieved using HTTP, such as images or embedded content. Most web browsers will block this mixed content. To check if a website has mixed content issues, either use Firefox’s Web Console to view individual pages  or use free online services such as Missing Padlock – SSL Checker 

Improving search engine optimisation

Moving a website to HTTPS will result in search engines treating the website as new, which could place it lower in search engine rankings. However, moving to HTTPS can also improve search engine rankings as many search engines place websites loaded over HTTPS higher in their search results  To minimise any negative impact on websites’ search engine optimisations, new HTTPS websites can be added and verified, for example, in the Google Search Console This will re-crawl the website and submit a new XML sitemap for the HTTPS version 

HSTS header

Even when HTTPS configurations and HTTP redirects are setup correctly, a HSTS header should still be used. This will ensure that for a specified period of time users will only be able to connect to a website using HTTPS. This is recommended to prevent adversaries from intercepting users’ initial HTTP requests. If using Let’s Encrypt and Certbot, sending HSTS headers can be setup automatically when obtaining a certificate.

Further information on HSTS implementation is available from GlobalSign 

Sign up for the HSTS Preload List

Signing up for the HSTS Preload List ensures that a user’s web browser will prevent HTTP requests being made to specified websites. This is different from a HSTS header as it occurs before a user has visited a website for the first time, provided they are using a web browser which supports the pre-load list. Thus, users are protected from attacks where an adversary prevents the HSTS header from being sent, such as in person-in-the-middle attacks.

Drop support for TLS 1.0 and TLS 1.1 immediately

All versions of TLS earlier than TLS 1.2, including SSL, are considered unsafe due to either having a flaw in the protocol itself or using vulnerable cipher suites that could leak confidential information. As such, support for versions of TLS earlier than TLS 1.2 will be dropped by Google [, Mozilla , Microsoft  and Apple starting in 2020. Importantly, if ongoing support for TLS 1.0 or TLS 1.1 is required for any reason, organisations are strongly encouraged to contact the Australian Cyber Security Centre (ACSC) to discuss possible risk mitigation strategies.

Be aware of TLS 1.2 limitations

TLS 1.2 or higher is required for HTTP Version 2 (HTTP/2), which provides significant performance improvements over HTTP and should be supported in order to provide a better user experience. However, due to deficiencies in TLS 1.2 and some of the included cipher suites, use of HTTP/2 with TLS 1.2 is limited. For example, HTTPS may fail if non-secure renegotiation and compression has not been disabled for TLS 1.2 in web server settings. Further advice on limitations associated with the use of TLS 1.2 are available from the HTTP/2 standard 

Begin transitioning from TLS 1.2 to TLS 1.3

As noted earlier, TLS 1.3 provides many security and performance benefits over TLS 1.2 and earlier versions. A simple way to disable older versions of TLS is to update web server configurations (e.g. an example configuration for Apache HTTP Server would be to include SSLProtocol TLSv1.3 in the configuration file). In some cases, web server software will need to be updated to the latest version to support TLS 1.3. In addition, if using a Content Distribution Network (CDN), enabling TLS 1.3 for external clients may only require ticking a box in configuration settings. The encryption configuration between any origin servers and the CDN may also require adjustment.

It is important to note though, as TLS is not backwards compatible, dropping support for TLS 1.2 will result in legacy web browsers being unable to access websites using TLS 1.3. In such cases it is recommended that users be encouraged to update their web browser to the latest version to receive support for TLS 1.3 and to protect their confidentiality. However, if transitioning from TLS 1.2 to TLS 1.3 is not possible in the short term, risks to users can be reduced by:

• removing support for compression
• disabling client-initiated renegotiation
• disabling renegotiation if the version of TLS does not support secure renegotiation
• only enabling secure ciphers.

The acceptable cipher suites for each version of TLS are found in Annex A.

Mozilla’s wiki provides advice on TLS configuration, including example configurations for security, compatibility and legacy systems  It also specifies what web browsers a particular configuration will be compatible with.

ADVANTAGES AND DISADVANTAGES OF TLS ENCRYPTION

Advantages of TLS

1. Data Integrity
The type of certificate that is exchanged between nodes is specified by the TLS. Therefore, TLS ensures that no any data that is being transmitted gets lost on its way. It will reach its destination safely.

2. Trustworthy
Whenever a site is secured by the TLS, it can be considered to be reliable. This is especially true for retailers and commercial websites. When the customers notice the green lock mark, they can be confident enough to conduct transactions.

3. Security
TLS is considered to be secure solution to transfer data on the web. Unlike in SSL where it uses Keyed Message Authentication, TLS uses a cryptographic method known as the HMAC (Key-Mashing Authentication Code). This method ensures that record cannot be tampered whiles its on transfer over the internet.

4. Malware Prevention
Some intruders can come up with malwares that tamper the communication between the web browser and the client. Through this intruders can gather confidential informations such as the credit card details and user login credentials. Using TLS these kinds of attacks are prevented. Thus, informations are not leaked over the network.

5. Granular Control
TLS provides more advanced and reactive alert system. Whenever there are problems during sessions and documents, users are alerted immediately. Hence, users can be benefited from Granular Control here.

Disadvantages of TLS

1. High Latency
Comparing to most of other secure encryption methods TLS provides higher latency. Whenever TLS is used, additional latency will be added to the site’s traffic.

2. MiM Attacks
Al though TLS is generally considered to be secure, some versions of TLS is still vulnerable to Man in the Middle Attacks. Besides this, other forms of cyber attacks such as SLOTH, POODLE and DROWN are also found to be susceptible.

3. Platform Support
Even though latest versions of TLS support many of the platforms, there are some versions such as TLS 1.3 that is only able to support few of the platforms. Popular Operating system provider Microsoft is facing difficulty with the implementation process.

4. Implementation Cost
Implementing a TLS certificate isn’t free, there are some costs involved. However due to the competition in the TLS industry, the cost of TLS certificate has been drastically reduced. The amount that needs to be paid depends upon the number of domains and sub domains. Apart from that it may also depend upon identity verification.

5. Network Complexity
Complexity in the network architecture is another major disadvantages of the TLS certificate. In this case automatically the network topology can also become complex leading to more fail overs. In order for handling this there should be proper network expert hired.

Drop your comment