Infoturve - Kursused - Arvutiteaduse instituut

Secure communication by HTTPS

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 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 USA and Europe: GCHQ taps fibre-optic cables for secret access to world's communications

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 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 the Internet traffic can analyse all unencrypted packets, i.e., a significant 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.

Security provided by HTTPS

How can the usage of HTTPS instead of HTTP enhance the security? HTTPS improves the 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 which 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

TLS and SSL

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 security vulnerabilities. A good overview of SSL/TLS history is given by SSL/TLS and PKI History.

The first SSL protocol SSL 1.0 was introduced in 1994 but it 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. TLS 1.3 specification is finalised, but it is not yet widely deployed.

More information about the SSL/TLS versions can be found in the next subsection. The statistics that are presented in that subsection are taken from a 2014 survey that analysed the top 1 million websites, i.e., the most popular websites that can be seen from (Alexa). The survey was unofficial and it studied how 451,470 websites were using SSL/TLS. The results of the survey can be found from the blog of Julien Vehent: SSL/TLS analysis of the Internet's top 1,000,000 websites.

Updated info about the usage of SSL/TLS versions can be found in 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 to support it. Still, by the previously mentioned survey about 18.9% of the popular websites continue to support SSL 2.0.
SSL 3.0 - uses MD5 hash function for key derivation and MD5 is not considered to be secure anymore. In spite of this about 99.6% of the popular websites support SSL 3.0 according to the previously mentioned survey. They continue to do that in order to support older operating system 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.
TLS 1.0 - contains a feature that allows to downgrade 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 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 with 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 which allows to reveal parts of the original message (i.e., to find information about the message by only using encrypted data). Therefore, it not advised to use TLS 1.0 with RC4 and actually it is not advised to use RC4 at all. However, according to the previously mentioned survey about 98.9% of the popular websites support TLS 1.0.
TLS 1.2 - is currently the most secure version of TLS. However, according to the survey only 33.2% of popular websites support TLS 1.2.
TLS 1.3 was finalised in August 2018 and mandates Perfect Forward Secrecy. Among other things, TLS 1.3 discontinues support for several ciphers and their mode of operations that have found to be weak.

As SSL 3.0 is considered to be insecure then browsers should not support the protocol. Ending the support for SSL 3.0 by the browsers would force the websites to update their certificates to support newer TLS versions which would increase the overall security level. Google, Mozilla and Microsoft stopped the support for SSL 3.0 in the end of 2014.

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. Simlarly, 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 very important that the secret key that is kept in the memory of the server is secured. If 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 with 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 with 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 therefore the data could be decrypted. Now, how can oneself 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.

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 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.

We haven't yet described how the encrypted channels is created by TLS. The required steps are illustrated on 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 an extra material for the students who would like to get more information about SSL/TLS.

HTTPS and certificates

Public key infrastructure is used to make secure connections between web browsers and web servers. In order to provide such encrypted connection the web server has to be configured to support HTTPS. 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 browser 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 -> Advanced -> Certificates -> View Certificates

Task: Identify the CA that signed the certificate used by 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 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.

Detailed information about 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://cs.cs.ut.ee.

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.

Notice that the trust chain used to be longer in the case of https://courses.cs.ut.ee compared to https://auth.ut.ee. 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 then the certificate information will be shown in a different format but the contents are similar.

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

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.

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 are 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 actual 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 are strictly regulated by the EV Guidelines. EV certificates provide the highest level of trust and web browsers bring out the usage of these certificates by coloring (a part of) the address bar green and providing the organization name on the address bar.

Problems related with certificates

Which risks appear when a website uses an expired certificate?
Which risks are related with 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 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, one big vulnerability in OpenSSL can affect a large part of the HTTPS websites. 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, a large portion of websites did not issue a new certificate or did it in a wrong way. This is illustrated by following figure.

Source

The websites that have not updated OpenSSL are still vulnerable to Heartbleed. More information about the vulnerability can be found on its webpage http://heartbleed.com/.

Infoturve 2018/19 sügis