Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Living with HTTPS

imperialviolet.org

Post reply on HN
Print view View original

71–80 of 132 posts

Re: Living with HTTPS

#71

Post by peterwwillis »

Erwin wrote: post #43
agwa wrote: post #24

Earlier quoted context omitted.

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/I…

A certificate can also have a number of alternate names, which providers call a Unified certificate -- UCC. The nice thing about that is that you can add/remove names after you've bought the certificate without having to go through the process. I haven't tried this in practice though, but this might be useful if you want to provide a bunch of client.yourdomain.com secure subdomains from the same IP address. Only down…

This is also wildly more secure than a wildcard certificate, where if someone nicks your private key your entire domain is compromised, but with UCC only select hosts' security could be compromised. I believe it's also supported in more devices than SNI (since X.509v3)

Re: Living with HTTPS

#72

Post by [deleted] »

rabidsnail wrote: post #34
moonboots wrote: post #29

Earlier quoted context omitted.

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

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]

Re: Living with HTTPS

#73

Post by spindritf »

zobzu wrote: 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…

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

Re: Living with HTTPS

#74

Post by spindritf »

rogerbinns wrote: post #54

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.

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

Re: Living with HTTPS

#75

Post by timr »

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?

Re: Living with HTTPS

#76

Post by [deleted] »

timr wrote: 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?

[deleted]

Re: Living with HTTPS

#77

Post by sadpluto »

tptacek wrote: post #63
sadpluto wrote: post #58

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…

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 "Whither DNSCurve?" [1], which has amazingly not been submitted in HN. I just submitted it [2].

(If I could vote for your time investment, please kindly consider commenting on that article before replying to this comment.)

Thanks again!

[1] http://www.isc.org/community/blog/201002/whither-dnscurve

[2] http://news.ycombinator.com/item?id=4268461

Re: Living with HTTPS

#78

Post by icebraining »

chime wrote: post #33
tptacek wrote: post #7

Earlier quoted context omitted.

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…

If clearing the browser cache/cookies makes the browser forget about STS for each domain, then MITM attacker gets a lot more chances to intercept and attack. I don't have stats on how often average users clear their browsers but it is a fairly common troubleshooting step so most people are aware of it. If clearing the browser cache/cookies does not make the browser forget about STS for each domain, then we got anothe…

The whole point of tracking cookies is to maintain some identifier. With STS you only get 1 bit, how do you identify them? All users who have visited the site since (now - STS expiration length) look the same.

Re: Living with HTTPS

#79

Post by jaggederest »

zobzu wrote: 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.

Re: Living with HTTPS

#80

Post by woobles »

sp332 wrote: post #2

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

Very interesting. Thanks!
Post reply on HN