Secure Transition to HTTPS Using HSTS
By the introduction of HTTPS, it was presumed that this protocol is able to fully guarantee the security of communications on the internet. However, its previous version, i.e. HTTP, was left unattended. Recognizing the security vulnerability of transitioning a URL from HTTP to HTTPS, scholars decided to find a method to restrict communications to HTTPS, and the method was called HSTS.
Imagine that you are sitting at your favorite café in a pleasant evening, intend to enjoy to the utmost from the silence and calmness of that atmosphere, and carry out your jobs whose major part should be done online. As usual, you connect to the café WiFi and use the free internet that it offers you. Everything seems to be perfect and there is no problem.
However, while you are busy doing your jobs in the peaceful atmosphere of the café and unaware of the security weakness of that public WiFi network, a person in the adjacent building is sitting in his room, and, through the software he has freely downloaded from the internet, is smoothly intercepting the traffic (or in other words, information) being sent and received over the café WiFi network.
It may come to your mind that “what problems occur when he intercepts traffic; or what information he can obtain by traffic interception, which may put me at risk”.
Before answering these questions, it is better to clarify what happens when we use different browsers and software applications that get connected to the internet and send and receive data.
Hypertext Transfer Protocol (HTTP) is a protocol responsible of transferring information (including texts, images, videos, etc.) among devices over the World Wide Web (www).
When you search for a page in your browser or open it directly by pasting a URL, you are actually using HTTP. It is worth mentioning that this protocol is not the only one used by browsers. Almost all devices connecting to the internet use this protocol to transfer their data.
The protocol initial plan was first proposed by Tim Berners-Lee in 1991, known as HTTP 0.9. However, it was just a preliminary plan needing to be worked on. In 1996, IETF HTTP Working Group (HTTP-WG) registered the first RFC related to this protocol, called HTTP 1.0, as RFC 1945. Still it could not become a standard RFC. Six months later, in 1997, the standard RFC of this protocol, called HTTP 1.1, was finally registered as RFC 2068.
While HTTP was being developed, a serious security weakness emerged: no data encryption method was devised for this protocol, meaning that all data communicated by this protocol over the internet between two systems could be easily intercepted by a third party.
For example, imagine that you have opened the bank payment page in your browser and entered your bank card information and you are waiting for the transaction to be completed. While opening the payment page, an HTTP communication was established between your browser and the bank web server. Now if a third party intercepts the HTTP traffic between you and the bank server, he will access all your bank card information and abuse them.
Emergence of HTTPS
The solution to HTTP insecurity was a secure version called Hypertext Transfer Protocol Secure (HTTPS). Using another protocol called Transport Layer Security (TLS), it establishes a secure communication between clients and servers.
To ensure communications, TLS uses Public Key Infrastructure (PKI). In sum, to establish a secure communication between two systems, the protocol utilizes three components:
- Mutual Authentication
- Digital signature to maintain the Integrity of communication
- Encryption of information to protect privacy
Apart from how TLS works, what you can finally observe in your browser in the final step, in order to make sure that the communication between your browser and the website you are visiting is of HTTPS type, is to insert https:// instead of http:// at the beginning of the URL.
Considering the above explanations and paying attention to the URLs recently visited, you are now probably thinking that “most of the websites support HTTPS. So if a person intercepts the WiFi network traffic of café, he cannot access my information!”
Sad to say that there is still the probability of intercepting your information by that cool-headed person sitting in the adjacent building.
SSL Certificate Sniffing
An SSL certificate should be first provided for a website to support HTTPS. TLS/SSL certificates are issued by authorities responsible of issuing digital certificates (Certification Authority (CA)). In general, in a communication between two or more parties (e.g. between browsers and web servers), the certification authority plays the role of a third party who is considered trusted by the communicators. The entity guarantees that the information exchanged in this communication (which includes the public key and the identity of the person sending the key) is safe and secure. CA guarantees this security by signing the SSL certificate.
After receiving the SSL certificate, the communication between the users and the website can be based on HTTPS. Accordingly, the site admin defines for the web server that when it receives the request of access to website based on HTTP, it asks from the requester a communication based on HTTPS by sending a code and the URL with https immediately in its reply. The code that the website sends in this case is HTTP code 301 or redirect 301.
For better understanding, see the following figure:
- The user enters http://example.com in his browser, and the browser on TCP port 80 (used by HTTP) sends the website access request to the server.
- By receiving the request from the browser, the server immediately sends the browser the HTTP code 301 with http://example.com.
- By receiving this message from the server, the browser sends to the server a request to access http://example.com on port 443 (the port specific to HTTPS).
- By receiving such request, the server sends the browser a certificate containing the digital signature.
- By acquiring the certificate and comparing it with its valid certification authorities, the browser verifies the certificate. Following the verification, communication is established between the browser and the web server, and the user accesses the site information.
Now imagine what happens if at the beginning of the process, where communication between the browser and server is based on HTTP, a third party, who is intercepting the information, gets involved between the browser and server, and the code 301 sent by the server is received by the sniffer instead of the user’s browser, and the sniffer, instead of sending the code to the user’s browser, sends its fake page which is similar to the main website and based on HTTP, to the user’s browser.
For better understanding, see the following figure:
The same as before, the user’s browser sends a request to the server to access http://example.com. However, here a sniffer is intercepting the communication. As soon as the request is sent by the user’s browser, the sniffer gets involved and disconnects the communication between the browser and the server. When the server replies the request by redirect 301, instead of sending the message to the user’s browser, the sniffer sends the information of his fake page to the browser, and the user will not be aware of the page falsification and what is going on.
The sniffer sends the request of http://example.com to the server and acquires the SSL certificate. On the other hand, the user uninformed of everything enters his information (including bank card information, passwords of social networks, emails, etc.) on the sniffer’s fake page and the sniffer gets access to that information. Now that the sniffer has both the SSL certificate and the user’s information, he can easily abuse them.
Such an attack is called SSL stripping attack which is a type of man-in-the-middle attacks. This security vulnerability was first discovered by Moxie Marlinspike, which led to the emergence of a mechanism known as HSTS.
Secure transfer to HTTPS using HTTP Strict Transport Security (HSTS)
Once the SSL stripping vulnerability was discovered, it was presumed that HTTPS connection is not always secure as imagined. Therefore, a solution to this security weakness should be presented.
As RFC 6797, a protocol called HTTP Strict Transport Security (HSTS) was released in 2012. It enables the websites to be available only through secure communications (i.e. HTTPS connection), and on the other hand, the users to communicate only with HTTPS-enabled websites.
To this end, the protocol uses its specific header called Strict-Transport-Security. By sending the HSTS header for the HSTS-supporting browser, the web server specifies HTTPS-enabled connection for future communications. Thus, even if the browser enters a URL with http, it immediately changes the URL into https before establishing any communication, and then connects to the web server through HTTPS. Moreover, if it detects the link as insecure, it shows an error message to the user and blocks the access to that website.
In the message sent by the server to the browser, which contains HSTS header, a time period is determined in second (max-age field). It defines the duration of the HSTS policy validity. For instance, an HSTS header may appear as follows:
Strict-Transport-Security: max-age=15768000; includeSubDomains
The header specifies for the browser that the HSTS policy is valid for approximately six months. It means that in the next six months, whenever the browser intends to access the website, it should communicate through HTTPS. On the other hand, the last phrase indicates that in addition to the main domain of the website, the law is applied for all of its subdomains.
You are now probably thinking that “the security problem of HTTPS communications is resolved as such and there is nothing to worry about!”. However, HSTS has also several weaknesses.
Firstly, the browser receives the HSTS header when it is communicating with the server for the first time. Therefore, in this initial communication between the browser and the server, HTTP-enabled connection is still probable.
Secondly, as previously stated, HSTS policy is valid for a specific time period determined by max-age. Therefore, it is very likely that the browser uses HTTP for its first communication with the server after the policy expires.
A list known as HSTS Preload was used to solve these two problems.
HSTS Preload List
HSTS Preload List is a list of domain names supporting HSTS, whose communication must be based on HTTPS. The list is hardcoded in the software of HSTS-supporting browsers, meaning that the list is added to part of the main codes of the browser software and can be changed or deleted in no circumstance (except changing the main codes of the software or when an update is released by the browser developers).
Therefore, if an HSTS domain is entered in HSTS-supporting browsers even without https or even without having previous visits to that website and receiving an HSTS header, communication is immediately established through HTTPS.
Currently, the following browsers support HSTS:
- Google Chrome v0.211.0 onwards
- Firefox v4 onwards
- Safari from OS X Mavericks onwards
- Opera v12 onwards
- Internet Explorer 11
- Microsoft Edge
- BlackBerry 10 operating system’s browser
ArvanCloud and HSTS
You can add your website to the Preload List, if meeting the following requirements:
- Possessing a valid certificate
- Transferring all HTTP traffics to HTTPS
- Availability of all subdomains only through HTTPS
- Sending a proper header for users for their settings
You do not need to worry. ArvanCloud automatically fulfills all of them for you. You just need to announce your domain name to Google.
The present article attempted to explain why HSTS mechanism is created and how it generally works. Although HTTPS is an encryption method to establish secure communication among systems, implementation of mechanisms such as HSTS can ensure the necessity of doing so. Obviously, the more websites are added to the HSTS Preload List, the more the security of the whole internet will increase.