6 ms·

EFF: How to Deploy HTTPS Correctly

167 points by roder 16y ago

deleted 16y ago
[deleted]
Revisor 16y 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 16y 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".
  - mrkurt 16y 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.
- bluesmoon 16y ago
  I believe hotmail handles this by proxying all external resources through their own HTTPS proxies.
- jerf 16y 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.
bluedevil2k 16y 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 16y 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.
  - bluesmoon 16y 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 16y 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.
xiaomai 16y 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.
- mrkurt 16y 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.
- bluesmoon 16y 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 16y 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/ 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 16y 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 16y ago
  You can with SNI. See here: http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication Check the support section too.
- qjz 16y 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 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.
jtchang 16y 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 16y ago
  Actually that's really interesting. How can you keep the https connection open?
  - maggit 16y 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-cardwell 16y ago
  Yeah. It's called False Start - http://www.imperialviolet.org/2010/09/05/blacklisting.html http://www.imperialviolet.org/2010/09/05/blacklisting.html
BCGC 16y 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 16y ago
It'd be nice if HSTS also allowed you to limit the root CAs that should be signing your site's certificate.

167 points by roder 16y ago

deleted 16y ago

[deleted]

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 16y 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".
- mrkurt 16y 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.
bluesmoon 16y ago
I believe hotmail handles this by proxying all external resources through their own HTTPS proxies.
jerf 16y 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.

bluedevil2k 16y 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 16y 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.
- bluesmoon 16y 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 16y 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.

xiaomai 16y 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.

mrkurt 16y 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.
bluesmoon 16y 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 16y 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/ 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 16y 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 16y ago
You can with SNI. See here: http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication Check the support section too.
qjz 16y 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 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.

jtchang 16y 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 16y ago
Actually that's really interesting. How can you keep the https connection open?
- maggit 16y 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-cardwell 16y ago
Yeah. It's called False Start - http://www.imperialviolet.org/2010/09/05/blacklisting.html http://www.imperialviolet.org/2010/09/05/blacklisting.html

BCGC 16y 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 16y ago

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