Re: CVE Request: Enforce use of HTTPS for MathJax in IPython

[Donald Stufft <donald () stufft io>]

On August 3, 2014 at 1:52:32 AM, gremlin () gremlin ru (gremlin () gremlin ru) wrote:
> On 02-Aug-2014 16:31:17 -0400, Donald Stufft wrote:
>  
> > > > loaded over HTTP. An attacker with fortuitous network position
> > > > could execute code on a local IPython notebook by modifying
> > > > the mathjax javascript.
> > > HTTPS wouldn't help much: the attackers (most of which are known
> > > to use 3-letter names) can (and they really do) issue a fake
> > > certificate for their decoy servers.
> > There are attackers other than 3 letter agencies.
>  
> Those attackers don't have things like SORM-2 or Jindun Gongcheng.

So your point is that if we can’t protect against targeted attacks
from multi billion dollar nation state adversaries we also shouldn’t
protect against a guy in the coffee shop.

>  
> > > In general, nothing received from the Net could be trusted. And
> > > the HTTPS doesn't guarantee anything beyond "this certificate
> > > was signed by this CA" - was that voluntary or forced.
>  
> Any objections on this point? :-)

The first part, yes. But I don’t feel like getting into an argument
about what trust means.

>  
> > > Enforcing HTTPS for the whole site is even more stupid: normally
> > > only user-specific data (login procedure, personal settings for
> > > registered users, etc) should be forced to go through HTTPS;
> > > everything else should normally be left up to the users' wish.
> > This is incredibly wrong. First off if only your login procedures,
> > personal settings, etc are password protected
>  
> Why password? Use client certificates instead.

Because client certificates have the worst UX possible. Saying we
should use client certificates is all well and good but I live in
the real world where a site that uses client certificates is
practically unusable in many browsers, and actually unusable in some.

Hint: Client certificates don’t protect against anyone who can
create their own valid certificates anyways so you’re getting
a crappier site for zero security benefits from the TLAs.

>  
> > then it's trivial for a MITM to simply strip the HTTPS from the
> > link to the login page.
>  
> At which point? Inside of my browser? Bwa-ha-ha...
> Redirect from http://example.net/login to https://example.net/login
> will perform just fine when there's a mistype.
>  
> > The vast bulk of users simply won't notice that they are visiting
> > a page via HTTP instead of HTTPS.
>  
> Nothing new: 95% of people are morons.
>  
> But once you'll create a system which can be used even by morons,
> it will be used only by morons.

I’m not even sure what this is supposed to mean. “It’ll be used
only by morons”? Yea whatever. Again most people live in the
real world where we can’t throw away 95% of the people in the
world because we want to pretend that using client certificates
or some other such nonsense is actually achieving anything
meaningful.

>  
> > Furthermore, even if you manage to login over HTTPS, HTTP,
> > being a stateless protocol, includes authentication credentials
> > with every request. This is typically taken in the form of
> > cookies which are sent with every request.
>  
> If you want to get some real security, use client certificates.

Client certificates don’t protect against TLAs which is your
stated attacker that you’re trying to protect against.

>  
> > In order to protect these cookies they need to only be sent
> > over a HTTPS connection.
>  
> "This is incredibly wrong." // (q) Donald Stufft, 2014-08-02
>  
> Here's my cookie named "auth":
> d4791d97c2e8aebfb09b0ce1e5d5bcc998fcdc02a2d4d7a5f7669c01d28fac5b
> It is known to contain my IPv4 address (among other information)
> and be Blowfish-encrypted. You've intercepted it. Next action?

If I had a MITM on your connection then i’d simply need to add it
to my own session and then I’m logged in as you. I don’t need to
decrypt it because the site operator will decrypt it for me to
see if I’m you. That’s assuming that the site has some means for
associating your cookie with a session (which I assume is what
you’re getting at with the IPv4 comment). A lot of sites don’t do
that so I don’t even need a MITM at that point.

>  
> Another option: I browse online shop anonymously (without logging
> in, which is wise: I don't want to see offers on things I don't
> actually need). You've intercepted my cookies. Next action?

Sure in this incredibly specific situation your cookies probably
aren’t very useful. Guess what, living in the real world again
cookies are ambient authentication and need to be protected on
most sites.

>  
> > [...]
> > So sure, this doesn't prevent a TLA with access to a root key
> > doing a targeted attack against a site, however it does prevent
> > an attacker who just happens to be on the same network (Coffeshop
> > Wifi etc) from attacking you.
>  
> Unlike TLA, an attacker in the same network can only eavesdrop
> passively. So, I can either keep anonimity (without logging in) or
> switch to HTTPS intentionally. Just don't push me there unless I've
> logged in…

This is wrong. There are many ways that an attacker in the same network
can do more than just eavesdrop. For one DNS is an unauthenticated
protocol and resolvers simply listen to the first response they get. So
it’s trivial for me, if I’m in the same network, to response to a DNS
query quicker than some server that’s not on the same LAN can.
Additionally there are things like ARP poisoning and the like.

Finally if a cookie is sent over HTTP than passive eavesdropping is all
I need.

>  
> (Normally I use secure tunnel to the trusted server when using public
> hotspots, so this is just to keep the discussion).
>  
> > > But the terminal state of mental disability is... yes, using
> > > scripts from outer sources: intercepting one popular source like
> > > https://ajax.googleapis.com/ajax/libs/jquery/*/jquery.min.js
> > > will allow the attacker to not bother of intercepting other
> > > sites directly.
>  
> Any comments on this?

Not particularly. It’s an obvious point. If you use the same script
as a lot of other people that is a more valuable target to attack
then a script hosted separately for each site.

--  
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA