Hi, this is exactly my thought as I finished reading the article, which is very good until the last protocol explanation. I agree it was too quick, even for a “quick introduction”. Maybe the author had to leave in a hurry for an appointment. :)
Fortunately, this is the only protocol mentioned in the article that I know how it works, so I will explain it for you and for others that bump into this same problem.
HSTS´s main function is to protect the user against a protocol downgrade. First, let me go through some brief HTTPS basics.
The browser informs the user about the HTTPS status in two ways: positive and negative feedbacks.
Negative feedback is error browsers present when there is a problem in the TLS negotiation (HTTPS is HTTP protected by TLS, ot HTTP over TLS). For example, if the browser cannot authenticate or does not trust the digital certificate sent by the server, it will warn the user about the security risks of proceeding with the page visit.
Just a side note: there is a big debate if browser security warnings are really effective. I often tell my students that the average user, when presented with, for example, an unknown certificate authority browser warning, reads:
“blablablablablabla”. OK or CANCEL
User hits CANCEL. If nothing happens, he reloads and hits OK. Then the page loads, user is happy and the hacker is even happier.
An oldie but goodie study about this problem is “Crying Wolf: An Empirical Study of SSL Warning Effectiveness”. Google it if you are interested in learning more about this debate. End side note.
However, if everything is secure with the encrypted HTTPS connection, the browser presents the user with positive feedback, usually with a locked padlock near the address bar. The problem with this approach is that, in my opinion, most users would not notice a missing tiny padlock and the missing “s” in https if a hacker could redirect the user connection to a malicious fake site with no HTTPS enabled (so security protocol downgrade), usually as a result of a successful DNS poisoning attack. In this case, the user would be viewing web page that is exactly the same of the login page that he had always seen, only with the padlock and the micro “s” of “https” missing in the address bar (i.e. insted of displaying <padlock icon> https://facebook.com,, the address bar would show http://facebook.com).
The hacker cannot fake a https connection because he does not have a valid trusted digital certificate for the site, that´s why he had to avoid HTTPS. To make the matter even worse, hackers started using padlocks as favicon in the fake login page, making it VERY difficult for average users to spot the security problem.
This is the problem HSTS tries to solve: If Facebook knows that THERE IS NO HTTP version of the login page and WILL NOT BE ONE for the next 6 months, why should the browser let a connection to this page using an unsecure protocol?
So after this long introduction, let me explain how HSTS works.
As a premise, the user must have visited the legitimate HTTPS web page at least once in the recent past for the protocol to work. For example, once the browser reaches the HTTPS authenticated Facebook login page, the header “strict-transport-security: max-age=15552000” tells the browser that future requests to the domain must use ONLY HTTPS, and this directive must be enforced for the next 180 days (1555200 seconds). Obviously every time the user reaches the legitimate Facebook web page, the countdown is reset.
The conclusion is that, if our friendly neighborhood hacker poisons our poor victim DNS cache AFTER the user has visited the legitimate one, the browser MUST NOT let an HTTP connection go through for that domain and raise “Errors in Secure Transport Establishment” error. So the hacker´s only chance to lure this user is to get his hands on a trusted digital certificate for facebook.com, a feat orders of magnitude larger than the “script kiddie” DNS poisoning attack (but not impossible).
I hope that helps.
