Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Aug 2014 09:51:44 +0400
From: gremlin@...mlin.ru
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request: Enforce use of HTTPS for MathJax in IPython

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.

 >> 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? :-)

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

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

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

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

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?

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

(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?


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin  gremlin  ru>
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