EFF: How to Deploy HTTPS Correctly

https://www.eff.org/pages/how-deploy-https-correctly

by roder • 16 years ago

167 43 16 years ago

Revisor• 16 years ago

How would you handle the mixed content e.g. on a secure forum where some content sent by the users contains non-secure elements like images?

Semiapies• 16 years ago

Good question. If you mean specifically getting around the "some objects on this page are insecure" popups, a trick I've seen work is to cut off the http protocol portion of remote URLs, forcing them to look like "//www.example.com/to/file.jpg".

mrkurt2• 16 years ago

That's just a link that's relative to the protocol, the same way /blah is relative to the protocol + host. If you load an https page with inlined image links like that, it'll attempt to hit those images over https as well.

This is fine if you control the source and can handle both http/https serving. It doesn't help for content inlined by users, though, it'll just result in broken images.

bluesmoon3• 16 years ago

I believe hotmail handles this by proxying all external resources through their own HTTPS proxies.

jerf• 16 years ago

The mixed content is, fundamentally, not secured by HTTPS. If your page is important enough to warrant HTTPS in the first place, why are you allowing user-specified content into the mix anyhow? Users are not trustworthy, in general.

Bear in mind if you implement the proxy solution that others suggest, you aren't just serving the content, you're approving it. Blind proxying is not really sensible; again, if it were, then why are you HTTPS in the first place?

You're probably talking about images. You should probably let them upload images and host them yourself, at which point you should actually examine them somehow for security guarantees, such as "yes, this really is a JPG".

If this sounds a bit utopian or a bit hardnosed, what it really comes down to is, do you need HTTPS or not? I won't necessarily guarantee there's never an in-between answer but it's an awfully narrow space. And if the answer is "yes", well, follow through then.

bluedevil2k3• 16 years ago

They are correct that everyone should be using HTTPS. It costs as little as $12/year for the certificate, there's tons of tutorials on how to set it up in Apache, and there's only a couple of hundred sites in the world that need to be concerned with the performance hit (no, I doubt your blog is on that list).

_delirium• 16 years ago

Is there a good way to set up a Varnish or Squid-like caching proxy in front of HTTPS, or is that by design impossible? My fairly small sites don't generally have performance problems, but on the occasions that they get Slashdotted or on the front page of Reddit, the caching sure helps keep things moving.

Edit: It looks like the best way might be to do SSL between the client and nginx on my side acting as a reverse proxy, and then non-SSL internally on my side? Not sure how that setup compares to Varnish in general, but it's probably fine for my purposes.

bluesmoon3• 16 years ago

yep, you'd use something like nginx or apache traffic server and set that up to serve SSL.

One special case though, if you have multiple servers that serve your content load balanced, and if these servers are in different colocations, then you probably need to run any sync between them over SSL. Even if you do control the link between the two boxes, there's that off chance that your link goes down and the IP layer automatically routes traffic through a different set of routers.

cosmicray• 16 years ago

one nit to pick... there are still people stuck on slow connections. they are not always there by choice. In some cases the infrastructure is lagging the advances in content proliferation. when you get to dialup (the remaining ubiquitous and typically unlimited connectivity) running HTTPS where it is not needed is painful. v90 is only able to achieve compression on HTTP traffic. HTTPS traffic ends up moving at 40-50% the speed of HTTP traffic. While data security is certainly a valid objective, not everything moving as HTTPS needs to do so.

mike-cardwell6• 16 years ago

It's a trade off. Security vs performance. Personally, I think a small reduction in performance for a massive increase in security is a worthwhile exchange. Other people don't think so.

someone_here• 16 years ago

So I've been setting up all my sites as separate domain names, with things like code.domain.com and email.domain.com. Should I migrate these services, or is there a way to use HTTPS on many subdomains?

bluedevil2k3• 16 years ago

You can buy a global wildcard certificate that lets you create a domain name for *.domain.com. It costs like $199/year on GoDaddy I think, so you'd have to figure out if you think it would be worth it over getting individual certificates as $12/cert.

techiferous2• 16 years ago

"everyone should be using HTTPS"

Can't the argument be made that if you are a startup and have launched a product to test the market, it would take up too much developer time to think about https? Depending on the nature of the service, shouldn't you defer the extra effort until only after you've validated the product/market fit?

bluedevil2k3• 16 years ago

It's $12 and 15 minutes, not a big investment.

moshezadka• 16 years ago

Well, the contradictory argument can be made as well: If you're a start-up, and your early adopters get annoyed because someone made sure Firesheep works with your web site, and they're all getting pranked, they're going to decide they won't bother.

OTOH, I am writing this comment on an open wireless router.

On the gripping hand, nothing I put here is private, and if someone "pranks" me, I can just login again and delete offensive content. Karma isn't actually money...

btmorex• 16 years ago

https incurs a heavy performance penalty for everyone. Server load isn't the problem; a large increase in latency for every single connection is.

Your typical blog is probably going to suffer even more from enabling https globally when compared to major sites because not as much effort has been put into combining js, css, and images into sprites.

mootothemax• 16 years ago

I wish I could uprate you with more than one vote.

Seriously, https performance sucks from start to finish. If the average user doesn't care about https, but does care about performance, who are they going to go with - you or your faster competitor?

chrisbroadfoot• 16 years ago

The main detractor is inability for intermediate parties/networks to perform caching.

You can't cache something that's encrypted!

mike-cardwell6• 16 years ago

Google is currently working on something called "False Start" to reduce the number of roundtrips for an SSL connection to reduce latency. I believe there is already code in Chrome for this.

amalcon• 16 years ago

Or rather, everyone should be using HTTPS once XP dies. Until then, HTTPS breaks the shared hosting model.

mike-cardwell6• 16 years ago

Until XP or IPv4 dies. I'm guessing IPv4 will be around longer than XP though.

xiaomai• 16 years ago

One objection to using HTTPS for everything that I occasionally see is the loading of 3rd party scripts (facebook, ad networks, etc.). The premise of the argument against using HTTPS is that these 3rd party scripts are only accessible via HTTP, so users of old versions of IE would get scary popup warnings.

The other interesting item from this article was that you should always load resources via HTTPS, because a malicious script would have control over the DOM. It seems like there is a need for some facility in browsers to let pages delegate limited privileges to 3rd party scripts (maybe only able to read/write in a certain div or something?), so that users can still be confident that their connection is secure.

mrkurt2• 16 years ago

The real problem with mixed content is that you're compromising the security of SSL when you allow insecure resources on the page. If a page is otherwise secure and includes an insecure ad script call, for instance, it's relatively easy to hijack that javascript request and munge it to do whatever you want with the DOM and javascript-accessible cookies.

bluesmoon3• 16 years ago

If you have third party scripts on your page, you've already given away control of your page. A compromise on the third party's servers makes your site vulnerable as well. The safe thing to do is to fetch third party content server-side, massage it and then pass it on to your front end.

Naturally, this requires more work, and you'd probably end up getting rate limited since all API requests now come from a single IP (your server's) rather than each user's IP.

Alternately, you can iframe third party scripts (or depending on privacy requirements, you may need to double-iframe them), but this means that the script cannot directly interact with content on your page.

Trade-offs everywhere, which is why the architect of your system really needs to know what he or she is doing.

extension• 16 years ago

It seems like there is a need for some facility in browsers to let pages delegate limited privileges to 3rd party scripts (maybe only able to read/write in a certain div or something?), so that users can still be confident that their connection is secure.

There is most definately such a need and here is one attempt to address it:

http://code.google.com/p/google-caja/

It's a subset of JavaScript that can be sandboxed within other JavaScript, implemented as a lexical sanitizer. It's a huge hack, but I can't think of a better way to do this with existing technology.

