After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726288 - leaks secure cookie information across MITM'ed HTTPS connections
leaks secure cookie information across MITM'ed HTTPS connections
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Passwords, Cookies, & Certificates
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on: 708847
Blocks: 721283
 
 
Reported: 2014-03-13 21:49 UTC by Daniel Kahn Gillmor
Modified: 2014-08-08 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Kahn Gillmor 2014-03-13 21:49:39 UTC
epiphany makes an unusual choice about what to do when X.509 certificates fail to validate: it goes ahead and makes the connection, but marks it with a broken lock icon to indicate that the connection is not secure.

I'm not going to argue that this convention itself is wrong (i think it's an interesting approach), but this sort of fail-open *must* protect the user's secure cookies (and any other traffic that is expected to be actually-secure) by not sending them across the un-validated TLS session.

In practice, if i visit an HTTPS site which sets a cookie (and marks the cookie "secure"), and i then set up a man-in-the-middle with a bogus certificate, and then have epiphany re-connect to that service, ephiphany will send the secure cookie to the MITM.

This results in a session compromise (the MITM can take any action it wants to on the server as myself).   it even appears to be triggerable with a <img width="1" src="https://targetedomain.example/favicon.ico" /> tag embedded in any other web page.

This makes ephiphany dangerous to use on any https web site that uses cookies to track user authenticated sessions (which is a large fraction of the web these days).
Comment 1 Daniel Kahn Gillmor 2014-03-14 04:30:43 UTC
Cookies are not necessarily the only thing that could be leaked, fwiw.  epiphany should treat any authentication-failed HTTPS connections exactly the way it would treat cleartext.  This means that in any context where data over a cleartext connection would be unacceptable, data from the authentication-failed HTTPS connection should also be unavailable.

A couple of other examples:

Mixed-content protection: modern browsers should refuse to load active content (javascript) from cleartext channels if they will be running in the context of an authenticated HTTPS origin; epiphany should also refuse to load active content from authentication-failed connections.

REFERER headers: modern browsers do not send https referer headers to http sites.  epiphany should also refuse to send https referer headers to authentication-failed HTTPS connections.

I'm sure there are more behavioral nuances like this; i'm fine if folks want to collect the list here.  what else have i missed?
Comment 2 Michael Catanzaro 2014-07-11 00:47:14 UTC
Hey Daniel, I think the issue you mention in your first post is covered by my patchset in bug #708847, do you agree?

(In reply to comment #1)
> Mixed-content protection: modern browsers should refuse to load active content
> (javascript) from cleartext channels if they will be running in the context of
> an authenticated HTTPS origin; epiphany should also refuse to load active
> content from authentication-failed connections.

I'd like to track this separately; I've filed bug #733038 for this issue.

> REFERER headers: modern browsers do not send https referer headers to http
> sites.  epiphany should also refuse to send https referer headers to
> authentication-failed HTTPS connections.

OK, bug #733039.

If you can think of anything else wrong, please do file a new bug and I'll set it to block bug #721283. Thanks.
Comment 3 Daniel Kahn Gillmor 2014-07-11 04:54:47 UTC
(In reply to comment #2)
> Hey Daniel, I think the issue you mention in your first post is covered by my
> patchset in bug #708847, do you agree?

I haven't tested the three patchsets on #708847, but a quick skim looks like they're taking the standard browser approach to certificate validation failures -- blocking the pageload entirely, if i'm understanding them correctly.

This report was about leaking secure cookies across the unauthenticated pageload, so if the unauthenticated pageload isn't happening anymore, then certainly no cookies will be leaked across it.

If the user clicks through enough of the warnings to enable the cert anyway, though, i suspect the cookies will propagate.  I'm not sure if this is worse or better than blocking the old cookies in the event that an unvalidated site is being re-visited, or maybe tying the cookies for a site to its last-seen valid/accepted cert -- so if a non-validated cert is presented, and the user manages to click through to see it anyway, the user's cookies would be reset for the site and not transmitted to the click-through?  (Worst case, this would mean that the user would be immediately presented with the site's login prompts again, which would mean that they'd give the site their password instead of their cookies.  But a MITM site could steal their cookies and prompt them for their password anyway, right?)

I'm brainstorming here -- epiphany's history of doing something radically different from the other browser vendors is at least a useful experiment in breaking expectations and thinking about the different consequences of possible choices that other people have not made. :)
Comment 4 Michael Catanzaro 2014-07-11 13:49:18 UTC
(In reply to comment #3)
> If the user clicks through enough of the warnings to enable the cert anyway,
> though, i suspect the cookies will propagate.  I'm not sure if this is worse or
> better than blocking the old cookies in the event that an unvalidated site is
> being re-visited, or maybe tying the cookies for a site to its last-seen
> valid/accepted cert -- so if a non-validated cert is presented, and the user
> manages to click through to see it anyway, the user's cookies would be reset
> for the site and not transmitted to the click-through?  (Worst case, this would
> mean that the user would be immediately presented with the site's login prompts
> again, which would mean that they'd give the site their password instead of
> their cookies.  But a MITM site could steal their cookies and prompt them for
> their password anyway, right?)

Right.  That's a clever idea that's probably worth its own bug, but I don't think it's a priority unless Firefox and Chrome are doing it too (which I kind of doubt).
Comment 5 Daniel Kahn Gillmor 2014-07-11 14:25:54 UTC
(In reply to comment #4)

> Right.  That's a clever idea that's probably worth its own bug, but I don't
> think it's a priority unless Firefox and Chrome are doing it too (which I kind
> of doubt).

i guess that depends on whether you think epiphany should lead or follow the other browsers :)

I'm not convinced that the old behavior (the auto-fallthrough) on invalid certs was the right thing (or even a Good Thing), but it is a very interesting challenge to the existing orthodoxy, particularly in light of current discussions around "opportunistic security" like:

 https://tools.ietf.org/html/draft-dukhovni-opportunistic-security

(see also recent mammoth threads on https://www.ietf.org/mail-archive/web/saag/current/maillist.html -- june/july 2014).  Making choices about cookie/referer/localobject leakage that would enable a safer variant of such a mode, though the UI presumably needs to be thought through more too.

But switching to the common browser model is "safer" of course, in terms of meeting typical user expectations.
Comment 6 Michael Catanzaro 2014-08-08 14:47:49 UTC
(In reply to comment #5)
> i guess that depends on whether you think epiphany should lead or follow the
> other browsers :)

Lead when it does not break web sites (stripping the referrer seems totally safe) and when it's more important than other priorities (too many other priorities right now, unfortunately), and follow otherwise.

> But switching to the common browser model is "safer" of course, in terms of
> meeting typical user expectations.

Yup.  In 3.14 users will have to click through a fairly strongly-worded warning message to leak their cookies. This is not ideal since many probably will, but at least we now default to secure.