Secure communication by TLS

Table of contents

Why Internet traffic can be intercepted and monitored
Security properties of HTTPS
TLS
TLS certificates
- Certificate trust levels
- Issues related with certificates
Attacks against PKI
Further reading
Moodle forum and feedback form

Why Internet traffic can be intercepted and monitored

Internet traffic is routed along the fastest route, and the network infrastructure is built such that the distances between continents are minimized. For example, UK has many submarine cables that connect the USA and Europe. Therefore, some countries are able to intercept and monitor huge amounts of the traffic that is passing through in transit. Some of these countries can be found by looking at the locations of the submarine cables, which can be seen from the following website: http://www.submarinecablemap.com/. For example, in 2013, it was revealed that UK is monitoring Internet traffic that is being transmitted between the USA and Europe: GCHQ taps fibre-optic cables for secret access to world's communications (2013)

Source: a screenshot of http://www.submarinecablemap.com/

Internet is built in a way that does not allow to predetermine the path of the data packet that is travelling from the source to the target node. The data packet is routed through the most optimal route, and therefore it is not easy to prevent the traffic from passing certain countries that monitor and save the traffic. From the submarine cables map, it can be seen that Estonia is connected with Finland and Sweden by submarine cables. Therefore, a large portion of the Internet traffic that enters Estonia is routed through Sweden, and we can not prevent the traffic from going through Sweden as there are fast links between Estonia and Sweden. This allows the Swedish intelligence agencies to monitor some traffic that comes from the eastern regions of Europe: Sweden helps the US spy on the Baltics: report (2013) and The Swedish Kings of Cyberwar (December 2016).

Countries and agencies that monitor Internet traffic can analyse all unencrypted packets, i.e., a significant volume of the traffic. When the contents of the packet are encrypted, then the monitoring party can get access only to the metadata, which contains the source IP, the target IP and the time when the packet was sent. From this metadata, it might be possible to find out which websites certain users are visiting and how much time they are spending to navigate on these webpages.

The websites / web services that provide an encrypted connection and ensure that the hosted data is encrypted usually have to follow the laws of the country where the data is located. Therefore, the corresponding state might use legal means to access the decryption keys and thus also access the encrypted data. In addition, the state might use legal means to require the companies to provide information about the client data. Such legal action is described in the following Guardian article: Secrets, lies and Snowden's email: why I was forced to shut down Lavabit (2014).

As a result of Snowden's leaks, the level of paranoia increased, and the industry started to focus on security. The main improvement that we can see is in the percentage of websites that support HTTPS. Before 2013 the usage of HTTPS was not common, however, by now it is getting difficult to find websites that do not use HTTPS. The aftermath of Snowden's leaks to security and cryptography is summarized in the following blog post: Looking back at the Snowden revelations (2019).

Security properties of HTTPS

How can the usage of HTTPS instead of HTTP enhance security? HTTPS improves security in several ways.

First, if a server is using a certificate that is signed by a trusted third party, then the user can be sure that the correct website was found. This helps against phishing attacks where the attacker creates a website that looks similar to a well-known website and lures users to enter personal information to the fake site in order to steal their identities.

Second, by using the key pair, the web server can negotiate with the browser and agree on a shared secret that is used to encrypt the following traffic between the browser and the web server. This prevents the attackers from listening to the contents of the communication. An attacker who taps the cables or listens to the traffic in an open WiFi network is now only able to read the metadata.

Third, in addition to the web server, the user might also have a key pair that could be used to identify himself / herself to the server. This is called mutual authentication. Mutual authentication is much more secure than logging in by using a password, and it is also more convenient as usually, the user does not have to remember the username and password. This functionality is commonly used in Estonia when a user logs into an online banking site by using an ID-card. In this case, the secret key that is kept inside the ID-card chip is used to authenticate the user to the server. To use a key pair that is not on a smart card, it is possible to load the private key into the browser and protect it with a password.

HTTPS provides:

confidentiality of the exchanged data
authentication of the server by a certificate
the integrity of the transmitted data and the authentication of the transmitted data
(authentication of the client)
(Perfect Forward secrecy aka PFS)

Technical properties of HTTPS:

the name of the protocol in the address bar is https://
by default port 443 is used
server must have a key pair
server must have a certificate
the protocol is either SSL or TLS