What we really need is a replacement for JavaScript.

gokhan• 16 years ago

Correct me if I'm wrong but one problem is multiple domains on a single machine. Each SSL cert should correspond to a unique IP, and if you don't have wildcard SSL, that means every single domain and sub-domain.

Separating requests through host header / name-based virtual hosting is not supported on https. Startups discussed on HN will most probably own the machine, but it's problematic for small sites.

nodata• 16 years ago

You can with SNI. See here: http://en.wikipedia.org/wiki/Server_Name_Indication Check the support section too.

qjz• 16 years ago

Each SSL cert should correspond to a unique IP

Not true. SSL doesn't even really know what an IP address is, and it's quite possible to use a single SSL certificate on multiple IP addresses if the CN resolves to all of them (in round robin DNS, for example). If you mean that one IP address can only support a single SSL host, that's never been entirely true, as it has always been possible to support multiple SSL sites on a single IP using different ports (example.com:4443, for example). But you probably don't want to specify the port, which is addressed now by Server Name Indication (SNI): http://en.wikipedia.org/wiki/Server_Name_Indication

if you don't have wildcard SSL, that means every single domain and sub-domain

Some CAs now sometimes include a X509v3 Subject Alternative Name for DNS, so you might get www.example.com tossed in for free when you buy a cert for example.com. Unfortunately, not all clients support this field.

Separating requests through host header / name-based virtual hosting is not supported on https.

Once again, SNI is likely to fix this as soon as it is ubiquitously supported by browsers (already support is pretty good). However, note that name-based virtual hosting is a web server feature that really has nothing to do with SSL/TLS. It's quite possible to use it for HTTPS without any problems for at least a single domain. In fact, I do it for all of my secure sites to ensure that content cannot be requested using the bare IP address or a different domain that resolves to the same IP. This should really be a best practice, but there's a lot of shrill advice against it that is extremely outdated and needs to just die.

In any case, most of the problems you mention are solvable now, even for small sites. The real problem is in saying that obsolete insecure web clients will not be supported on your site, and that's getting easier to do every day.

tbrownaw2• 16 years ago

http://en.wikipedia.org/wiki/Server_Name_Indication#Client_s...

It's possible, but needs XP to die before it's practical.

timmorgan• 16 years ago

Wondering if one could practically implement a site with TLS+SNI for browsers that support it while letting browsers on XP and others that don't support it hit the site with HTTP unencrypted.

Of course, not appropriate for all sites, but definitely a step forward for sites holding out due to incomplete support.

jtchang• 16 years ago

Yes we already know HTTPS is secure.

I am sick of the articles saying enabling HTTPS is not going to impact performance "much".

Even without pulling out jmeter, apache bench, or load runner I can tell you just hitting F5 on a HTTPS page makes it take longer. It's the responsiveness. I don't really care if it takes 10% more CPU. CPU cycles are getting cheaper and cheaper. I do care a lot that it takes 50ms more.

Yes I know you can tweak things so that the HTTPS connection stays open and doesn't have to handshake everytime. But really, is there anyway to get that handshake down to something acceptable?

watchandwait• 16 years ago

Actually that's really interesting. How can you keep the https connection open?

maggit• 16 years ago

I don't know HTTPS, but it should be just HTTP over SSL. That means regular "Connection: keep-alive" should work just as well on HTTPS as HTTP. In both cases it will keep the connection alive, allowing several requests after one another.

mike-cardwell6• 16 years ago

Yeah. It's called False Start - http://www.imperialviolet.org/2010/09/05/blacklisting.html

BCGC• 16 years ago

This does not fly with our BAFHs. They need to know the content :)

It would be nice if we can have integrity and authenticity without confidentiality.

caf• 16 years ago

It'd be nice if HSTS also allowed you to limit the root CAs that should be signing your site's certificate.

EFF: How to Deploy HTTPS Correctly

Related Stories