Honor Cipher Order

[Daniel Kahn Gillmor]

​imported from mantis:

benbe said:

mod_gnutls should honor the order in which ciphers are added in the priority string. There should be a switch to turn this behaviour off. (Cf. ​SSLHonorCipherOrder from mod_ssl)

[Daniel Kahn Gillmor]

on 2013-02-01, dkg wrote:

benbe, can you explain what you mean by this report? the priority string is a GnuTLS convention that allows the operator of a tool that uses the library to pass a specific set of config choices through explicitly to the library.

If you think the library isn't honoring your choices for the priority string, that's a report that should probably be passed to GnuTLS upstream. If the problem is that mod_gnutls isn't passing through the configured priority string to the library untouched, then that's something we should fix in mod_gnutls.

If you're not sure which is the case, can you give a specific example of a scenario where mod_gnutls does not behave as you expect, and describe what you'd expect it to do differently?

on 2013-02-23, dash wrote:

I have to agree with [dkg] here, there's not much else the module can do, it is the responsibility of the underlying GnuTLS library to honor the priority-string given to it. If there is a need to switch this functionality completely off and have the library behave as default, one can use a priority string of "NORMAL" AFAIK.

Please follow this up and elaborate on your initial request.

[...]

Expecting your input...

on 2013-02-23, benbe replied:

When you specify a priority string with mod_ssl it prioritizes the ciphers in the order they are given in the configuration string. Thus ciphers named first are selected over others when there's client support for them. For mod_ssl the server here selects the cipher by sending its preference alongside its list of supported ciphers. In contrast, mod_gnutls only announces its supported ciphers and the client chooses any of the server-supported ones with no preference transmitted.

It's not clear if this is an issue with GnuTLS itself (documentation isn't really clear about this) or if it's only mod_gnutls that's lacking support for some needed flags that have to be set for some cipher preference to be transmitted.

For an example I'd recommend having a look at the BEAST attack where a mitigation is prioritizing TLS1.2+ over other older ciphers from the TLS1.0/TLS1.1 set while disallowing certain cihers from being selected. While TLS 1.2 usually is preferred over TLS1.0 and TLS1.1 some algorithms like RC4 are not. Thus doing something like "NONE:TLS1.2:+RC4:+TLS1.1:+TLS1.0" (just an example) would usually mitigate the BEAST attack, but isn't honored in the way you'd intend when specifying it this way: GnuTLS will happily setup a TLS1.1 cipher even if RC4 should have been preferred instead.

on 2013-03-12, dash wrote:

Before I involve Nikos [From GnuTLS] and bother him unnecessarily, please try ​this configuration of mod_gnutls' Priority-String, it should mitigate the BEAST SSL attack?

It should work with the trunk version.

on 2013-03-26, dash wrote:

Will implement this hopefully in the next major version.

This should be an additional config layer that compliments GnuTLS' Priority Strings.

[Nikos Mavrogiannopoulos]

Note that there is also the %SERVER_PRECEDENCE priority string which prioritizes the selection of ciphersuites in the server side, instead of the client side (which is the default and what the TLS protocol mandates).

​http://gnutls.org/manual/html_node/Priority-Strings.html