A more detailed description of the aforementioned security properties is given in the next section.

TLS

Actually, there is no separate HTTPS protocol, the name HTTPS stands for secure HTTP, and it means that HTTP protocol is encapsulated by a security layer. The encapsulation is created by Transport Layer Security (TLS) (or its predecessor Secure Socket Layer (SSL)) protocol.

There are several SSL and TLS versions, but the default one should be the newest TLS protocol as it is not known to have any major security vulnerabilities. A good overview of SSL/TLS history is given by SSL/TLS and PKI History.

TLS history

The first SSL protocol, SSL 1.0, was introduced in 1994 but was never publicly used as it contained a severe security issue. SSL 2.0 also contained security issues and was therefore replaced by SSL 3.0 in 1996. TLS 1.0 was created as an upgrade to SSL 3.0 to make the protocol more secure by using better cryptography. However, TLS 1.0 contained a functionality that allowed to downgrade the connection to SSL 3.0 if one of the communicating parties was not able to use TLS 1.0. In 2006 TLS 1.1 was created in order to protect against some cryptographic attacks that were possible against TLS 1.0. In 2008 TLS 1.2 was created in order to add new cryptographic cipher suites and to improve the security of the protocol in general. The specification for TLS 1.3 was finalized in 2018, and the adoption of TLS 1.3 is growing rapidly.

There used to be severe security issues related to supporting old and insecure SSL/TLS versions. Fortunately, modern browsers have stopped using these versions. Thus, even if a web site supports SSL3.0, it is not available to the majority of users. However, a few years back, this was not the case, and old and insecure SSL and TLS versions were supported by the majority of websites and browsers. Updated info about the usage of SSL/TLS versions can be found from SSL Pulse.

SSL / TLS versions

The following describes the different versions of SSL / TLS and their security properties:

SSL 2.0 - protocol contains several vulnerabilities, and therefore newer browsers have stopped supporting it.
SSL 3.0 - uses MD5 hash function for key derivation and MD5 is not considered to be secure anymore. In spite of this, some websites still support SSL 3.0. Probably some of these websites continue to do that in order to support older operating systems like Windows XP that are bundled with an old browser like Internet Explorer 6 that are not able to use TLS. In 2014 a new attack (The POODLE Attack and the End of SSL 3.0) was found against SSL 3.0, and it forced the major browsers to end the support for SSL 3.0 by the end of 2014 (Announcement by Mozilla). Thus, the security issues related to SSL3.0 are not relevant to users who are using modern browsers.
TLS 1.0 - contains a feature that allows downgrading the protocol to SSL 3.0 if one of the communicating parties is not using TLS 1.0. The option to downgrade the security level is a serious security issue, and it can be used to lower the security of the communication. In 2011 it was found that TLS 1.0 can be attacked; more information about the attack can be read from: BEAST attack. As the attack used a problem related to the block cipher CBC mode, then it was advised to move the connections to a stream cipher RC4. However, in 2013 it was found that RC4 contains a statistical weakness which allows revealing parts of the original message (i.e., to find information about the message by only using encrypted data). Therefore, it is not advised to use TLS 1.0 with RC4 and actually, it is not advised to use RC4 at all. The vendors of the mainstream browsers announced that they would end the support for TLS 1.0 and TLS 1.1 in 2020.
TLS 1.2 - is the most widespread version of TLS. Until 2018 it was the most secure TLS version. TLS 1.2 is still considered to provide a sufficient level of security.
TLS 1.3 was finalised in August 2018 and mandated Perfect Forward Secrecy. Among other things, TLS 1.3 discontinues support for several weak ciphers and their mode of operations that have been found to be weak.

You can check the security of your browser from the following website SSL/TLS Capabilities of Your Browser. It checks which SSL / TLS versions are supported by your browser. Similarly, the server's SSL/TLS configuration is tested by the SSL Server Test

Perfect forward secrecy aka PFS

As mentioned before, the web server needs to have a key pair in order to use HTTPS. It is essential that the secret key that is kept in the memory of the server is secured. If the server's secret key leaks, then it is possible to decrypt the encrypted HTTPS traffic. It is known that some countries monitor and save Internet traffic so that it might be possible to decrypt it in the future. One might guess what can happen if the secret key of the server leaks.

