Posted
by
samzenpus
on Friday November 23, 2012 @09:05AM
from the way-it-is dept.

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."

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?

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?

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.

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.

Yeah, I can't say I really notice a huge difference when switching to SSL on the page load front either. Being a self-centered asshole, I was more worried about CPU time. More CPU time means server upgrades which means more time working and less time pretending to work.

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:

So did Google just compromise speed for security? Definitely not.

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

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".

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".

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.

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.

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.

Except that, to properly serve via SSL and not have a mixed content warning, you need to serve everything via SSL from the same domain. That means, that you also need to serve static files via SSL. If you have high CPU load on your server that serves static files, you are doing something wrong. Then again, where you server static files the CPU should not be the bottleneck, thus adding SSL may actually not hurt. But as always, it depends on your use case. Adding SSL is not a free operation; but it may be suf

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.

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.

If the operator of the web site is operating them, the caching load balancer can implement all SSL, and the web servers can communicate with the proxy through HTTP.

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

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?

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.

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).

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

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.

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].

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

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.

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.

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])

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.

That seems like a good idea to me. And when view the certificate in your browser, the browser should be able to connect to the certificate authority, and you should be able to get a bio of the certificate, check if is revoked, and write and view complaints on certificate.

Unfortunately that's not relevant for security given the way most browsers behave by default. All the attacker needs is ONE compromised/cooperative CA out of the dozens of CAs your browser recognizes or will recognize.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

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

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

Parent is right in that we are ultimately at the mercy of our browser, operating system, and the individuals and tools that built this software. On the other hand I think grandparent is correct as much as it would be a good idea to spread the trust and also a good idea to have an audit of the certificate authority and its certificates. Just like when you purchase a product, you see what other individuals and organizations say about that product before buying it. The same should be of certificates and the

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

Verification of SSL server certificate is not enough to protect your account. There needs to be additional 2 way authentication, so both sides can prove they know the username password/key to the account. So if the certificate does get compromised, you will still be protected from man in the middle.
Here is one such protocol:
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol [wikipedia.org]

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.

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.

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?

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.

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]

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.

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.

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

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 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.

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.

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, if you can afford to pay the fees. I see tons of potential for redirect 301 to HTTPS, becasue it will screw the existing links on the Internet and the unaware businesses would love to pay for maintenance of their broken websites.