Live data from Hacker News

Living with HTTPS

imperialviolet.org

81–90 of 132 posts

Re: Living with HTTPS

#81
post #48

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 fo…

It's very straightforward for a proxy to have its own CA=YES certificate and mint/sign certs for every HTTPS site the proxy sees on the fly. If you have a corporate proxy that is intercepting HTTPS traffic, that is what it should be doing. Then, the proxy makes its certificate available to users, you download it, and add it to your CA certs via the UI that browsers provide for that; HTTPS magically appears to work ag…

So the proxy server acts as a forced man in the middle? This has to be one of the most atrocious things I have ever experienced. Forcing a man in the middle is insane especially in a large company where there may well be a lack in competency.

HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.

Re: Living with HTTPS

#82
post #31

Earlier quoted context omitted.

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

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…

Well, now that DANE is nearly an RFC I should change Chrome to use it rather than the TYPE257 records.

But the important point is that DNSSEC stapled certificates don't need the browser to perform any extra DNS lookups. The certificate itself contains the DNSSEC information and signatures. Since DNSSEC is signed the data can come over any channel; it doesn't have to be port 53.

Unencrypted DNS still leaks the hostname that you're visiting - that's true. However, the destination IP address probably leaks the same information and, if not, we sent the hostname in the clear at the beginning of the TLS handshake! (That's SNI, it allows SSL virtual hosting.)

Re: Living with HTTPS

#83
post #68

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 wi…

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.

Dwarfed by hosting costs? There is tons of shared hosting options in the $50/year range which are quite usable for lots of purposes.

Re: Living with HTTPS

#84
post #82

Earlier quoted context omitted.

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…

Well, now that DANE is nearly an RFC I should change Chrome to use it rather than the TYPE257 records. But the important point is that DNSSEC stapled certificates don't need the browser to perform any extra DNS lookups. The certificate itself contains the DNSSEC information and signatures. Since DNSSEC is signed the data can come over any channel; it doesn't have to be port 53. Unencrypted DNS still leaks the hostnam…

Thanks for answering! What I don't understand is that, given that your starting point is "two computers talking over a malicious network", doesn't the current state of affairs of (unencrypted)DNS mean that it's game over from the outset? That is, if the network is malicious, that MITM could very refer you to an invalid IP address the moment you first try to resolve, say, mail.google.com.

Please don't take this as an argument. I just want to know where I'm wrong! I just can't get over the idea of pushing at the (justifiably) paranoid level for HTTPS while we still have plain-text DNS... even with DNSSEC!

Wish request: Your thoughts on http://news.ycombinator.com/item?id=4268461.

Re: Living with HTTPS

#85
post #63

Earlier quoted context omitted.

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.

Thanks for your answer! I'm more confused by the moment about DNSSEC et al: isn't the DNSSEC-based validation of HTTPS referred to above supposed to get rid of CAs in the future? That wouldn't make sense even with DNSSEC considering that the information is not encrypted? (Right?) I hope you don't take this as "hijacking", but I'd be most curious about what you and other security experts think about Paul Vixie's "Whit…

There is a splinter group of people- who- want- DNSSEC who argue that DNSSEC will obviate the need for CAs. There reasoning, distilled, is that DNSSEC is itself a PKI, with the roots signing TLDs and TLDS signing domains and so on. Since the core architecture purpose of certificates is to "break the tie" between an attacker's public key and the real site's public key, and since DNSSEC zones could serve the same purpose, by housing a DNSSEC-signed public key, blammo, no more Verisign.

There are a bunch of problems with this idea. Most of the ones that spring to my mind are problems with DNSSEC in general: its brittleness, the reliability problems I think it's going to cause, the things it does that actually diminish the security of the DNS... but the big point relevant here is: DNSSEC replaces a market of CAs with a baked- into- the- Internet fiat authority. If DNSSEC had replaced SSL CA's in the mid '00s, Ghaddafi's Libya would have been Bit.ly's CA. This does not seem like a win to me.

I don't think that rent-seeking SSL CAs are as big a problem as many HN users seem to think they are. I think ultimately there's significant expense involved in operating a secure CA, and that relative to their purported value, CA certificates are reasonably priced.

The pressing problem with SSL/TLS is that CAs aren't trustworthy. They are rent-seeking, as expected, but also shoddily operated. The Internet has largely lost faith in the people operating CAs.

Moreover, a decade and a half of browser/CA relationships have left all the major browsers riddled with skeleton-key CA certs run by organization that nobody can really vouch for. As a result, large companies have purchased browser-trusted CA operations, and then used them to do incredibly dubious things. The companies that have been caught doing skanky stuff with their CA keys haven't even been kicked out of the browser CA stores.

As a result, we're left with a situation in which untrustworthy companies can potentially sign certificates for (and thus enable transparent MITM attacks against) critically important sites, like Google Mail. That's an untenable position.

I personally believe (and, yes, hope) that the future of Internet security looks much like today, except with things like Trevor Perrin and Moxie Marlinspike's TACK scheme, to allow security-sensitive sites to overrule bogus CAs, and to allow us to gradually decrease the architectural dependence we have on SSL CAs and start experimenting with more flexible alternatives.

I am not a fan of trying to take the same model that just failed us, but centralizing it and handing it over to the unaccountable groups of people who control the domain name system.

Re: Living with HTTPS

#86
post #69

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)

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.

Re: Living with HTTPS

#87
post #81
post #48

Earlier quoted context omitted.

It's very straightforward for a proxy to have its own CA=YES certificate and mint/sign certs for every HTTPS site the proxy sees on the fly. If you have a corporate proxy that is intercepting HTTPS traffic, that is what it should be doing. Then, the proxy makes its certificate available to users, you download it, and add it to your CA certs via the UI that browsers provide for that; HTTPS magically appears to work ag…

So the proxy server acts as a forced man in the middle? This has to be one of the most atrocious things I have ever experienced. Forcing a man in the middle is insane especially in a large company where there may well be a lack in competency. HTTPS shouldn't magically appear to 'work' again, considering it is completely broken when a forced mitm is introduced.

Are you arguing with me, or with reality? I can't tell, because the system I described is how corporate proxies work pretty much everywhere.

If you want privacy against the administrators of your employer, don't use your employer's network to do things that need privacy.

Re: Living with HTTPS

#88
post #85

Earlier quoted context omitted.

Thanks for your answer! I'm more confused by the moment about DNSSEC et al: isn't the DNSSEC-based validation of HTTPS referred to above supposed to get rid of CAs in the future? That wouldn't make sense even with DNSSEC considering that the information is not encrypted? (Right?) I hope you don't take this as "hijacking", but I'd be most curious about what you and other security experts think about Paul Vixie's "Whit…

There is a splinter group of people- who- want- DNSSEC who argue that DNSSEC will obviate the need for CAs. There reasoning, distilled, is that DNSSEC is itself a PKI, with the roots signing TLDs and TLDS signing domains and so on. Since the core architecture purpose of certificates is to "break the tie" between an attacker's public key and the real site's public key, and since DNSSEC zones could serve the same purpo…

Wow. Thank you very much for educating us, Thomas. Your comments require grabbing some popcorn or equivalent. In particular when you engage in a constructive debate with someone of your caliber. One of my all-time favorite threads in HN (or elsewhere...) is http://news.ycombinator.com/item?id=893659. Thanks again.

Re: Living with HTTPS

#89
post #75

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?

Without the proper tuning https will be significantly slower than http.

Re: Living with HTTPS

#90
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)

Post reply on HN