[HTTPS-Everywhere] HTTPS Everywhere for Chromium

Daniel Lanigan Daniel at chibu.net
Wed Dec 1 11:38:04 PST 2010


No, I hear you. I'm all about getting https everywhere (hence this mailing
list :P)

As for the CDN:

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.

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.

If there's anyway to work with this to get it setup, that would be great.
https://www.rentjungle.com/ works just fine other than calling improperly
secured files.

~ Daniel


On Wed, Dec 1, 2010 at 1:33 PM, Chris Palmer <chris at eff.org> wrote:

> On Dec 1, 2010, at 4:18 AM, Daniel Lanigan wrote:
>
> > While I do agree in principal, it's just not going to happen yet. I'm
> working on getting https going for my company's site, rentjungle.com, but
> I'm having issues with getting the CDN working correctly (I'm not sure it's
> possible with our current setup).
>
> For my own understanding, can you explain more about your CDN problems?
> People often raise this concern to me, and I want to know more about the
> practical difficulties they face. Some CDNs, like Amazon, do offer HTTPS
> service, so in theory it should be plug and play. For some operators, it is.
>
> Unfortunately, Amazon charges more for HTTPS service. (I am looking into
> finding out why --- I suspect it's mostly a form of price discrimination and
> only lightly tied to actual operating costs.)
>
> > However, the real issue lies with smaller sites, especially personal
> websites running on shared servers. Dreamhost, for instance, requires you to
> have a unique IP address (and of course, the certificate), which obviously
> costs more.
>
> Certainly. To address that problem, we have Server Name Indication:
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication
>
> It's not 100% supported yet, but at least it's there and growing. There are
> many hurdles before we can live the "there is only one mode, and it is
> secure" dream. My purpose with this and my previous email is to goad
> everyone into getting their jumping shoes on so we can start leaping over
> those hurdles. :)
>
>
> --
> Chris Palmer
> Technology Director, Electronic Frontier Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101201/ed20633c/attachment.html>


More information about the HTTPS-everywhere mailing list