(In reply to comment #0)
> We need to immediately disable SSLv3 in recently-released versions of
> glib-networking in order to respond to the POODLE attack.

POODLE is specifically an attack against browsers-using-SSLv3, not SSLv3 in general, so it's only WebKit/Epiphany that are at risk, and it would make more sense to disable it at that level. (Except that glib doesn't provide any way to disable SSLv3, so we do need to at least add new API...)

Note that there are still SSLv3-only hosts out there (some of them inside firewalls and thus not vulnerable to POODLE and thus less likely to be upgraded), so disabling SSLv3 globally would break some things for some people. (And even if we provide a way to re-enable SSLv3, no existing code would be making use of it, so it would effectively be an ABI break, and, eg, evolution would have to also put out a new release, to allow connectivity to continue working for certain users.)

> It will almost surely be disabled by default in GnuTLS 3.4 [2]

I don't think that thread suggests "almost surely".

I don't have a strong preference for how we do this, so long as we get SSLv3 disabled in WebKitGTK+ in all major distros ASAP. The problem with new API is that any new API would have to be backported to several old stable releases (for Fedora, we'd need it in both GNOME 3.8 and 3.10) for it to get picked up by important distros, and I'm not sure that WebKitGTK+ can raise its glib or libsoup dependencies at all. New API also makes it more difficult for apps to do the right thing.

Maybe the best thing to do would be to email distributor-list to advise distributors to disable SSLv3 by default at the GnuTLS level, and then write this off as NOTGNOME. Maybe that's a terrible idea. I'll ask Nikos for his thoughts.

(In reply to comment #1)
> POODLE is specifically an attack against browsers-using-SSLv3, not SSLv3 in
> general, 

OK, that's true.

> so it's only WebKit/Epiphany that are at risk, and it would make more
> sense to disable it at that level. (Except that glib doesn't provide any way to
> disable SSLv3, so we do need to at least add new API...)

WebKitGTK+ hardly knows anything about SSL/TLS; it basically just calls soup_message_get_https_status() to decide whether the connection is secure or not. So we'd need new API in libsoup as well.

> Note that there are still SSLv3-only hosts out there (some of them inside
> firewalls and thus not vulnerable to POODLE and thus less likely to be
> upgraded), so disabling SSLv3 globally would break some things for some people.

They're going to break anyway with future versions of GnuTLS.

> (And even if we provide a way to re-enable SSLv3, no existing code would be
> making use of it, so it would effectively be an ABI break, and, eg, evolution
> would have to also put out a new release, to allow connectivity to continue
> working for certain users.)

I see your point. Unfortunately, not changing anything does not protect us from such an ABI break, since GnuTLS can already remove cipher suites and protocols, causing negotiation failure even though the version of glib-networking is unchanged. Hm....

> I don't think that thread suggests "almost surely".

As of right now, there's only one objection, and as far as I can parse his argument it is that all other crypto protocols are also compromised by a government conspiracy, so there's no value in upgrading to a newer one... and while I'm not at all sure that's as outlandish as it should be, I'm still going to go with "almost surely," indeed. :)

I've asked for suggestions on gnutls-help: http://lists.gnutls.org/pipermail/gnutls-help/2014-October/003636.html

GTlsConnectionGnutls has a back door in the form of an environment variable that you can set to change the gnutls "priority string" ("man gnutls_priority_init" for the general idea, though that's not the complete documentation). So the simplest thing for distros to do if they want something quick is just turn epiphany into a wrapper script:

  #!/bin/sh

  # Forbidden POODLE!
  export G_TLS_GNUTLS_PRIORITY=${G_TLS_GNUTLS_PRIORITY:-NORMAL:%COMPAT:\!VERS-SSL3.0}
  exec /usr/bin/epiphany.real "$@"

(In reply to comment #2)
> > I don't think that thread suggests "almost surely".
> 
> As of right now, there's only one objection

Yeah, but the original post was just "hey, should we do this, maybe?", not "i'm going to do this".

To the extent that security people are talking a lot about this, I suspect that it's not because they're worried about it actually becoming a problem (Firesheep never amounted to much), but because they're excited about finally having a solid excuse for forcing everyone to upgrade their old SSLv3 servers. (In fact, given the problems the Chrome team had with their attempts at TLS-speeding-up extensions, I wouldn't be surprised if Google explicitly went looking for an exploit that they could use as leverage to rid the world of SSLv3-only servers. ;-)

Created attachment 288714 [details] [review]
Allow controlling the SSL/TLS versions a GTlsConnection can use

not tested and I haven't written the glib-networking side yet...

(In reply to comment #4)
> GTlsConnectionGnutls has a back door in the form of an environment variable
> that you can set to change the gnutls "priority string" ("man
> gnutls_priority_init" for the general idea, though that's not the complete
> documentation). So the simplest thing for distros to do if they want something
> quick is just turn epiphany into a wrapper script:
> 
>   #!/bin/sh
> 
>   # Forbidden POODLE!
>   export
> G_TLS_GNUTLS_PRIORITY=${G_TLS_GNUTLS_PRIORITY:-NORMAL:%COMPAT:\!VERS-SSL3.0}
>   exec /usr/bin/epiphany.real "$@"

Wonderful. This environment variable is checked at the beginning of each handshake, so we can set it in the network process initialization. Martin, Carlos, does this sound OK?

> To the extent that security people are talking a lot about this, I suspect that
> it's not because they're worried about it actually becoming a problem
> (Firesheep never amounted to much), but because they're excited about finally
> having a solid excuse for forcing everyone to upgrade their old SSLv3 servers.

I haven't read the paper yet, but my understanding is that this completely breaks SSL/TLS in browsers that support SSLv3, provided that the user loads one webpage via HTTP instead of HTTPS (in order to allow javascript injection). Hence the urgency to fix this.

My understanding of Firesheep is that it was not a browser vulnerability. It only compromised session cookies that were sent over HTTP, but it's completely expected that cookies sent over HTTP are attacker-controlled.

OK, new API works too. I guess for WebKitGTK+ we'll test the glib version at compile time to decide whether to set the environment variable or to use the new API, so that you don't have to backport this to a bunch of stable branches and so that we don't need to bump our dependency. That will create an awkward hole for users who compile against an older glib but use a hypothetical future version of glib-networking that doesn't use GnuTLS, but I think that's reasonable.

(In reply to comment #7)
> My understanding of Firesheep is that it was not a browser vulnerability. It
> only compromised session cookies that were sent over HTTP, but it's completely
> expected that cookies sent over HTTP are attacker-controlled.

OK, reading the paper, I see it's only an attack on the secure cookie. That's still very bad. If you control my Amazon.com session, you can buy stuff with my credit card and bank account.

Note you can't call setenv() after any threads are created.  That means *very* early in process startup. 

Further note using GSettings to check for something will involve spawning two threads.

https://bugzilla.gnome.org/show_bug.cgi?id=659326

I guess we'll add equivalent API to SoupSession as well, since WebKitGTK+ doesn't have access to the GTlsConnection?

(In reply to comment #10)
> Note you can't call setenv() after any threads are created.  That means *very*
> early in process startup. 
> 
> Further note using GSettings to check for something will involve spawning two
> threads.

Thanks very much for the warning; I would surely have gotten that wrong.

We can use the new API in WebKit using conditional compilation, and suggest distros to upgrade their libsoup version. I wouldn't mind to bump the requirements anyway, I think a serious security bug is enough reason to bump any dependency, but I'm not sure everybody agrees with me on that.

(In reply to comment #11)
> I guess we'll add equivalent API to SoupSession as well, since WebKitGTK+
> doesn't have access to the GTlsConnection?

Eventually, yes, although even without new API, WebKit can use SoupMessage::event (a proxy for GSocketClient::event) to monitor the connection process and set the right flags on the connection before the handshake occurs. (It already uses that signal for other stuff so it's not even much more code.)

(In reply to comment #12)
> We can use the new API in WebKit using conditional compilation

Given that there's a workaround without needing new API, which you'll need to be using anyway, and given that we don't normally (or ever?) add new API in point releases, I'm leaning towards not adding the new API until GLib 2.44 (which then also gives us more time to make sure we're getting the API right).

OK, I have a response from Nikos at [1]. He's saying that unless we've implemented nonstandard TLS version negotiation on top of GnuTLS, then we are not vulnerable [2]. (This is because the attack is mostly passive, except for the portions where the attacker injects malicious js into an HTTP connection and forces TLS negotiation failure with all versions of TLS.) I need to check to be sure, but I am pretty sure we do not do that. If so, no problem (though it's independently a good idea to disable SSLv3). For what it's worth, poodletest.com says we're not vulnerable, but ssllabs.com says we are. ssllabs.com is more trustworthy, but they might well only be checking for whether we support SSLv3 at all, rather than whether they can force use of SSLv3 through the downgrade dance.

Nikos also recommends not adding API to allow applications to control the versions of protocols in use... hm.

(In reply to comment #13)
> Eventually, yes, although even without new API, WebKit can use
> SoupMessage::event (a proxy for GSocketClient::event) to monitor the connection
> process and set the right flags on the connection before the handshake occurs.
> (It already uses that signal for other stuff so it's not even much more code.)

Great, thanks for the tip. We can use this to disable SSLv3 using the existing glib API on GTlsClientConnection (which I did not know about), no changes required in anything besides WebKit, and no setenv() needed.

> (In reply to comment #12)
> Given that there's a workaround without needing new API, which you'll need to
> be using anyway, and given that we don't normally (or ever?) add new API in
> point releases, I'm leaning towards not adding the new API until GLib 2.44
> (which then also gives us more time to make sure we're getting the API right).

Yes, that is best, since we now have two workarounds (if we are vulnerable at all).

[1] http://lists.gnutls.org/pipermail/gnutls-help/2014-October/003637.html
[2] http://nmav.gnutls.org/2014/10/what-about-poodle.html

(In reply to comment #14)
> I need to check
> to be sure, but I am pretty sure we do not do that.

You do. It's implemented at the libsoup level. See bug 581342 for the history.

> We can use this to disable SSLv3 using the existing
> glib API on GTlsClientConnection (which I did not know about)

I assume you mean setting use-ssl3 to FALSE from the G_SOCKET_CLIENT_HANDSHAKING event... that actually won't disable SSLv3 entirely, it will just disable the fallback-to-only-SSLv3 behavior. (The property ought to be called "use-ONLY-ssl3", or "disable-tls"; SSLv3 is supported whether the property is TRUE or FALSE.)

Disabling fallback means you're no longer doing the "nonstandard TLS version negotiation" Nikos warns against, so you can't be man-in-the-middled. But you're still vulnerable when talking to websites that only support SSLv3, as long as they implement version negotiation correctly (since regardless of what you set use-ssl3 to, glib will be offering SSLv3 as a supported version). That's in contrast to the G_TLS_GNUTLS_PRIORITY solution, which would disable all SSLv3.

Probably any site that's still SSLv3-only is not terribly security-critical though, so this may be a good compromise.

OK, thanks. We're going to use setenv() to change G_TLS_GNUTLS_PRIORITY from WebKitGTK+.

I don't know what you want to do with this bug report. It's not really a good idea to leave the insecure version negotiation support in libsoup, but if it's still needed for compatibility....

Since Geary is still on WebKit 1, we need to disable SSLv3 manually.  There's a lot of information on this ticket.  Can someone distill the steps for programmatically disabling SSLv3 in WebKit 1?

(In reply to comment #17)
> Since Geary is still on WebKit 1, we need to disable SSLv3 manually.  There's a
> lot of information on this ticket.  Can someone distill the steps for
> programmatically disabling SSLv3 in WebKit 1?

You don't necessarily need to disable SSLv3 as the POODLE attack relies on inserting Javascript into an insecure connection, and Geary has disabled Javascript, so you are not vulnerable. It's probably a good idea to do so anyway. At the very beginning of main, before calling any function that could internally create a thread, use:

g_setenv("G_TLS_GNUTLS_PRIORITY", "NORMAL:%COMPAT:!VERS-SSL3.0", FALSE);

NORMAL:%COMPAT is the priority string used by GTlsConnectionGnutls. The third parameter disables overwrite, allowing the user to override the priority string if need be. Obviously this is a workaround, and it will stop working if glib-networking switches away from GnuTLS, or simply stops parsing this variable, or switches away from NORMAL:%COMPAT. It's also incompatible with Fedora's upcoming downstream crypto policies [1], which is worth knowing about since it will be a minor downstream problem in a few months.

[1] https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies

(In reply to comment #18)
> At the very beginning of main, before calling any function that could
> internally create a thread, use:
> 
> g_setenv("G_TLS_GNUTLS_PRIORITY", "NORMAL:%COMPAT:!VERS-SSL3.0", FALSE);

Thanks.

> It's also incompatible with Fedora's upcoming downstream crypto policies

Does it make sense to offer a configure switch to disable the disabling of SSLv3, or to allow the packager a way to specify the priority string?

(In reply to comment #19)
> Does it make sense to offer a configure switch to disable the disabling of
> SSLv3, 

...yes, I think it would, if you want to do so. You might prefer to wait and see if it's requested, though.

> or to allow the packager a way to specify the priority string?

This wouldn't be needed.

We're switching WebKitGTK+ to use the priority string "NORMAL:%COMPAT:%LATEST_RECORD_VERSION:!VERS-SSL3.0" as %LATEST_RECORD_VERSION is required for compatibility with some web sites.  Presuming it doesn't turn out to break others, it should probably be used in glib-networking (and other apps setting this environment variable) as well.

http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html

Yes, someone filed another bug about that (bug 740087). It presumably *will* break some other sites.

wip/danw/poodle has code to add %LATEST_RECORD_VERSION to the base priority string by default, and to remove it when constructing the "use-ssl3" priority string, and to make "use-ssl3" actually mean "use the lowest TLS/SSL version permitted by the base priority".

So with that, and the priority string you gave above, WebKitGTK+ would try "NORMAL:%COMPAT:%LATEST_RECORD_VERSION:!VERS-SSL3.0" first, and then if that handshake failed (perhaps because of %LATEST_RECORD_VERSION), libsoup would try again in "use-ssl3" mode, which in this case would be "NORMAL:%COMPAT:!VERS-TLS-ALL:+VERS-TLS1.0", and thus hopefully manage to negotiate a TLS 1.0 connection. ("!VERS-TLS-ALL" disables SSL 3.0 too, despite the "TLS" in the name, so that string permits only TLS 1.0.)

Unfortunately, "make check" seems to be failing even on master and I haven't debugged why yet, and I didn't want to push this and put out a 2.42.2 release until I did.

OK, but maybe overloading the semantics of "use-ssl3" like this will be more confusion than it's worth?

(In reply to comment #23)
> OK, but maybe overloading the semantics of "use-ssl3" like this will be more
> confusion than it's worth?

well, I'll update the docs too, and I'd like to rename it to "use-fallback" in 2.44. (Where by "rename" I mean "deprecate the existing property and add a new one".)

(In reply to comment #22)
> wip/danw/poodle has code to add %LATEST_RECORD_VERSION to the base priority
> string by default, and to remove it when constructing the "use-ssl3" priority
> string, and to make "use-ssl3" actually mean "use the lowest TLS/SSL version
> permitted by the base priority".

This is now committed, and released in glib-networking 2.42.1 and 2.43.1.

> Unfortunately, "make check" seems to be failing even on master

FTR, this is due to a gnutls bug (http://savannah.gnu.org/support/?108690), and the failing tests now get skipped when using the broken gnutls versions.

Ideally, we would also find a near-term solution to ensure apps can easily get a secure connection (with SSLv3 disabled) without mucking with any environment variables, at the cost of compatibility with ancient servers.

(In reply to comment #25)
> FTR, this is due to a gnutls bug (http://savannah.gnu.org/support/?108690), and
> the failing tests now get skipped when using the broken gnutls versions.

I'm still seeing failure on connection test #15; is this the test that was broken for you? I don't see any recent commits with the effect of disabling the test when using the broken gnutls versions.

(In reply to comment #26)
> > FTR, this is due to a gnutls bug (http://savannah.gnu.org/support/?108690), and
> > the failing tests now get skipped when using the broken gnutls versions.
> 
> I'm still seeing failure on connection test #15

oops, I pushed the fix on glib-2-42 but forgot to push master too. fixed now.