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."
Server Load (Score:1)
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: (Score:2)
Re: (Score:1)
You can see "delay" with https sites easily, no benchmarks required either. It's just the performance price paid for the (hopefully) added security.
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: (Score:2)
Re: (Score:2)
To be fair, the myth that SSL requires too much hardware is rooted on reality. It was once true, at the 90's.
That article has a big WTF:
That after explaining how SSL increases latency. And for supporting the stated fact that they didn't compromisse speed, the article comes with a pair of non-sequitours: Google uses chaches, and they optmized it to use much less memory.
(Just a note... Yes, SSL does increase latency, and no, it's not enough to n
Recommendation and ads (Score:2)
Yes, SSL does increase latency, and no, it's not enough to notice in a well written page. But if you go making a ton of different connections, it will be quite noticeable.
So what's the proper way to incorporate advertisements (which pay the writing and hosting bills) and recommendation widgets (which attract readers) "in a well written page"? Those tend to make "a ton of different connections".
Re: (Score:2)
Yes, SSL does increase latency, and no, it's not enough to notice in a well written page. But if you go making a ton of different connections, it will be quite noticeable.
So what's the proper way to incorporate advertisements (which pay the writing and hosting bills) and recommendation widgets (which attract readers) "in a well written page"? Those tend to make "a ton of different connections".
The "ton of different connections" is a two-edged sword. Obviously each needs to establish a session, and incurs a concurrency overhead. On the other hand requests can be overlepped past the "connection per server" limit you would get if they all came from the same site".
Re: (Score:2)
Most of the time, the proper way to incorporate those things is by assynchronous requests after the page loads.
Not everybody is lucky enough to get permission to do that with ads, but there is no reason to make the user wait those social network widgets to load before he can see your page.
Asynchronous iframe loading and reflows (Score:2)
Most of the time, the proper way to incorporate those things is by assynchronous requests after the page loads.
The implementation on (for example) Cracked.com of asynchronous requests to Facebook and other social networks has caused article pages to reflow several times, and when these reflows move the navigation buttons as they tend to do, I end up clicking links other than the one I intended to click.
Re: (Score:2)
I end up clicking links other than the one I intended to click.
On some sites that might be considered a feature to them.
Click fraud (Score:3)
Re: (Score:2)
You know you can fill the space taken by those widgets before loading them, right?
(I don't doubt any problem you may have had doing this, I'm just pointing it out.)
Re: (Score:2)
You know you can fill the space taken by those widgets before loading them, right?
I think one of the Facebook widgets has one height for an active Facebook user (in which case a bunch of recommendation options presumably pop up) and another height for someone who has no Facebook account (in which case "Sign up for Facebook to see what your friends like" appears). But I don't feel like signing up for a Facebook account and giving Facebook my cell phone number just to verify this. I haven't even dug into the Google+ account that I have.
Re: (Score:2)
Meaning that Googles own load takes 99% of the CPU load.
For people with less CPU intensive pages, the numbers will be different. For static pages, the load generated should be very low (if not, you're using the wrong server software), and that could easily be as low as the SSL overhead, meaning each will be 50% of the total load. In that case, switching to SSL means doubling the number of active CPUs.
I wouldn't have thought that gmail was that CPU-intensive on the front-end server. Based on AJAX front-ends I have worked on a lot of the work will be at the data retrieval level and the servers are more likely to be IO bound that CPU bound. It would be interesting to have some figures for the cpu load increase for static content. BTW one way to reduce the CPU load is to disable the 3DES protocol options. Newer protocols are more secure and use much less processor time.
Re: (Score:2)
Re: (Score:2)
Wait, do you really think that the same machines are handling google's SSL and google's content? Or amazon's, facebook's or any other massive web properties?
There may be SSL hardware to help the systems, but otherwise the SSL slowdown was always more about latency than CPU.
Re: (Score:2)
For people with less CPU intensive pages, the numbers will be different. For static pages, the load generated should be very low (if not, you're using the wrong server software), and that could easily be as low as the SSL overhead, meaning each will be 50% of the total load. In that case, switching to SSL means doubling the number of active CPUs.
For low-cpu static content CPU load is a non-issue. If you can saturate your pipe with 1% CPU, are you going to even notice that doubles to 2% CPU?
Not that it matters in the first place if you terminate SSL in your load balancer, as is commonly the case for non-financial stuff.
Re: (Score:1)
The problem with https isn't the server load per request but the additional server load due to not being able to cache resources as efficiently.
What breaks HTTP cache control? (Score:2)
Re: (Score:3)
Since the cache servers in between the client and the server can't cache the content for multiple users.
Oh, you thought only browser caches mattered.
Consider the still excellent though ancient http://www.ircache.net/ [ircache.net]
Who is operating these caching proxies? (Score:2)
Since the cache servers in between the client and the server
Who is operating these cache servers you're talking about?
Re: (Score:2)
Every company I do border gateway IT for has a border cache that filters all Internet access for the client. All connections to Internet servers go through it and reduce overall Internet bandwidth requirements, speed up actual content delivery for content accessed by multiple users (Windows Updates are a huge win) and allow the disallowing of specific sites or URIs by policy controls.
I also operate the same thing at home because well, I'm good at it and its worth it for the PS3+PC+Laptop+Tablet+SmartPhones
Run an internal CA for your border cache (Score:2)
If the end user is operating them, such as a business that provides caching for web sites viewed by users of its office network, the business can run an HTTPS caching proxy that uses a self-signed certificate, and everyone behind the firewall can install the business's root certificate.
Every company I do border gateway IT for has a border cache that filters all Internet access for the client.
That's what I was talking about. I don't see why you couldn't just run your own internal CA on a home or office network and use that as part of a man in the middle that caches HTTPS communications.
PS3+PC+Laptop+Tablet+SmartPhones+3DS
Perhaps the problem with running an internal CA happens with devices onto which only the manufacturer, not the device's owner, can install SSL root certificates. Is this the case with the Sony, Nintendo, and perhaps Apple devices that you mentioned?
Re:Server Load (Score:4, Interesting)
HTTPS-only is a hack from a lack of foresight and breaks caching.
What we need is a signature-only system for content that isn't private. There's no reason to encrypt the front page images on CNN to each user, but signing them so they are provably from CNN is valuable.
Re:Server Load (Score:5, Insightful)
HTTPS-only is a hack from a lack of foresight and breaks caching.
What we need is a signature-only system for content that isn't private.There's no reason to encrypt the front page images on CNN to each user, but signing them so they are provably from CNN is valuable.
More myths from the 90s - wrong on both counts. Privacy always matters. Maybe you live in a country where browing CNN won't land you in jail, but others aren't so lucky. And the only one who can't cache HTTPS traffic is the man-in-the-middle, which is sort of the point, really. Server-side there's plenty of hardware solutions to caching these days, it's just a question of where you terminate SSL. Client-side there's plenty of solutions as well, if you're running a home or office network and your users are willing to trust your cert (and thereby allow you to snoop).
Re: (Score:2)
Maybe you live in a country where browing CNN won't land you in jail, but others aren't so lucky.
"Honestly, I wasn't browsing at all, just making random https connections to cnn.com"...
Re: (Score:2)
More myths from the paranoid.
As someone who deals with security on a regular basis, I know that SSL doesn't fix any of the problems you're mentioning. In fact, my point is only invalidated in situations where the content itself is private to the user. Connection tracking negates your points entirely. Assuming any middle-man knowledge, I can already determine what sites you visit. Assuming any level of police state, I can just put a keyboard monitor on your USB input or a pinhole video monitor through yo
Re: (Score:2)
Why not? A cheap hosting provider is probably serving hundreds or thousands of sites from a single box, it makes sense to invest in an hardware solution that can be shared between all of them.
And you can get free certs, as long as you don't need extra validation.
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.
Re: (Score:2)
Whenever *anything* becomes popular -- whatever it is -- it seems to be ruined. It's such a sad fact.
In this case I think that the only practical way to break it would be to break TLS. This is something that many people have tried and with the current version failed (though you should avoid TLS 1.0 [theregister.co.uk].
I dunno (Score:2)
Does breaking the PKI consist of break TLS?
Also, with all the recent attacks against the PKI, I'm wondering how the you and the GP are concerned about people suddenly get interest in breaking HTTPS.
Re: (Score:2)
Does breaking the PKI consist of break TLS?
What "breaking of PKI" are you referring to? If you mean certificates generated with non-random keys [theverge.com] then this does not break TLS itself - though of course connections using weak certificates could be compromised. Ditto to certificates issues with short keys [eeye.com]. The compromised CAs [slashdot.org] then this could be seen as a weakness in the whole idea of centralised trusted CAs. While I like the idea of decentralised CAs [ieee.org] but think that it is not something to be rushed in to.
Re: (Score:2)
By "breaking the PKI" I mean basicaly compromissing certificates (directly or by compromissing CAs). So, yes, I'm refering to all that.
Those are not an attack on TLS itself, but for most effects, they are enough alike.
Re: (Score:3)
Here's the thing about crypto: it's never the math that's vulberable in the wild, it's the key distribution. That's always been the fundamental weakness of HTTPS: to easy to get a fake cert that will fool enough users. Heck, one attacker got a real Bank of America Cert by simply asking for a cert by email with forged headers.
CAs are the weak link. It doesn't matter whether the attack breaks whatever you consider "TLS itself": a bank vault with the worlds strongest door, but no sides or back is still not
Re: (Score:2)
SSL is "broken" not by any flaw in the protocol itself but by the flawed trust model used.
Go through mozilla's list of trusted root certificates and realise that every organisation on that list has the power to MITM you without generating a certificate warning (and the power to delegate that power to "intermediate certs" owned by third parties) . Then ask youself whether you really trust every organisation on that list not to MITM you and not to delegate signing powers to an organisation you do not trust.
Yo
Re: (Score:2)
The trust model would have worked a lot better if TLS had allowed multiple certificates of the same key. Major sites would make sure to use several different companies, and browser users could easily dump lousy TLS providers from the trusted roots without losing access to anything important. That would result in actual competition between TLS providers.
Re: (Score:1)
SSL (Score:5, Insightful)
Re: (Score:2)
Now, just gotta get SSL certificate system... secure and working.
That suggests the question, are there any CAs which have never [knowingly] been compromised?
Re: (Score:2)
That suggests the question, are there any CAs which have never [knowingly] been compromised?
Yes, my self-signed CA has never been compromised. Must disclose that has never been connected to the internet
.nu (Score:3)
For example, my bank offers online banking. Part of the login for said online banking is hosted on a .NU domain, a completely different country, which I don't even know the exact location of.
The IUSN Foundation of Niue, a tiny island country in the South Pacific, operates .NU as if it were a generic top-level domain like .COM. It has been popular in northern Europe, as "nu" means "now" in Swedish, Danish, and Dutch. (It also means "naked" in French.) McAfee reports that there was a time in 2007 when .nu was a hotbed of browser exploits, but it had been cleaned up by 2008. (source [wikipedia.org])
Re: (Score:2)
How did a banking company in my country get a certificate for a domain in a completely different country?
Same way they get a certificate for any other domain they legitimately own.
Just because a domain is in a foreign TLD doesn't mean they don't legitimately own it .
Re: (Score:2)
Define compromised. Do you only count those who have had intrusions into their networks, or also those who have given out certificates to people you don't trust?
I will (well, would) be happy if certs are (were) guaranteed to belong to someone who has received mail at a physical address. I don't care who they are, or where that is. I can decide what I think about it and accept the cert or not.
Re: (Score:1)
Re: (Score:2)
If you visit China and CNNIC decides to sign a *.yourbank.com certificate and MITM you, your browser wouldn't warn you. It'll show you the usual "secure" icons etc.
If you want a warning you can use firefox and certificate patrol. Or try Chrome's certificate pinning feature (not sure about the
Re: (Score:3)
What about all those SSL/TLS attacaks that came out a year ago, injection renegotiations etc.? Is SSL/TLS suddenly considered safe again? I thought they discovered serious issues in the concept.
Re: (Score:1)
Also, as more and more mundsne activities begin to go through SSL, I suspect it will provide more and more opportunity for users to grow accustomed to blindly accepting any and all invalid certificates, because they become conditioned to understand that the certificate warning is just a minor annoyance to dismiss as quickly as possible. (Even many theoretically "secure" websites that deal with actual sensitive information like credit card numbers are already conditioning people to accept invalid certificate
Re: (Score:1)
As long as it is based on the deeply logically flawed concept of "authority" [wikipedia.org], it can by definition never ever work.
Trust is a personal, individual thing. There can never ever be a thing that can be put into place as a global entity that everyone trusts. You can only decide who to trust *yourself*. You can never offload that to somebody else. Ever. I'm sorry, but there's a limit to how lazy of an ass one can be, before it starts to hurt.
So what we need is a web of trust system, with trust factors for every l
Re: (Score:1)
Re: (Score:2)
Free Class-1 SSL certificates are available from StartSSL
https://www.startssl.com/ [startssl.com]
Class-1 does not show the "Super secure secret key" icons with organization name because they are only email-verified, and you must used a personal name, but for small personal "hobby" websites they are still a lot better than a self signed certificate.
Class-2 certs are what supposedly need "verified", and show all the high security flags.
In practice however this verification is typically lacking depending on which cert author
Re: (Score:1)
Re: (Score:2)
Why not 301? The 302 status is for when you may change your head later, so the client better keep using the same address again and again. With 301 it should only use the new addred from now on.
Re: (Score:2)
Yes, I agree.
It was a honest question. I wanted to kow if I was overlooking something,
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: (Score:2)
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: (Score:3)
It's been a very long time since I've messed with web technologies at this level, so I'm tossing the following out merely for discussion purposes: What about changing the default browser to behavior so that instead of first trying the http: prefix, browsers try https: instead and then fall back to http: only when necessary? Would that work around the 'ssl stripping' issue?
Re: (Score:2)
That wouldn't help if someone in the middle is blocking the https site. You really need a way to tell the browser to not try the http site at all, even as a fall back. "Force fall back to insecure legacy mode" is a very common form of attack these days.
Re: (Score:2)
Because this lets the browser know and it remembers. So when I come along and spoof the MAC address of your gateway, and route the traffic to my own web server. I also need to run HTTPS or you will get a warning.
Additionally I am also going to need a certificate that your system will see as trusted and valid for the name you requested; which fortuitously remains at least a little hard in the typical case.
Without this I could pretty much count on you just typing amazon.com, rather than https://amazon.com/ [amazon.com]
How to easily add HTTPS to a website? (Score:2)
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.
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.
Re:How to easily add HTTPS to a website? (Score:4, Interesting)
SSL certificates are not the problem: https://cert.startcom.org/ [startcom.org]
The problem is that some browsers (mainly IE on XP) don't support SNI, so your website needs a dedicated IPv4.
If you manage the machine, you can get a VPS with a dedicated IP for almost nothing (I pay $3/month), but managed web hosting is another issue.
Re: (Score:2)
FYI: the https://cert.startcom.org/ [startcom.org] site is, as far as I know, somewhat deprecated. The more up-to-date URL is https://www.startssl.com/ [startssl.com]
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.
Re: (Score:1)
Thanks for all the details, however my website is hosted on a shared plan, meaning I practically zero control over the server setup. Is it a lost cause to try adding HTTPS? The host is Funio.com, if that's any help.
Re: (Score:2)
Funio uses Panelbox Control Panel... they searchable Knowledgebase, here is a quick search for "SSL Certificate" : https://kb.funio.com/search?search=ssl+certificate [funio.com]
Re: (Score:1)
Thank you for the link.
Re: (Score:2)
I would advocate not using HTTPs unless you have something to secure. That might be as simple as login if you have forum or something but if its all just non-interactive public information send it in the clear.
Do some googling there are some public CAs that will issue minimally verified certificates for personal sites free for at least the first year, so that might be an option. Otherwise if the user community is small enough you can use a self signed certificate. You'll need to contact them out of band
Re: (Score:2)
Re: (Score:1)
You gotta be kidding, if one of my vendor's gave me their root certificate to install on my machine, so I could securely connect to their site, I'd tell them to take a flying leap and get a real certificate. If I'm understanding right, your friend now has the ability to MITM his customers' SSL connections. We can argue about whether the root certificates preinstalled can be trusted, but I'm confident they're safer than the local Dunder Mifflin.
This should never have been needed (Score:3, Insightful)
This simple logic that when any SECURE page is requested then EVERYTHING must be accessed in secure mode (valid certificate required of every part if the main requested page has a valid certificate) should have been in there right from the beginning. So many of our security problems exists because people just DON'T THINK right at the beginning AND it takes so damn fscking long for the process to fix their stupidity.
Oh dear, another armchair expert (Score:2)
Tell me , if all this is so obvious, how come you didn't design it?
Besides which , when https was designed it was a pretty hefty burden on the server CPUs of the day so it was logical that only the parts that needed security would actually use https. Unfortunately hindsight always does have 20/20 vision and people who pretend its their own insight are usually full of it.
Re: (Score:2)
I'm not sure you get what the problem is, the problem is that end users often don't "request secure pages" explicitly, they either type a plain domain name with no protocol or they follow a link from another site (possiblly a search engine) so the initial request for a session is often over plain http.
If the users connection is not subject to MITM then they get redirected to the secure site but if a MITM is present then the MITM can make sure that doesn't happen by rewriting any links or redirects that poin
HTTPS is Great (Score:1)
RFC 6797 is not an "Internet Standard" (Score:1)
It's a proposed standard.