10 ms·

Living with HTTPS

326 points by daniel02216 14y ago

rdl 14y ago
This was by a wide margin my favorite talk at HOPE this year. (and a great advertisement for using Chrome in secure settings where you need a web browser) The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.
- abraham 14y ago
  What do you mean by "Google being one of the main http-only JS resources"?
  - rdl 14y ago
    Adsense. Also I think GA was http only at some point.
    - abraham 14y ago
      Adsense can be an issue. At least it isn't a requirement for site functionality though. GA has had https support as long as I can remember.
sp332 14y ago
Moxie published a tool called SSLstrip http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/ here's a simple video demonstration https://www.youtube.com/watch?v=PmtkJKHFX5Q https://www.youtube.com/watch?v=PmtkJKHFX5Q
- woobles 14y ago
  Very interesting. Thanks!
isaacaggrey 14y ago
For users, HTTPS Everywhere is a must: https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere Also, by using DuckDuckGo [1] over HTTPS you get the same ruleset in HTTPS Everywhere [2] even if you don't have the extension installed. [1] https://duckduckgo.com/ https://duckduckgo.com/ [2] http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-implements-https-everywhere.html http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...
- harshreality 14y ago
  The chrome extension at least seems to break a lot of sites. They're not kidding when they say it's alpha. Pages include resources from https-everywhere'd domains and for whatever reason (mostly that the ssl versions of those resource urls aren't serving the same resources, or have broken certs) those resources fail to load. Within an hour of using it I'd seen it break 3 or 4 sites, so it got disabled. You can manually disable it for individual sites, if you recognize that it's the problem, but if some minor resource fails to load it might not be obvious.
  - mxxx 14y ago
    The reason the extension 'breaks sites' is because an alarming number of sites are happy to serve unsecure content all over the place. See the refernece to New York Times in the original article for an example.
- peterwwillis 14y ago
  And use HTTPS Finder to default to connecting via HTTPS before HTTP, then add a rule automatically to HTTPS Everywhere. https://addons.mozilla.org/en-US/firefox/addon/https-finder/ https://addons.mozilla.org/en-US/firefox/addon/https-finder/
tptacek 14y ago
This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice: * Enable HSTS * Don't link to HTTP:// javascript resources from HTTPS pages * Set the secure flag on cookies Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set. The only quibble I might have is the fatalism he has about mixed-security Javascript links. I'd go further than he does: when you source Javascript from a third party, you have leased your users security out to that third party. Don't like the way that sounds? Doesn't matter: it's a fact. Companies should radically scale back the number of third parties that they allow to "bug" their pages.
- deleted 14y ago
  [deleted]
- moonboots 14y ago
  A solution going forward to contain 3rd party javascript is HTML5 sandbox iframe. This allows declaring a whitelist of permissions 3rd party code should be granted. Only about 40% of browsers support this feature [1]. For unsupported browsers, the external javascript continues working without the security guarantees, so it's no worse than the situation now. [1] http://caniuse.com/#feat=iframe-sandbox http://caniuse.com/#feat=iframe-sandbox
  - rabidsnail 14y ago
    You can get most of the benefit now by registering a separate domain for the frames and taking advantage of the same-origin policy.
    - deleted 14y ago
      [deleted]
- rabidsnail 14y ago
  It's actually kind of a pain to enable HSTS because it makes you fix all the places where you're downgrading to HTTP. You should definitely do it if you care whether your users' sessions get hijacked, but it's not _just_ flipping a switch.
jenseng 14y ago
The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers? In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
- tptacek 14y ago
  No, that's not how STS works. Once the header is set, a MITM can't simply clear the header; the purpose of STS is to tell the browser to remember that the site is HTTPS-only. You are, obviously, vulnerable on first contact to a site, in that an attacker can prevent you from ever seeing the STS header. The point of STS is that attackers don't generally get to intercept your first contact with a site. Adam Langley, by the way, is one of Google's Chrome SSL/TLS/HTTPS people.
  - makmanalp 14y ago
    If you're in an oppressive country (say Syria), for example, is it a bad assumption that you're always being MITM'd, and unless you leave the country (not likely) EVERY first contact you make is already compromised? It's a tough chicken and egg problem.
    - tptacek 14y ago
      I'm really not sure what the point of this debate is. There are countries oppressive enough where I'd be worried that most of the computers in them are backdoored and keylogged. HSTS doesn't have anything to say about that either. Similarly: a country savvy enough to have a whole regime for ensuring they have custody of all transactions from first contact on probably isn't a country that offers safe access to browser binaries either, which kind of hurts the utility of baked-in SSL restrictions.
      - rdl 14y ago
        The thing which terrifies me is that most of the users in these "screwed" countries are probably using mobile phones connected to a state-owned PTT carrier (or a couple of licensed carriers), rather than laptops or desktops, at least for most organizing. True, a lot of the devices are purchased through the grey market unlocked vs. via the carrier, but it's not hard for a carrier to push OTA evil
agwa 14y ago
> There's a second collarary to this: attackers can set your HTTPS cookies too. If your app uses session ID cookies, then another implication of this is that attackers can set a user's session ID to a value they know, wait for the user to log in, and then use the session ID to hijack the logged-in session. To prevent this make sure you regenerate session IDs when logging a user in. (This isn't the only reason to regenerate session IDs on log in but it's a very compelling one.)
- tptacek 14y ago
  This is called "Session Fixation". Most modern frameworks prevent it, which is a reason to use your framework's session functionality rather than re-inventing it. Session fixation used to be a common problem. There were lots of J2EE applications which were not only fix-able, but which would allow an attacker to fix a session ID with a carefully crafted GET URL. It's much rarer now.
yorhel 14y ago
Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.
- rmc 14y ago
  You can get SSL certs that are valid for wild card subdomains, e.g. *.example.com
  - yorhel 14y ago
    Ah, I wasn't aware of that. Thanks!
  - agwa 14y ago
    Wildcard certs tend to be very expensive. If you only need two domains it's probably more cost-effective to just buy two certs. Edit: a downside of using separate certs is that you'll need to serve the respective sites from separate IP addresses, or rely on SNI [1] which isn't supported in older browsers. But if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right? [1] http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication
    - rmc 14y ago
      if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right? Not necessarily. People used to have different domains for images/css/js because browsers used to not want to download more than 2 things at the same time from the same domain name. (Back when the web was young and ugly, and bandwidth was scarce, this made sense). By having multiple domains (e.g. a.static.example.com, b.static.example.com etc.) on the same IP addres/server, you could trick browsers into downloading more in parallel and make your site seem faster. You didn't need multiple IPs for that. Now-a-days browsers have upped their limit from 2 to something like 8 → 16 or so, so it's less of a problem.