In order to prevent problems related to the leakage of the server's secret key, it is possible to use a temporary key pair to negotiate the session key. If a temporary key pair is generated and used for each session key negotiation, then the third party who gets access to the server's long time secret key is not able to decrypt the previously saved encrypted session data. When the attacker would somehow get access to the temporary secret key, then it would be possible only to decrypt the information that is related to a single session. The approach that uses temporary key pairs to negotiate session keys is called Perfect forward secrecy (PFS).

When PFS is used, it is not useful for the attacker to save the corresponding session data in the hope that a server key might leak and the data could be decrypted. Now, how can one check if PFS is used during the HTTPS connection? Unfortunately, the user is not able to enforce PFS; this has to be the choice of the server, i.e., the choice of the website. To check if PFS is used during the connection, one should check which algorithm is used to negotiate the session key. If the algorithm for session key negotiation is Diffie-Hellman Ephemeral (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), then PFS is used during the session. A more detailed overview of PFS can be accessed from: Perfect Forward Secrecy - An Introduction.

Task: Find a webpage that uses PFS.

Integrity of data

TLS is able to provide integrity of the transmitted data. This means that an attacker is not able to secretly modify TLS packets without the communicating parties finding out. Message authentication codes (MAC) are used to provide the integrity of the packets. The MAC algorithm gets the data and a key as input and outputs a short message authentication code. The same key is used to create and verify the message authentication code, and therefore the key has to be agreed upon before the communication is initialized. Therefore, MAC also provides the authenticity assurance. The following algorithms are used to create message authentication codes: HMAC-MD5, HMAC-SHA1, HMAC-SHA256/384, AEAD. HMAC-MD5 is supported by SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.2. HMAC-SHA1 is supported by SSL 3.0, TLS 1.0 and TLS 1.2. The other two algorithms are only supported by TLS 1.2.

Session negotiation

We haven't yet described how the TLS connection is initiated. General information about that can be found from the following post: How does SSL/TLS work?. Very specific and detailed information can be seen from: https://tls.ulfheim.net/.

The required abstract steps are illustrated in the following figure:

Source: http://www.cs.cmu.edu/~mmaass/tpm_tls/report.html

Additional materials

A detailed overview of HTTPS is given by the MIT course 6.858 Computer Systems Security. The following video lecture is made available through the MIT OpenCourseWare program. It is not compulsory to watch the video; it is extra material for the students who would like to get more information about SSL/TLS.

TLS certificates

Public key infrastructure is used to make secure connections between web browsers and web servers. In order to provide such an encrypted connection, the web server has to be configured to support TLS. First, web server needs a key pair, i.e., a public key and a secret key, but in addition, it needs a certificate that binds the domain of the webpage with the corresponding public key. It is important that the certificate would be signed by a trusted third party, i.e., by a CA, as otherwise, the web browsers will warn the users about the unknown identity of the website. The certificate of the CA is signed either by another trusted CA or by a root CA whose certificate is preloaded to the browser. Most web browsers contain at least 50 preloaded certificates of the root certificate authorities. This means that the browser trusts all certificates that are signed by these CA-s or by CA-s who have been indirectly trusted by the root CA. This, of course, is not a very good solution when we think about security. What happens when one of the trusted CA-s turns malicious or when one of these CA-s is hacked? In case the trusted CA gives out or is forced to give out a false certificate, then the browsers will automatically accept it.

Task: Which root certificates are trusted by default in your web browser? In Firefox this can be checked from: Preferences -> Security & Privacy -> Certificates -> View Certificates ...

Task: Identify the CA that signed the certificate of a web page that is using HTTPS. Check if the certificate is trusted. You can use any HTTPS website.

Firefox

So how can a user make sure that a website is using a secure connection? In Firefox, a padlock icon is shown on the left side of the address bar when HTTPS is used. The information about the connection, i.e., the encryption algorithms, the version of TLS, certificate information, can be seen by clicking on the padlock and then on the arrow on the right to find the “More Information” button.

Detailed information about the page and the certificate can be seen by clicking on the “More Information” button.

Task: Click on the “View Certificate” button to see more detailed information about the certificate and the trust relationships from the website certificate to the root certificate:

Google Chrome

