[<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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