clarkevans 14y ago
I'm wondering if there could be an equivalent DNS entry that might help signal a site should only be accessed via SSL? Then you could possibly protect against initial access as well as returning users.
- agl 14y ago
  We can't do a blocking DNS lookup other than for A/AAAA records. About 5% of Chrome users cannot resolve TXT records because the network is filtering the DNS requests. (i.e. we know that the network is up and we're asking about a DNS name that we known exists, but we get a timeout.)
  - peterwwillis 14y ago
    Think this is a side-effect of EDNS0 being blocked, or UDP packets on port 53 bigger than 512 bytes being blocked?
    - agl 14y ago
      The response is 345 bytes and we used the OS DNS library to send the request, so I'm not sure whether EDNS0 would have been set.
  - sadpluto 14y ago
    In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I understand correctly this involves a lookup of a TYPE257 record. Given that only 5% can resolve TXT records, do you know what % of Chrome users can then resolve TYPE257 records? Digressing a bit further, wouldn't you say that even if HSTS is enabled and registered in the all the browsers' built-in list, you still have the problem of unencrypted DNS lookups? (Maybe this kind of attack is orders of magnitude harder to implement. I honestly don't know.) [1] http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
    - tptacek 14y ago
      No. The whole idea of HSTS is that you can never trust the DNS; you assume that's the most likely way an attacker is going to MITM her victims. HSTS tells the browser to remember that from that point on, all connections to SERVER.NAME have to happen under a TLS session with a valid cert.
DannoHung 14y ago
Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen. I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself.
- Flimm 14y ago
  Or fix the certificate issues. Don't train the staff to be blind to security warnings.
  - jarek 14y ago
    How exactly does "I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself." become "train the staff to be blind to security warnings"?
    - Flimm 14y ago
      If you know what you're doing, you'd know how to get around this limitation, with the --ignore-certificate-errors option for example. Any knowledgeable front-end or back-end developer would know how to find this out by doing a Google search. As long as you don't train the rest of the staff to do the same, that's fine. Now, why isn't the IT department fixing this security and usability problem?
    - tptacek 14y ago
      If you know what you're doing, get the CA=YES cert from your proxy and install it in your browser.
      - DannoHung 14y ago
        The cert itself was broken in the most recent case.
jenrzzz 14y ago
Google Cache mirror if anyone needs it: http://webcache.googleusercontent.com/search?q=cache:http%3A//www.imperialviolet.org/2012/07/19/hope9talk.html http://webcache.googleusercontent.com/search?q=cache:http%3A...
jastr 14y ago
HTTPSEverywhere is a firefox/chrome browser plugin, that will ensure connections that can be HTTPS are. It also does a good job preventing ssl stripping. https://www.eff.org/https-everywhere/ https://www.eff.org/https-everywhere/
jerhewet 14y ago
Does anyone have any recommendations for search terms I could use to put together a list of news stories / posts about known man-in-the-middle attacks that have occurred?
willfarrell 14y ago
SSL/TLS & Perfect Forward Secrecy - http://hackerne.ws/item?id=4267767 http://hackerne.ws/item?id=4267767
rogerbinns 14y ago
It mentions the free StartSSL certificates, as does their page. But what isn't clear is if the certificates are free to renew after a year (ie this is just a teaser). I currently use a self signed cert and certificate patrol, but apps (in particular Thunderbird) are becoming increasingly hostile to that.
- spindritf 14y ago
  > what isn't clear is if the certificates are free to renew after a year Yes, they are. StartSSL will even send you a reminder e-mail.
kmfrk 14y ago
Obligatory Django link: https://github.com/carljm/django-secure https://github.com/carljm/django-secure.
zobzu 14y ago
What I take out of this, beside things I knew of already (and most others as well) is: * Chrome wants to FORCE you to buy an SSL certificate. * The guy suggest getting one from StartSSL BUT those are crap for 2 reasons: you can only have ONE domain, else you have to pay. The TOS are horrible. So, dear imperialviolet, if you want me to use certificates that your company trusts (and by extension, your users), get up with it and make Google provide free, unlimited SSL certificates. Til then, no dice.
- spindritf 14y ago
  > you can only have ONE domain, else you have to pay It's one name per certificate (well, two: yourdomain.com and whatever.yourdomain.com) but you can order multiple certificates for multiple subdomains in the same or different domains at no charge.
- jaggederest 14y ago
  If you can't afford the $43/year for a Thawte starter cert, you have no business running a domain of your own. Seriously, less than $4 a month - that's going to be dwarfed by any sort of hosting you might be paying for. And it's only one domain per cert, so your entire argument is silly.
  - zokier 14y ago
    Dwarfed by hosting costs? There is tons of shared hosting options in the $50/year range which are quite usable for lots of purposes.
  - icebraining 14y ago
    My VPS runs an email server, seed box and hosts my personal landing page and a small organization's blog for 2€ / month. If you have a really small website, NearlyFreeSpeech is actually nearly free.
- dinkumthinkum 14y ago
  You know it's not Google that makes you buy SSL certs for security, right? As far as "no dice" ... um check out some tutorials on SSL ...
fijal 14y ago
For what is worth Libya owned a trusted CA (maybe still does), which means that MITM would happily work, because they can transfer all the certs to their own authority. I don't personally see how this is more secure than my self-signed certificate, which generates a warning that's these days very hard to avoid (even if I do know that the cert is fine)
- tptacek 14y ago
  Stipulate that it's true that Libya owned a browser-trusted CA, and compare situations: With signed certificates, Libya can MITM (unpinned) certificate-backed TLS sessions. With signed certificates, random people cannot MITM (any) certificate-backed TLS sessions. With self-signed certificates, Libya can MITM any TLS session. With self-signed certificates, random people can MITM any TLS session. I'm not seeing the argument you're making here.
timr 14y ago
Honest question, for those who have done it: what are the downsides of allowing your whole site to be accessed via SSL? Obviously, you need to be a bit more diligent about making asset urls protocol-relative (which can be a PITA across a large, dynamically generated site), but are there any other gotchas? Server load? Reduced cache-ability?
- deleted 14y ago
  [deleted]
- ceph_ 14y ago
  Without the proper tuning https will be significantly slower than http.
  - Zirro 14y ago
    Could you clarify what "proper tuning" entails?
    - ams6110 14y ago
      SSL/TLS is not computationally expensive any more[1] but there are some things that can help/hurt discussed in the footnote. [1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
- emmelaich 14y ago
  By protocol relative, are you referring to the // urls? (http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/) Because they wound't be so PITAish would they?
  - deleted 14y ago
    [deleted]
- pornel 14y ago
  You can have good cacheability—you just need to send explicit Cache-Control headers (which is a good idea anyway). If you don't do SSL properly (e.g. non-SSL-terminating load-balancer can break SSL session resuming by forwarding requests to different servers which don't share tickets) then you'll have lower front-end performance. webpagetest.org nicely shows connections including time spent on SSL negotiation, so you can use it to check your SSL overhead.
kodisha 14y ago
Any experience with CORS and https? Does it work properly? If i have www.mydomain.com with certificate A, and api.mydomain.com with a certificate B, can i make CORS call with javascript? (i know that if you try it with self signed cert, it will just drop the request)
- samt 14y ago
  Yes this works. Just get all the headers correct.
newman314 14y ago
If includeSubDomains is set for HSTS, does that mean that a cert for https://foo.com/ https://foo.com/ is required instead of https://www.foo.com/ https://www.foo.com/ in order to protect cookies set for foo.com and under? It's not clear to me from what docs that I have been able to find.
five_star 14y ago
I learned a lot about internet security here. Thanks a lot!
honestq 14y ago
honest question: why can't banks when customers open a new account, give them a card with 1. the bank's ip addresses (in each region) and 2. their printed public key (ssl or ssh format). and why doesn't the bank ask for a public key from each customer? in-person key exchange. no one even pays attention to the client side of ssl. how many of you use your own ssl certificates? you basically can't under the cert authorty scheme. it's a racket and no one is going to pay for these. and do the banks even care? they use tactics like cookies and follow-up emails to verify customers (hardware). and why does the bank have to be able to switch their ip address without telling anyone? what if the same was true for phone numbers? people would be like wtf? load balancing? c'mon. too difficult ot type? thnk about the trade-offs in security, all for the sake of not looking at a number? ipv4 is no longer than an area code and phone number. just tell people where your servers are and let them choose the one that is nearest. which incidentally, contrary to conventional wisdom, is not _always_ the one that will be the most responsive in the ever-changing state of the network. there's nothing more annoying than being subjected to using trial and error and you are not allowed to do any of the trial when the errors start coming. out of your control. what happened to the concept of "important numbers"? are we to believe you only need to remember "google.com" or "yourbank.com"? that's a security problem waiting to happen. second honest question: why does bank website need to embed links to third party reources and require that customers enable their browsers to access all these indiscriminantly (user doesn't get to choose) and to enable javascript? is javascript needed for security of a connect or to accomplish a financial transaction? because that's all i need from the bank website. i think we're past the point where customers need to be enticed to use the web to do things like banking and shopping. they're going to be forced to. so we can forgo the silly demonstrations and gratuitous use of javascript. save for "show HN". what we need is simplicity, reliability and security.
jordanthoms 14y ago
I have a rails 3.2 site, and I hadn't thought about this much aside from setting force_ssl to true. Turns out that automatically enables HSTS and secure cookies - cool!

326 points by daniel02216 14y ago

rdl 14y ago

This was by a wide margin my favorite talk at HOPE this year. (and a great advertisement for using Chrome in secure settings where you need a web browser) The irony of Google being one of the main http-only JS resources for a long time was kind of amusing, though.

abraham 14y ago
What do you mean by "Google being one of the main http-only JS resources"?
- rdl 14y ago
  Adsense. Also I think GA was http only at some point.
  - abraham 14y ago
    Adsense can be an issue. At least it isn't a requirement for site functionality though. GA has had https support as long as I can remember.

sp332 14y ago

Moxie published a tool called SSLstrip http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/ here's a simple video demonstration https://www.youtube.com/watch?v=PmtkJKHFX5Q https://www.youtube.com/watch?v=PmtkJKHFX5Q

woobles 14y ago
Very interesting. Thanks!

isaacaggrey 14y ago

For users, HTTPS Everywhere is a must: https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere Also, by using DuckDuckGo [1] over HTTPS you get the same ruleset in HTTPS Everywhere [2] even if you don't have the extension installed. [1] https://duckduckgo.com/ https://duckduckgo.com/ [2] http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-implements-https-everywhere.html http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...

harshreality 14y ago
The chrome extension at least seems to break a lot of sites. They're not kidding when they say it's alpha. Pages include resources from https-everywhere'd domains and for whatever reason (mostly that the ssl versions of those resource urls aren't serving the same resources, or have broken certs) those resources fail to load. Within an hour of using it I'd seen it break 3 or 4 sites, so it got disabled. You can manually disable it for individual sites, if you recognize that it's the problem, but if some minor resource fails to load it might not be obvious.
- mxxx 14y ago
  The reason the extension 'breaks sites' is because an alarming number of sites are happy to serve unsecure content all over the place. See the refernece to New York Times in the original article for an example.
peterwwillis 14y ago
And use HTTPS Finder to default to connecting via HTTPS before HTTP, then add a rule automatically to HTTPS Everywhere. https://addons.mozilla.org/en-US/firefox/addon/https-finder/ https://addons.mozilla.org/en-US/firefox/addon/https-finder/

tptacek 14y ago

This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice: * Enable HSTS * Don't link to HTTP:// javascript resources from HTTPS pages * Set the secure flag on cookies Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set. The only quibble I might have is the fatalism he has about mixed-security Javascript links. I'd go further than he does: when you source Javascript from a third party, you have leased your users security out to that third party. Don't like the way that sounds? Doesn't matter: it's a fact. Companies should radically scale back the number of third parties that they allow to "bug" their pages.

deleted 14y ago
[deleted]
moonboots 14y ago
A solution going forward to contain 3rd party javascript is HTML5 sandbox iframe. This allows declaring a whitelist of permissions 3rd party code should be granted. Only about 40% of browsers support this feature [1]. For unsupported browsers, the external javascript continues working without the security guarantees, so it's no worse than the situation now. [1] http://caniuse.com/#feat=iframe-sandbox http://caniuse.com/#feat=iframe-sandbox
- rabidsnail 14y ago
  You can get most of the benefit now by registering a separate domain for the frames and taking advantage of the same-origin policy.
  - deleted 14y ago
    [deleted]
rabidsnail 14y ago
It's actually kind of a pain to enable HSTS because it makes you fix all the places where you're downgrading to HTTP. You should definitely do it if you care whether your users' sessions get hijacked, but it's not _just_ flipping a switch.

jenseng 14y ago

The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers? In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.

tptacek 14y ago
No, that's not how STS works. Once the header is set, a MITM can't simply clear the header; the purpose of STS is to tell the browser to remember that the site is HTTPS-only. You are, obviously, vulnerable on first contact to a site, in that an attacker can prevent you from ever seeing the STS header. The point of STS is that attackers don't generally get to intercept your first contact with a site. Adam Langley, by the way, is one of Google's Chrome SSL/TLS/HTTPS people.
- makmanalp 14y ago
  If you're in an oppressive country (say Syria), for example, is it a bad assumption that you're always being MITM'd, and unless you leave the country (not likely) EVERY first contact you make is already compromised? It's a tough chicken and egg problem.
  - tptacek 14y ago
    I'm really not sure what the point of this debate is. There are countries oppressive enough where I'd be worried that most of the computers in them are backdoored and keylogged. HSTS doesn't have anything to say about that either. Similarly: a country savvy enough to have a whole regime for ensuring they have custody of all transactions from first contact on probably isn't a country that offers safe access to browser binaries either, which kind of hurts the utility of baked-in SSL restrictions.
    - rdl 14y ago
      The thing which terrifies me is that most of the users in these "screwed" countries are probably using mobile phones connected to a state-owned PTT carrier (or a couple of licensed carriers), rather than laptops or desktops, at least for most organizing. True, a lot of the devices are purchased through the grey market unlocked vs. via the carrier, but it's not hard for a carrier to push OTA evil

agwa 14y ago

> There's a second collarary to this: attackers can set your HTTPS cookies too. If your app uses session ID cookies, then another implication of this is that attackers can set a user's session ID to a value they know, wait for the user to log in, and then use the session ID to hijack the logged-in session. To prevent this make sure you regenerate session IDs when logging a user in. (This isn't the only reason to regenerate session IDs on log in but it's a very compelling one.)

tptacek 14y ago
This is called "Session Fixation". Most modern frameworks prevent it, which is a reason to use your framework's session functionality rather than re-inventing it. Session fixation used to be a common problem. There were lots of J2EE applications which were not only fix-able, but which would allow an attacker to fix a session ID with a carefully crafted GET URL. It's much rarer now.

yorhel 14y ago

Somewhat related question: It's fairly common for sites to have static files (images/css) served on a different (sub)domain. What are you supposed to do when the html content is being served on HTTPS? Should the static files be on HTTPS as well? If so, wouldn't it need a different certificate? Certificates are only valid for a single domain, after all.

rmc 14y ago
You can get SSL certs that are valid for wild card subdomains, e.g. *.example.com
- yorhel 14y ago
  Ah, I wasn't aware of that. Thanks!
- agwa 14y ago
  Wildcard certs tend to be very expensive. If you only need two domains it's probably more cost-effective to just buy two certs. Edit: a downside of using separate certs is that you'll need to serve the respective sites from separate IP addresses, or rely on SNI [1] which isn't supported in older browsers. But if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right? [1] http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication
  - rmc 14y ago
    if the use case is a separate domain for serving static files, that's probably hosted on a different server/IP address anyways, right? Not necessarily. People used to have different domains for images/css/js because browsers used to not want to download more than 2 things at the same time from the same domain name. (Back when the web was young and ugly, and bandwidth was scarce, this made sense). By having multiple domains (e.g. a.static.example.com, b.static.example.com etc.) on the same IP addres/server, you could trick browsers into downloading more in parallel and make your site seem faster. You didn't need multiple IPs for that. Now-a-days browsers have upped their limit from 2 to something like 8 → 16 or so, so it's less of a problem.

clarkevans 14y ago

I'm wondering if there could be an equivalent DNS entry that might help signal a site should only be accessed via SSL? Then you could possibly protect against initial access as well as returning users.

agl 14y ago
We can't do a blocking DNS lookup other than for A/AAAA records. About 5% of Chrome users cannot resolve TXT records because the network is filtering the DNS requests. (i.e. we know that the network is up and we're asking about a DNS name that we known exists, but we get a timeout.)
- peterwwillis 14y ago
  Think this is a side-effect of EDNS0 being blocked, or UDP packets on port 53 bigger than 512 bytes being blocked?
  - agl 14y ago
    The response is 345 bytes and we used the OS DNS library to send the request, so I'm not sure whether EDNS0 would have been set.
