This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Hi, What are the blockers for having that implemented in glib-networking?

(In reply to Nikos Mavrogiannopoulos from comment #3)
> Hi, What are the blockers for having that implemented in glib-networking?

I wouldn't say there are any blockers, just a couple things we need to figure out, which I'd like to hear thoughts on:

 * Upstreamability. My understanding is that @SYSTEM is a Fedora-specific thing at the moment and we're not allowed to put @SYSTEM in the priority string we use upstream, so we'd have to implement this with a downstream patch. This is really unfortunate. It would be nice if we could use @SYSTEM upstream, with GnuTLS smart enough to fall back, say, from @SYSTEM to NORMAL if a system policy is not set. We could patch it downstream, but this would be unfortunate.

 * Our current base priority string is NORMAL:%COMPAT:%LATEST_RECORD_VERSION. Are %COMPAT and %LATEST_RECORD_VERSION part of the system policy on Fedora? If so, then it doesn't matter, but if not, then we need to decide if it's acceptable or desirable to use @SYSTEM:%COMPAT:%LATEST_RECORD_VERSION as the priority string or if we have to use only @SYSTEM. If we use only @SYSTEM and the system policy doesn't include %COMPAT:%LATEST_RECORD_VERSION, I fear we're going to break web sites. This seems like a good time to try doing that, but if we start getting bug reports that Fedora's Firefox can handle sites that WebKit cannot, we're going to want to add back %COMPAT:%LATEST_RECORD_VERSION. (My measure of whether it's OK to break a site or not is if the site works in our Firefox.)

 * glib-networking uses different priority strings if an application enables fallback mode ("NORMAL:%COMPAT:%COMPAT:!VERS-TLS-ALL:+VERS-TLS1.0", the double %COMPAT is a bug) or unsafe rehandshake mode ("NORMAL:%COMPAT:%LATEST_RECORD_VERSION:%UNSAFE_RENEGOTIATION") or both at the same time. In this case, I guess we will just replace NORMAL with @SYSTEM and leave the rest, since we surely don't want to break these APIs. If you don't want applications using these modes, they should probably be fixed individually, same as we're doing for everything that uses GnuTLS, right?

See: https://git.gnome.org/browse/glib-networking/tree/tls/gnutls/gtlsconnection-gnutls.c#n213

 * Lastly, for downstreams of glib-networking: WebKit adds !VERS-SSL3.0:!ARCFOUR-128 to the priority strings. I guess we'll have to keep doing that forever, as even if the Fedora policy disables those (does it?) they will still be enabled in other distros (correct? is this true for new versions of GnuTLS?). It would be nice for applications to not need to worry about such things, but when a new attack like POODLE comes out, if we trust the system priority string then our users are going to be vulnerable for months or years, whereas major browsers like Firefox will have this fixed in a couple days. We're planning to add API to GLib to make it easier for applications to override the default priority string for this reason: https://bugzilla.gnome.org/show_bug.cgi?id=745637 Do you think WebKit should be able to trust the system policy to handle issues like these in the future (a) on Fedora, and (b) on other distros? Or will we have to continue to override the SYSTEM priority to disable such things? What about, e.g. certificates with SHA-1 signatures (which we'll of course want to distrust soon, probably beginning in GNOME 3.24)?

(In reply to Michael Catanzaro from comment #4)
> (In reply to Nikos Mavrogiannopoulos from comment #3)
> > Hi, What are the blockers for having that implemented in glib-networking?
> 
> I wouldn't say there are any blockers, just a couple things we need to
> figure out, which I'd like to hear thoughts on:
> 
>  * Upstreamability. My understanding is that @SYSTEM is a Fedora-specific
> thing at the moment and we're not allowed to put @SYSTEM in the priority
> string we use upstream, so we'd have to implement this with a downstream
> patch. This is really unfortunate. It would be nice if we could use @SYSTEM
> upstream, with GnuTLS smart enough to fall back, say, from @SYSTEM to NORMAL
> if a system policy is not set. We could patch it downstream, but this would
> be unfortunate.

@SYSTEM is Fedora specific, but you can simply use gnutls_set_default_priority() which is patched in Fedora to be @SYSTEM instead of NORMAL.

>  * Our current base priority string is
> NORMAL:%COMPAT:%LATEST_RECORD_VERSION. Are %COMPAT and
> %LATEST_RECORD_VERSION part of the system policy on Fedora?

What is more important is to know the reason of this choice. Most likely these priority strings are no longer needed since gnutls 3.3 (my guess is that you use %LATEST_RECORD_VERSION to connect to buggy servers, and %COMPAT to disable random record padding - these are now defaults in the gnutls library).

>  * glib-networking uses different priority strings if an application enables
> fallback mode ("NORMAL:%COMPAT:%COMPAT:!VERS-TLS-ALL:+VERS-TLS1.0", the
> double %COMPAT is a bug) or unsafe rehandshake mode
> ("NORMAL:%COMPAT:%LATEST_RECORD_VERSION:%UNSAFE_RENEGOTIATION") or both at
> the same time. In this case, I guess we will just replace NORMAL with
> @SYSTEM and leave the rest, since we surely don't want to break these APIs.
> If you don't want applications using these modes, they should probably be
> fixed individually, same as we're doing for everything that uses GnuTLS,
> right?

Yes, but that should be a downstream patch as you mentioned. Note that if you are doing unsafe fallbacks you should also set the %FALLBACK_SCSV option on the downgraded session (available since 3.4). However, since all browsers are dropping fallbacks it may make sense to plan for removing that code.

>  * Lastly, for downstreams of glib-networking: WebKit adds
> !VERS-SSL3.0:!ARCFOUR-128 to the priority strings. I guess we'll have to
> keep doing that forever, as even if the Fedora policy disables those (does
> it?)

Yes since F23.

> they will still be enabled in other distros (correct? is this true for
> new versions of GnuTLS?). It would be nice for applications to not need to
> worry about such things, but when a new attack like POODLE comes out, if we
> trust the system priority string then our users are going to be vulnerable
> for months or years,

I believe it is exactly the other way. On the next poodle we are able to respond centrally for all applications via the system policy. If we have applications deciding by themselves we get the current situation where it is unknown which application enables what.

> override the SYSTEM priority to disable such things? What about, e.g.
> certificates with SHA-1 signatures (which we'll of course want to distrust
> soon, probably beginning in GNOME 3.24)?

Why do you think it is easier changing all applications which use custom policies, as opposed to changing a central component in Fedora?

(In reply to Nikos Mavrogiannopoulos from comment #5)
> @SYSTEM is Fedora specific, but you can simply use
> gnutls_set_default_priority() which is patched in Fedora to be @SYSTEM
> instead of NORMAL.

We can certainly use gnutls_set_default_priority() for the default case, but if the application were to request fallback mode or turn on unsafe renegotiation, that won't work, because we enable those modes by appending to the priority string. In such cases the application would get NORMAL instead, which could e.g. unintentionally turn on ciphers that are disabled by the system policy. The only solution I can think of would be a downstream patch to explicitly include @SYSTEM in the priority string.

TBH I still think that making the system policy a Fedora-specific thing was a mistake; I see no strong reason that other distros should be different, especially for a security-critical library.

> >  * Our current base priority string is
> > NORMAL:%COMPAT:%LATEST_RECORD_VERSION. Are %COMPAT and
> > %LATEST_RECORD_VERSION part of the system policy on Fedora?
> 
> What is more important is to know the reason of this choice. Most likely
> these priority strings are no longer needed since gnutls 3.3 (my guess is
> that you use %LATEST_RECORD_VERSION to connect to buggy servers, and %COMPAT
> to disable random record padding - these are now defaults in the gnutls
> library).

OK, then I'm willing to try removing them. I wonder what Dan thinks, though; he might require a runtime check of the GnuTLS version so we still set the priority string manually if GnuTLS is older. I don't care about support for old GnuTLS, though, especially for minor compatibility issues with broken servers. Such old GnuTLS is probably insecure, anyway.

> the
> > double %COMPAT is a bug)

For the record: I tried to remove the double %COMPAT, but one of our SSL fallback tests failed surprisingly... I didn't look into it further.

> Yes, but that should be a downstream patch as you mentioned. Note that if
> you are doing unsafe fallbacks you should also set the %FALLBACK_SCSV option
> on the downgraded session (available since 3.4). However, since all browsers
> are dropping fallbacks it may make sense to plan for removing that code.

Thanks for pointing this out.

Beginning with Fedora 25, libsoup no longer uses the fallback mode (because major browsers are dropping the fallback), so this won't affect most GNOME stuff. But it's still offered by glib-networking, so I guess we should add use of %FALLBACK_SCSV to make it safer. (I didn't realize GnuTLS supported that extension.) I guess we need to check the version of GnuTLS in use to determine whether that's OK to use in the priority string, right?

> >  * Lastly, for downstreams of glib-networking: WebKit adds
> > !VERS-SSL3.0:!ARCFOUR-128 to the priority strings. I guess we'll have to
> > keep doing that forever, as even if the Fedora policy disables those (does
> > it?)
> 
> Yes since F23.

OK, good for Fedora, but now what about other distros -- what about NORMAL? We have to think about other distros too. If NORMAL still allows insecure things, then we'll have to keep setting the priority string manually upstream, and patch it out of WebKit in Fedora, which would be unfortunate.

> Why do you think it is easier changing all applications which use custom
> policies, as opposed to changing a central component in Fedora?

Mostly because I'm concerned you'll have compatibility concerns. If I remember correctly, GnuTLS in Fedora was quite late in disabling SSLv3; that didn't happen until the next stable Fedora release, right? I presume the system policy change was slow because of the risk of breaking a bunch of applications, but WebKit needed the policy change immediately.

Anyway, you clearly expect to be on top of such things in the future, so I'm fine with trusting gnutls_set_default_priority() in Fedora. Pushing as much security policy as possible into GnuTLS is great, because you know we're just going to get stuff wrong if we try to handle it at the higher levels. ;) But I'm still concerned about using this upstream, as it feel like it's maybe only safe in Fedora? What do you think, Nikos?

(In reply to Nikos Mavrogiannopoulos from comment #5)
> >  * Our current base priority string is
> > NORMAL:%COMPAT:%LATEST_RECORD_VERSION. Are %COMPAT and
> > %LATEST_RECORD_VERSION part of the system policy on Fedora?
> 
> What is more important is to know the reason of this choice. Most likely
> these priority strings are no longer needed since gnutls 3.3 (my guess is
> that you use %LATEST_RECORD_VERSION to connect to buggy servers, and %COMPAT
> to disable random record padding - these are now defaults in the gnutls
> library).

Random record padding is disabled by default or %COMPAT is enabled by default? (Or %COMPAT is now a no-op and gnutls strives to be more compatible by default?)

The padding is *probably* the specific reason we needed to specify %COMPAT in the past, but whenever there's a tradeoff that doesn't involve a concrete security exploit, WebKitGTK would probably rather have gnutls be more compatible with Firefox/IE/Chrome than have it be more featureful/correct.

But maybe these days %COMPAT belongs in WebKit's overrides, not in the base priority string.

> However, since all browsers
> are dropping fallbacks it may make sense to plan for removing that code.

libsoup master no longer attempts fallback (and I don't think anyone else ever used it).

(In reply to Dan Winship from comment #7)
> The padding is *probably* the specific reason we needed to specify %COMPAT
> in the past

(We never bothered to figure out exactly what bugs %COMPAT was working around. We just tried it, and it made stuff work better, so we started using it.)

(In reply to Dan Winship from comment #8) 
> (We never bothered to figure out exactly what bugs %COMPAT was working
> around. We just tried it, and it made stuff work better, so we started using
> it.)

E.g. if a broken firewall drops our handshakes because we support a menagerie of different ciphersuites instead of just a handful like major browsers, and there exist servers on the Internet that are still affected by this, we'll likely want to keep %COMPAT. But indeed, we could move it to WebKit instead....

(In reply to Michael Catanzaro from comment #9)
> (In reply to Dan Winship from comment #8) 
> > (We never bothered to figure out exactly what bugs %COMPAT was working
> > around. We just tried it, and it made stuff work better, so we started using
> > it.)
> 
> E.g. if a broken firewall drops our handshakes because we support a
> menagerie of different ciphersuites instead of just a handful like major
> browsers, and there exist servers on the Internet that are still affected by
> this, we'll likely want to keep %COMPAT. But indeed, we could move it to
> WebKit instead....

I just remember that %COMPAT doesn't only disable the random TLS record padding, but also enables a counter-measure to avoid a black-hole behavior of old F5 firewalls (the %DUMBFW option). These are today rare, but most likely you want to keep that on the client side for maximum compatibility.

(In reply to Dan Winship from comment #7)
> (In reply to Nikos Mavrogiannopoulos from comment #5)
> > >  * Our current base priority string is
> > > NORMAL:%COMPAT:%LATEST_RECORD_VERSION. Are %COMPAT and
> > > %LATEST_RECORD_VERSION part of the system policy on Fedora?
> > 
> > What is more important is to know the reason of this choice. Most likely
> > these priority strings are no longer needed since gnutls 3.3 (my guess is
> > that you use %LATEST_RECORD_VERSION to connect to buggy servers, and %COMPAT
> > to disable random record padding - these are now defaults in the gnutls
> > library).
> 
> Random record padding is disabled by default or %COMPAT is enabled by
> default? (Or %COMPAT is now a no-op and gnutls strives to be more compatible
> by default?)

Random record padding is disabled by default.

(In reply to Michael Catanzaro from comment #6)
> (In reply to Nikos Mavrogiannopoulos from comment #5)
> > @SYSTEM is Fedora specific, but you can simply use
> > gnutls_set_default_priority() which is patched in Fedora to be @SYSTEM
> > instead of NORMAL.
> 
> We can certainly use gnutls_set_default_priority() for the default case, but
> if the application were to request fallback mode or turn on unsafe
> renegotiation, that won't work, because we enable those modes by appending
> to the priority string. In such cases the application would get NORMAL
> instead, which could e.g. unintentionally turn on ciphers that are disabled
> by the system policy. The only solution I can think of would be a downstream
> patch to explicitly include @SYSTEM in the priority string.
> TBH I still think that making the system policy a Fedora-specific thing was
> a mistake; I see no strong reason that other distros should be different,
> especially for a security-critical library.

There was no other way. We had to have a way for a distro-specific default string. If the other distributions adopt our policies it would be shared code.

> Beginning with Fedora 25, libsoup no longer uses the fallback mode (because
> major browsers are dropping the fallback), so this won't affect most GNOME
> stuff. But it's still offered by glib-networking, so I guess we should add
> use of %FALLBACK_SCSV to make it safer. (I didn't realize GnuTLS supported
> that extension.) I guess we need to check the version of GnuTLS in use to
> determine whether that's OK to use in the priority string, right?

Correct. (the version this was introduced is 3.4.4)

> 
> > >  * Lastly, for downstreams of glib-networking: WebKit adds
> > > !VERS-SSL3.0:!ARCFOUR-128 to the priority strings. I guess we'll have to
> > > keep doing that forever, as even if the Fedora policy disables those (does
> > > it?)
> > 
> > Yes since F23.
> OK, good for Fedora, but now what about other distros -- what about NORMAL?
> We have to think about other distros too. If NORMAL still allows insecure
> things, then we'll have to keep setting the priority string manually
> upstream, and patch it out of WebKit in Fedora, which would be unfortunate.

SSL3.0 and rc4 are disabled since 3.4.0 for gnutls. Older versions may or may not have them disabled (it's a compile time flag).

> Mostly because I'm concerned you'll have compatibility concerns. If I
> remember correctly, GnuTLS in Fedora was quite late in disabling SSLv3; that
> didn't happen until the next stable Fedora release, right? I presume the
> system policy change was slow because of the risk of breaking a bunch of
> applications, but WebKit needed the policy change immediately.

Note that the compatibility concerns you can handle on top of the system-wide policy. You can always use @SYSTEM at downstream with all the required options appended (e.g., add %COMPAT and remove ciphers such as ones the banned by HTTP/2).

(In reply to Nikos Mavrogiannopoulos from comment #5)
> Yes, but that should be a downstream patch as you mentioned. Note that if
> you are doing unsafe fallbacks you should also set the %FALLBACK_SCSV option
> on the downgraded session (available since 3.4). However, since all browsers
> are dropping fallbacks it may make sense to plan for removing that code.

Thinking about this more, I think we should not use %FALLBACK_SCSV, because we don't know how applications might be using fallback mode. If an app enables fallback mode from the start, then this could totally break that app.

Hey Nikos, I going to change our DEFAULT_BASE_PRIORITY from "NORMAL:%COMPAT:%LATEST_RECORD_VERSION" to "@SYSTEM:%COMPAT:%LATEST_RECORD_VERSION" with a downstream patch. That should work for you, right? I don't think we want to give us %COMPAT:%LATEST_RECORD_VERSION as those fixed web sites in the past.

Keep in mind that various applications (I'm aware of WebKit, Midori, Xombrero, and Geary) override this by setting the G_TLS_GNUTLS_PRIORITY environment variable and so they will still not use the system priority. I'll take care of WebKit; you might want to file bugs for the rest.