Living with HTTPS • Hacker News Board

Re: Living with HTTPS

#121

Post by mxxx » Fri, Jul 20, 2012, 7:35 AM UTC

harshreality wrote: post #26

isaacaggrey wrote: post #3

For users, HTTPS Everywhere is a must: 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/ [2] http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...

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

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.

Re: Living with HTTPS

#122

Post by webjunkie » Fri, Jul 20, 2012, 7:48 AM UTC

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…

Do StartSSL certificates even work on every browser by default?

Re: Living with HTTPS

#123

Post by mike-cardwell » Fri, Jul 20, 2012, 8:39 AM UTC

tptacek wrote: post #4

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

"Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set."

Less than a year ago, you were saying HSTS wasn't worth the trouble. Ref: https://news.ycombinator.com/item?id=2909613

Glad you've changed your mind.

Re: Living with HTTPS

#124

Post by pornel » Fri, Jul 20, 2012, 10:19 AM UTC

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?

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.

Re: Living with HTTPS

#125

Post by icebraining » Fri, Jul 20, 2012, 10:29 AM UTC

jaggederest wrote: post #79

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.

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.

Re: Living with HTTPS

#126

Post by icebraining » Fri, Jul 20, 2012, 10:35 AM UTC

webjunkie wrote: post #122

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…

Do StartSSL certificates even work on every browser by default?

Yes. They offer a list on the bottom of the page: http://www.startssl.com/?app=40

Re: Living with HTTPS

#127

Post by agl » Fri, Jul 20, 2012, 1:56 PM UTC

sadpluto wrote: post #84

agl wrote: post #82

Earlier quoted context omitted.

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…

Yes, DNS can be used to direct you to the wrong IP address but that hardly matters: an evil network can give you the correct IP address but then intercept all traffic to it.

The key is that the IP address doesn't matter, indeed it shouldn't matter whether the traffic is going over carrier pigeon. You have a name that you wish to connect to, say example.com, and you have some way to send an receive packets. If the other end can prove that they are example.com by means of a certificate then you have a secure connection. How the data gets there and back is immaterial to transport security.

Re: Living with HTTPS

#128

Post by samt » Fri, Jul 20, 2012, 3:15 PM UTC

kodisha wrote: post #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)

Yes this works. Just get all the headers correct.

Re: Living with HTTPS

#129

Post by tptacek » Fri, Jul 20, 2012, 3:26 PM UTC

DannoHung wrote: post #119

agl wrote: post #30

Earlier quoted context omitted.

The bypass button only disappears for HSTS sites. Do you have a proxy server that's intercepting these connections and has a broken certificate? You can disable all certificate checking with --ignore-certificate-errors but it is as bad as it sounds. Rather, to correctly support MITM proxies you should install their CA certificate locally.

I suppose I can use that the next time it happens, but that's a bit more overkill in terms of disabling warnings than I'm looking for :/

Starting Chrome with a flag is more overkill than adding a whole feature to Chrome to allow users to ignore SSL security?

Re: Living with HTTPS

#130

Post by otterley » Fri, Jul 20, 2012, 4:05 PM UTC

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?

In my case, I work for a SaaS provider that performs virtual hosting using customer-provided SSL certificates (myservice.customer.com). This puts us in the unenviable position of having to maintain thousands of IP address endpoints, one per customer, along with all the network-related complexity that goes along with it.

SNI would help a lot, but unfortunately it will never be a feature in the SSL client code in Windows XP (which MSIE uses) and so we're stuck with this for the foreseeable future.