- sadpluto 14y ago
  In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I understand correctly this involves a lookup of a TYPE257 record. Given that only 5% can resolve TXT records, do you know what % of Chrome users can then resolve TYPE257 records? Digressing a bit further, wouldn't you say that even if HSTS is enabled and registered in the all the browsers' built-in list, you still have the problem of unencrypted DNS lookups? (Maybe this kind of attack is orders of magnitude harder to implement. I honestly don't know.) [1] http://www.imperialviolet.org/2011/06/16/dnssecchrome.html http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
  - tptacek 14y ago
    No. The whole idea of HSTS is that you can never trust the DNS; you assume that's the most likely way an attacker is going to MITM her victims. HSTS tells the browser to remember that from that point on, all connections to SERVER.NAME have to happen under a TLS session with a valid cert.

DannoHung 14y ago

Please for the love of god, if you're working at google and read this: Add a deeply set option to FORCIBLY enable that button in all situations where it might appear. We sometimes have certificate issues with our proxy server at my workplace and it makes Chrome practically unusable when they happen. I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself.

Flimm 14y ago
Or fix the certificate issues. Don't train the staff to be blind to security warnings.
- jarek 14y ago
  How exactly does "I know what I'm doing. I'll reset the option when the underlying issue is resolved, and overall it's a great feature for the browser, but I need to have the ability to be responsible for myself." become "train the staff to be blind to security warnings"?
  - Flimm 14y ago
    If you know what you're doing, you'd know how to get around this limitation, with the --ignore-certificate-errors option for example. Any knowledgeable front-end or back-end developer would know how to find this out by doing a Google search. As long as you don't train the rest of the staff to do the same, that's fine. Now, why isn't the IT department fixing this security and usability problem?
  - tptacek 14y ago
    If you know what you're doing, get the CA=YES cert from your proxy and install it in your browser.
    - DannoHung 14y ago
      The cert itself was broken in the most recent case.

jenrzzz 14y ago

Google Cache mirror if anyone needs it: http://webcache.googleusercontent.com/search?q=cache:http%3A//www.imperialviolet.org/2012/07/19/hope9talk.html http://webcache.googleusercontent.com/search?q=cache:http%3A...

jastr 14y ago

HTTPSEverywhere is a firefox/chrome browser plugin, that will ensure connections that can be HTTPS are. It also does a good job preventing ssl stripping. https://www.eff.org/https-everywhere/ https://www.eff.org/https-everywhere/

jerhewet 14y ago

Does anyone have any recommendations for search terms I could use to put together a list of news stories / posts about known man-in-the-middle attacks that have occurred?

willfarrell 14y ago

SSL/TLS & Perfect Forward Secrecy - http://hackerne.ws/item?id=4267767 http://hackerne.ws/item?id=4267767

rogerbinns 14y ago

It mentions the free StartSSL certificates, as does their page. But what isn't clear is if the certificates are free to renew after a year (ie this is just a teaser). I currently use a self signed cert and certificate patrol, but apps (in particular Thunderbird) are becoming increasingly hostile to that.

spindritf 14y ago
> what isn't clear is if the certificates are free to renew after a year Yes, they are. StartSSL will even send you a reminder e-mail.

kmfrk 14y ago

Obligatory Django link: https://github.com/carljm/django-secure https://github.com/carljm/django-secure.

zobzu 14y ago

What I take out of this, beside things I knew of already (and most others as well) is: * Chrome wants to FORCE you to buy an SSL certificate. * The guy suggest getting one from StartSSL BUT those are crap for 2 reasons: you can only have ONE domain, else you have to pay. The TOS are horrible. So, dear imperialviolet, if you want me to use certificates that your company trusts (and by extension, your users), get up with it and make Google provide free, unlimited SSL certificates. Til then, no dice.

spindritf 14y ago
> you can only have ONE domain, else you have to pay It's one name per certificate (well, two: yourdomain.com and whatever.yourdomain.com) but you can order multiple certificates for multiple subdomains in the same or different domains at no charge.
jaggederest 14y ago
If you can't afford the $43/year for a Thawte starter cert, you have no business running a domain of your own. Seriously, less than $4 a month - that's going to be dwarfed by any sort of hosting you might be paying for. And it's only one domain per cert, so your entire argument is silly.
- zokier 14y ago
  Dwarfed by hosting costs? There is tons of shared hosting options in the $50/year range which are quite usable for lots of purposes.
- icebraining 14y ago
  My VPS runs an email server, seed box and hosts my personal landing page and a small organization's blog for 2€ / month. If you have a really small website, NearlyFreeSpeech is actually nearly free.
dinkumthinkum 14y ago
You know it's not Google that makes you buy SSL certs for security, right? As far as "no dice" ... um check out some tutorials on SSL ...

fijal 14y ago

For what is worth Libya owned a trusted CA (maybe still does), which means that MITM would happily work, because they can transfer all the certs to their own authority. I don't personally see how this is more secure than my self-signed certificate, which generates a warning that's these days very hard to avoid (even if I do know that the cert is fine)

tptacek 14y ago
Stipulate that it's true that Libya owned a browser-trusted CA, and compare situations: With signed certificates, Libya can MITM (unpinned) certificate-backed TLS sessions. With signed certificates, random people cannot MITM (any) certificate-backed TLS sessions. With self-signed certificates, Libya can MITM any TLS session. With self-signed certificates, random people can MITM any TLS session. I'm not seeing the argument you're making here.

timr 14y ago

Honest question, for those who have done it: what are the downsides of allowing your whole site to be accessed via SSL? Obviously, you need to be a bit more diligent about making asset urls protocol-relative (which can be a PITA across a large, dynamically generated site), but are there any other gotchas? Server load? Reduced cache-ability?

deleted 14y ago
[deleted]
ceph_ 14y ago
Without the proper tuning https will be significantly slower than http.
- Zirro 14y ago
  Could you clarify what "proper tuning" entails?
  - ams6110 14y ago
    SSL/TLS is not computationally expensive any more[1] but there are some things that can help/hurt discussed in the footnote. [1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
emmelaich 14y ago
By protocol relative, are you referring to the // urls? (http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/) Because they wound't be so PITAish would they?
- deleted 14y ago
  [deleted]
pornel 14y ago
You can have good cacheability—you just need to send explicit Cache-Control headers (which is a good idea anyway). If you don't do SSL properly (e.g. non-SSL-terminating load-balancer can break SSL session resuming by forwarding requests to different servers which don't share tickets) then you'll have lower front-end performance. webpagetest.org nicely shows connections including time spent on SSL negotiation, so you can use it to check your SSL overhead.

kodisha 14y ago

Any experience with CORS and https? Does it work properly? If i have www.mydomain.com with certificate A, and api.mydomain.com with a certificate B, can i make CORS call with javascript? (i know that if you try it with self signed cert, it will just drop the request)

samt 14y ago
Yes this works. Just get all the headers correct.

newman314 14y ago

If includeSubDomains is set for HSTS, does that mean that a cert for https://foo.com/ https://foo.com/ is required instead of https://www.foo.com/ https://www.foo.com/ in order to protect cookies set for foo.com and under? It's not clear to me from what docs that I have been able to find.

five_star 14y ago

I learned a lot about internet security here. Thanks a lot!

honestq 14y ago

honest question: why can't banks when customers open a new account, give them a card with 1. the bank's ip addresses (in each region) and 2. their printed public key (ssl or ssh format). and why doesn't the bank ask for a public key from each customer? in-person key exchange. no one even pays attention to the client side of ssl. how many of you use your own ssl certificates? you basically can't under the cert authorty scheme. it's a racket and no one is going to pay for these. and do the banks even care? they use tactics like cookies and follow-up emails to verify customers (hardware). and why does the bank have to be able to switch their ip address without telling anyone? what if the same was true for phone numbers? people would be like wtf? load balancing? c'mon. too difficult ot type? thnk about the trade-offs in security, all for the sake of not looking at a number? ipv4 is no longer than an area code and phone number. just tell people where your servers are and let them choose the one that is nearest. which incidentally, contrary to conventional wisdom, is not _always_ the one that will be the most responsive in the ever-changing state of the network. there's nothing more annoying than being subjected to using trial and error and you are not allowed to do any of the trial when the errors start coming. out of your control. what happened to the concept of "important numbers"? are we to believe you only need to remember "google.com" or "yourbank.com"? that's a security problem waiting to happen. second honest question: why does bank website need to embed links to third party reources and require that customers enable their browsers to access all these indiscriminantly (user doesn't get to choose) and to enable javascript? is javascript needed for security of a connect or to accomplish a financial transaction? because that's all i need from the bank website. i think we're past the point where customers need to be enticed to use the web to do things like banking and shopping. they're going to be forced to. so we can forgo the silly demonstrations and gratuitous use of javascript. save for "show HN". what we need is simplicity, reliability and security.

jordanthoms 14y ago

I have a rails 3.2 site, and I hadn't thought about this much aside from setting force_ssl to true. Turns out that automatically enables HSTS and secure cookies - cool!