Google Chrome also displays a padlock on the left side of the address bar if the connection is encrypted, i.e., when HTTPS is used. More detailed information about the certificate used to be seen by clicking on the padlock (or "(i)") icon and choosing "Certificate". Alternatively, certificate information can be seen by pressing F12 and choosing the "Security" tab. The following screenshot displays information about the connection to https://www.ut.ee.

By clicking on the button "View certificate" the detailed information is displayed.

Task: Navigate to https://courses.cs.ut.ee and click on the padlock icon. Then click on the “Certificate information” button in order to view detailed information about the courses.cs.ut.ee certificate.

Some certificates have more intermediary issuers (see the screenshot below). More information about the intermediate CA-s can be seen when clicking on the corresponding rows in the certificate window. If you are using Windows, the certificate information will be shown in a different format, but the contents are similar.

Certificate trust levels

There are three types of certificate types that a CA can issue, each providing a different trust level to the end-user. More information can be found from: https://www.globalsign.com/en/ssl-information-center/types-of-ssl-certificate/

Domain validation (DV) certificates are issued by only checking if the requester controls the domain that the certificate is going to be used for. This is usually either done by asking the requester to upload a specific randomly generated document to its web server or sending a validation code to an e-mail address on this domain. No other validation of the physical person or organization behind the domain name is done. Since this validation can be automated, there are some CA-s that issue DV certificates for free, e.g. Let's Encrypt initiative.

Organization Validation (OV) certificates are issued by doing some vetting of the requesting organization. Of course, domain control (as in DV certificates) is also validated.

Extended Validation (EV) are issued after a thorough vetting of the requesting organization. The issuing process of EV certificates is strictly regulated by the EV Guidelines. EV certificates were supposed to provide the highest level of trust and web browsers used to bring out the usage of such certificates by colouring (a part of) the address bar green and providing the organization name on the address bar. However, since 2019 the highlighting of EV certificates is no longer practised by mainstream browsers. One of the reasons is that the names on the organizations are not unique across different countries. Therefore, it was possible to request certificates for namesake companies that visually displayed the same company name on the URL bar. A news story was written in 2017 about this possibility: Nope, this isn’t the HTTPS-validated Stripe website you think it is.

Task: Visit an online banking website and check which type of certificate is used.

Issues related to certificates

Which risks appear when a website uses an expired certificate?
Which risks are related to self-signed certificates?

An example of how Google Chrome warns the user when a (self-signed) certificate is used.

The above screenshot describes how the browser warns the user about the unverified identity, i.e., one cannot be sure who operates the website when a self-signed certificate is used. A user should take the warnings seriously and proceed only if it can be made sure why a self-signed certificate is used. Sometimes, a website may use a self-signed certificate just to provide an encrypted connection to a small group of people, and in this case, it might not be necessary to get the certificate signed by a trusted third party.

The browser can show many different warnings about problematic certificates. These different warnings can be viewed by navigating to the following site: https://badssl.com/.

Attacks against PKI

How would it be possible to attack the PKI?

There have been several examples of attacks against PKIs:

Heartbleed vulnerability

In the April of 2014, a major vulnerability was found in the OpenSSL cryptography library. The vulnerability allowed an attacker to read the memory of a web server without the server noticing it. A good illustration of the vulnerability is given by XKCD in Heartbleed Explanation.

Source: Wikimedia

Why was this vulnerability so important? OpenSSL is one of the most widespread crypto libraries, which means that a large percentage of HTTPS sites are built using OpenSSL. More specifically, OpenSSL is used to implement TLS, which is a central part of HTTPS. Therefore, a vulnerability in OpenSSL can affect a large part of websites using HTTPS. The vulnerability itself was also pretty severe as among other information, the web servers keep their secret keys in the memory. Therefore, all websites that were affected by the vulnerability had to generate a new key pair and issue a new certificate as the old secret key might have been compromised.

However, if an affected server was using PFS for HTTPS connections, then the leakage of the server's long term private key would not have compromised the messages that were exchanged in the past. Thus, Heartbleed vulnerability illustrated why PFS is necessary, but fortunately, the support for PFS is common nowadays. Furthermore, PFS can also prevent the leakage of previously transmitted data in case the server's private key is compromised due to a cyber attack.

More information about the vulnerability can be found on its webpage http://heartbleed.com/.

Infoturve 2022/23 sügis