When you are using the free Wi-Fi at your favorite restaurant or hotel after a conference. Have you noticed your Wi-Fi passwords are printed and never changed?
A hacker is staying at the same hotel. They monitor and listen to all wireless network connections.
“Packet sniffer” is a harmful tool used by hackers. A packet sniffer monitors a network’s data stream and sometimes executes tasks.
This hacker can intercept HTTP network traffic and attack any website that utilizes 301 redirects to convert to HTTPS. By using this approach, hackers can break SSL encryption and steal data or show a phony login gateway page.
Your website should use HTTP Strict Transport Security, not HTTPS. SSL certificates aren’t adequate security.
If you are new and looking for an easy way to set up an HTTPS certificate for your website then you can choose some of the best web hosting free trials to get started.
What Is HSTS?
HTTP Strict Transport Security, or HSTS, is a web server directive that tells user agents and browsers (via an initial response header) how to handle the web server connection.
This modifies the Strict-Transport-Security option. It needs HTTPS connections and ignores HTTP requests from scripts. HTTP Strict Transport Security (HSTS) is one of the security settings a web server or hosting provider can implement.
History Of HSTS
The idea for Strict Transport Security was inspired by a 2009 presentation by Moxie Marlinspike that illustrated how an adversarial network may deteriorate visitor connections and take advantage of unsafe redirection.
A lot of the most well-liked web browsers adopted it right once, and in 2012 it was eventually finalized as RFC 6797.
Even after a website turns on HTTPS, users may still try to connect using HTTP. Ex:
- Browsers automatically utilize http:// when a user puts “gsa.gov” into the address bar.
- It’s possible for a user to click on an outdated link that contains a http:// URL.
- The network of a user may be hostile and aggressively rewrite links from https:// to http://
Websites that prefer HTTPS will often continue wait for connections through HTTP in order to redirect users to the HTTPS URL.
This is because HTTP is still the more secure protocol. Take, for instance:
$ curl --head http://github.com HTTP/1.1 301 Moved Permanently Location: https://github.com/
How Does The Browser Handle HSTS?
The browser will remember the Strict-Transport-Security header when your site loads through HTTPS for the first time. By doing so, any future HTTP attempts to load the page will convert to HTTPS.
Strict-Transport-Security header expiration shows how long since an HTTP load attempt. After that, HTTP loads won’t convert to HTTPS automatically.
When the Strict-Transport-Security header is delivered, the browser updates the expiration date. This allows the website to refresh the data and prevents a premature timeout. Setting max-age to 0 (over an HTTPS connection) disables Strict Transport Security and allows HTTP access.
How To Preload Strict Transport Security?
An HTTP Strict Transport Security (HSTS) preload service is run by Google. If you adhere to the guidelines and correctly submit your domain, you can guarantee that only secure connections will be established between browsers and your domain.
Every browser uses the preload list, even though Google is the firm that runs the service. On the other hand, because it is not part of the HSTS standard, it should not be taken as official.
For a max-age of 1 year, the secure protocol HTTPS will be used for any and all existing and future subdomains. This prevents users from accessing URLs or subdomains that can only be delivered over the HTTP protocol.
Strict-Transport-Security: max-age=31536000; includeSubDomains
How to Implement HSTS for Your Website?
A Wildcard Certificate is required if you utilize subdomains to arrange your content if you wish to cover just HTTPS. However, you should be comparatively secure if your SSL certificate includes Domain Validation, Organization Validation, or Extended Validation. Check to see that they are installed and operating correctly.
The next phases of testing will put your web apps, user login, and session management to the test. Every five minutes, the HSTS will be let expire once. Tests should be carried out for an additional week and a month. Correct any problems that may occur during your deployment. Change max-age=xx. 604800 is one week, and 2592000 is one month. The preload should be appended once testing is complete.
Change the max-age option to 63072000 after you are assured that HSTS is working properly with your web apps. That will be two years in comparison. Make sure to include this in your preload submission because it is precisely what the Chromium Project is looking for!