[HTTPS-Everywhere] HTTPS Everywhere for Chromium

Chris Palmer chris at eff.org
Wed Dec 1 18:13:36 PST 2010


On Dec 1, 2010, at 11:38 AM, Daniel Lanigan wrote:

> We're using (as you could figure out if you dig deep enough) Amazon's Cloudfront. I can definitely point the urls to https. The problem is that we're using cdn1.rentjungle.com, cdn2.rentjungle.com, etc. But, the certificate that's sent back is for .cloudfront.com, so it doesn't match. As far as I know if I changed the urls to point to *whatever the random subdomain is*.cloudfront.com, it should work just fine (in theory...), but then we'd have an extra DNS lookup, and links to an external domain, and I think we'd prefer to not.

What extra DNS lookup? If you lookup cdn2.rentjungle.com or foo.cloudfront.com, it's one name either way. In fact, just now when I looked up cdn2.rentjungle.com, in one response packet I got a lot of answers: the fact that the CNAME for cdn2.rentjungle.com is d2n9qgwrg5blis.cloudfront.net, and then 8 round-robin A records for d2n9qgwrg5blis.cloudfront.net. So it's all the same anyway, and DNS already optimizes away, thankfully, what might otherwise have been more round trips.

As for links to an external domain, what is wrong with that? You've already decided to do it with Quantcast.

> That's about it really. Though I'm also not sure about the ability of some of our other external scripts (quantcast, etc) to use https, but that's neither here nor there.

Actually, that is very much here and there. :) When you include https://example.com/whatever.{js,jpg}, you give example.com control over your page (or part of your page, in the case of images).

When you include http://example.com/whatever.{js,jpg} in your page, you give example.com and any active network attacker control over your page.

For that matter, is Amazon/Cloudfront trustworthy?


-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation




More information about the HTTPS-everywhere mailing list