HTTP Strict Transport Security Becomes Internet Standard 98
angry tapir writes "A Web security policy mechanism that promises to make HTTPS-enabled websites more resilient to various types of attacks has been approved and released as an Internet standard — but despite support from some high-profile websites, adoption elsewhere is still low. HTTP Strict Transport Security (HSTS) allows websites to declare themselves accessible only over HTTPS (HTTP Secure) and was designed to prevent hackers from forcing user connections over HTTP or abusing mistakes in HTTPS implementations to compromise content integrity."
Re:Server Load (Score:5, Informative)
Isn't the point of mixed web sites to lessen server load from https? I was always under the impression a mixed environment only using https when necessary was a better idea. Obvoiusly not mixing SSL and non on any single page like the article mentions, but wouldn't just be as effective to advocate for better SSL implementations?
No, mixed web sites were never recommended and many browsers will give a "mixed content" warning. The overhead isn't that high, Google commented after its switch to https only for gmail: [techie-buzz.com]
all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.
Re:Accessible only over HTTPS? Really? (Score:5, Informative)
Sure. Not that difficult. Then all the hacker has to do is spoof your site on HTTP and hope people don't notice the address bar isn't green. A number of people will fall for that one.
With HSTS, your brokerage will keep doing the redirect for non-HSTS browsers and for people who are visiting the site the first time. But once they've connected, the browser will note that it's a HSTS site. So next time it'll do the redirect in the browser, where a hacker can't interfere with it, and just do the secure HTTPS connection to the site.
HSTS also makes it impossible for people to click through security warnings, if a hacker is spoofing the HTTPS site with a forged (self-signed) certificate.
Re:Server Load (Score:5, Informative)
You can see "delay" with https sites easily, no benchmarks required either. It's just the performance price paid for the (hopefully) added security.
Yes there is added latency due to the handshake, though on my broadband connection I can't say that I can see it. Google has proposed and is implementing [imperialviolet.org] several standards to reduce this delay though. Of course the biggest reduction in the effects of latency came with "Keep Alive" which we have now had for years.
Re:I'm still not getting it (Score:5, Informative)
What's the difference between using this protocol and, uh, just disabling HTTP on your webserver? Or, from a user standpoint, just making sure you're using HTTPS via the URL?
Disabling HTTP can break things for users who manually enter URLs and forget the "https" or any number of other bad things. It's usually good form for a secure site to also run a plain-http server that redirects users to the secure site to avoid such confusion.
Only problem: ssl stripping. If a bad guy can intercept the connection between you and the secure site before the security has been negotiated then they can connect to the secure site in the normal way and present that page to you sans HTTPS and intercept anything you do there.
In short: browsers don't remember when a site "used to be secure but isn't today" and so don't present any warnings. This method tells the browser "For the next [time interval] you should only connect to me using a secure protocol. If not, the connection should fail." -- all that's required is that the user connect to the secure site at least once (e.g. from home or some other trusted network) to have the HSTS flag set for that site. If they try going to the coffee shop or some other place where there's a bad guy attempting ssl stripping then the connection will fail.
Re:How to easily add HTTPS to a website? (Score:5, Informative)
I can get the security side of things, but how do you do that easily and with zero budget? What about a personal website? I can't afford an SSL certificate for that.
NameCheap. sells Comodo and GeoTrust domain-validated SSL certs for ~$8-$10/year. Thawte certs are $30. Those are well within an "essentially nil" budget range for even the smallest of businesses.
StartSSL.com has domain-validated certs for free. Additional validation and features (like wildcards) are available at nominal cost.
All of the above-mentioned certs are widely trusted by browsers, both on computers and mobile devices.
Certificate costs haven't been an issue for several years now. The days of needing to get VeriSign certs at outrageous prices are gone (though VeriSign still charges outrageous prices, naturally).
Is there any "SSL/HTTPS For Dummies With No Cash" manual somewhere, keeping in mind that most people with websites are code monkeys, not network administrators.
Enabling SSL/TLS for your web server usually requires the addition of a few lines in a configuration file that tell the server (a) to use SSL and (b) the location of the server's private key, public key, and any intermediate certificates from the certificate authority. The details vary based on your server software, but it's usually quite easy and instructions can be found on Google. The steps are basically:
1. Generate an RSA public key (usually 2048 bits, though 4096 is not uncommon. 1024 bits is deprecated.).
2. Create a certificate signing request (CSR) for your site using that private key.
3. Submit the CSR to the certificate authority for signing.
4. Complete whatever verification process the CA requires (for domain-validated certs this usually requires that you click a link sent to the email address listed in your domain's whois record, while high-validation-level certs may involve you sending the CA various documents).
5. One you are verified, the CA signs your CSR and sends you the signed certificate. In many cases they also direct you to download the required intermediate certificate that you'll also need.
6. You save the private key (readable to root only, of course), signed certificate, and the intermediate certificate to your server and configure your server software appropriately (usually only a few lines of configuration changes).
At present, most HTTPS sites should have their own unique IP address, which rules out most "personal" hosting. This is because Internet Explorer on Windows XP (still a substantial chunk of users) does not handle HTTPS-enabled virtualhosts. Pretty much any other browser on any other system does support it.
Server Name Indication (Score:4, Informative)
And you can get free certs, as long as you don't need extra validation.
It's not the SSL certificate that's the cost bottleneck for the smallest sites; it's the dedicated IPv4 address. A lot of the cheapest use name-based virtual hosting, which requires the Server Name Indication (SNI) extension to SSL. Without SNI, the client can't see any certificate but the first on port 443 of a given address, which means the user will see a serious certificate error most of the time. Popular web browsers that lack SNI support include Internet Explorer for Windows XP, for which Microsoft is providing extended support until April 2014, and Android Browser on Android 2.x, which is on millions of Android phones and many inexpensive Android tablets.