Re: [openssl-dev] cipher order
On Fri, Mar 4, 2016 at 11:00 PM Viktor Dukhovni wrote: > > > On Mar 4, 2016, at 3:57 PM, Emilia Käsper wrote: > > > > I've updated the pull to do a much more substantial cleanup. > > What will @STRENGTH mean in this context? Will ignore > the distinction between AES256 and AES128? @STRENGTH will sort it back by symmetric encryption key strength. Which is a bit of a bummer but I have no good answer for how to avoid it, because this is what @STRENGTH's contract promises to do. What does this > do to the @SECLEVEL interface which tries to provide > NIST-compatible bit strengths across multiple features? > @SECLEVEL will continue to work as expected, i.e., it will filter out the ones that don't meet the level. (@SECLEVEL operates directly on the cert, and does nothing to the cipherlist alone. Which results in misleading output from the 'ciphers' app, but that is a separate bug.) > > Or we just changing the default order, and allowing > @STRENGTH to perturb it back, and @SECLEVEL to prune-away > 128 leaving just 256, ... > > In other words how does this fit into the larger picture? The ordering affects lists built from the predefined groups - ALL, DEFAULT, HIGH, MEDIUM, LOW etc. More generally, it sorts each cipher group separated by the ':'. For example, if you do 'CAMELLIA:AES' then you get CAMELLIA ciphers sorted by this preference, followed by AES ciphers sorted by this preference., and if you do 'CAMELLIA:AES@STRENGTH' then - sadly - you get the symmetric strength-sort back. We could add a variant of @STRENGTH that re-sorts by our internal implicit preferences (which we're allowed to change at any time), but that's not going to happen for 1.1.0. It is, however, possible, to achieve the same effect in multiple ways already: - start from DEFAULT, and remove more ciphers, e.g. "DEFAULT:!3DES:!AES128" - Or, if you want a superset of DEFAULT, start from ALL, and remove some ciphers: "ALL:!MEDIUM:!LOW:!aNULL:!eNULL:!IDEA:!SEED" Both of these operations will preserve the preferences. Anyway, the goal here is to improve the situation *if the user does nothing*. It does not solve all the other problems of the API, but it does not make them worse. Emilia > -- > Viktor. > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
> Browsers have largely decided to implement GCM-modes only with AES128. > Chrome is now about to change that. Not sure if other browsers will > follow. > > Right now if you configure a server with openssl's cipher suite > ordering it is likely that a connection will happen with AES256 in CBC > mode instead of the (most likely more secure) AES128 in GCM mode. The standard does not specify whether the client selects the cipher or the server selects the cipher. OpenSSL servers yield to the client's preference. That is, the server attempts to match the clients first preference, then the second preference, and so on. If you control the server's configuration, then order them how you see fit. Then use SSL_OP_CIPHER_SERVER_PREFERENCE context option to ensure the server's preference for ciphers are used. Jeff -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
> On Mar 4, 2016, at 3:57 PM, Emilia Käsper wrote: > > I've updated the pull to do a much more substantial cleanup. What will @STRENGTH mean in this context? Will ignore the distinction between AES256 and AES128? What does this do to the @SECLEVEL interface which tries to provide NIST-compatible bit strengths across multiple features? Or we just changing the default order, and allowing @STRENGTH to perturb it back, and @SECLEVEL to prune-away 128 leaving just 256, ... In other words how does this fit into the larger picture? -- Viktor. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
I've updated the pull to do a much more substantial cleanup. On Thu, Mar 3, 2016 at 6:16 PM Emilia Käsper wrote: > Hm, I think that I actually agree. But David's done enough, so I'll have a > look myself. > > On Thu, Mar 3, 2016 at 5:33 PM Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote: > >> On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck" >> wrote: >> >> >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper >> >wrote: >> >>https://github.com/openssl/openssl/pull/783 >> > >> >This is different from what I had in mind. >> >... >> >I would argue that cbc/hmac is so fragile that it's always preferrable >> >to have aead before cbc/hmac. The security difference between 128 and >> >256 bit aes is imho mostly irrelevant in practice. >> >> Again, +1 >> >> Perhaps David can do his magic again? :-) >> -- >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
Hm, I think that I actually agree. But David's done enough, so I'll have a look myself. On Thu, Mar 3, 2016 at 5:33 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck" > wrote: > > >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper > >wrote: > >>https://github.com/openssl/openssl/pull/783 > > > >This is different from what I had in mind. > >... > >I would argue that cbc/hmac is so fragile that it's always preferrable > >to have aead before cbc/hmac. The security difference between 128 and > >256 bit aes is imho mostly irrelevant in practice. > > Again, +1 > > Perhaps David can do his magic again? :-) > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck" wrote: >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper >wrote: >>https://github.com/openssl/openssl/pull/783 > >This is different from what I had in mind. >... >I would argue that cbc/hmac is so fragile that it's always preferrable >to have aead before cbc/hmac. The security difference between 128 and >256 bit aes is imho mostly irrelevant in practice. Again, +1 Perhaps David can do his magic again? :-) smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper wrote: > https://github.com/openssl/openssl/pull/783 This is different from what I had in mind. What this patch does is sort e.g. chacha/poly and aes256-gcm before aes256-cbc. It does however not sort aes128-gcm before aes256-cbc. (David Benjamin answered to me on the chrome security list that he wanted to avoid arguing about this and chose the lesser controversial variant.) I would argue that cbc/hmac is so fragile that it's always preferrable to have aead before cbc/hmac. The security difference between 128 and 256 bit aes is imho mostly irrelevant in practice. The difference between the two approaches may become mostly irrelevant once all major browsers support at least one aead mode with 256 bit, but I'm not sure if that's going to happen any time soon. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpmJ5ws0YpN1.pgp Description: OpenPGP digital signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
https://github.com/openssl/openssl/pull/783 Courtesy of David Benjamin. On Thu, Mar 3, 2016 at 4:34 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > +1 > > Sent from my BlackBerry 10 smartphone on the > Verizon Wireless 4G LTE network. > Original Message > From: Hanno Böck > Sent: Thursday, March 3, 2016 07:28 > To: openssl-dev@openssl.org > Reply To: openssl-dev@openssl.org > Subject: [openssl-dev] cipher order > > Hi, > > Last year I proposed to change the ciphering order in OpenSSL to always > prefer AEAD cipher suites before CBC/HMAC-based ones: > https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html > > I just checked openssl 1.1.0 alpha and it still orders ciphers in an > imho problematic way. > > Browsers have largely decided to implement GCM-modes only with AES128. > Chrome is now about to change that. Not sure if other browsers will > follow. > > Right now if you configure a server with openssl's cipher suite > ordering it is likely that a connection will happen with AES256 in CBC > mode instead of the (most likely more secure) AES128 in GCM mode. > > Can this be changed before 1.1.0 gets out? > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: BBB51E42 > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] cipher order
+1 Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Hanno Böck Sent: Thursday, March 3, 2016 07:28 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: [openssl-dev] cipher order Hi, Last year I proposed to change the ciphering order in OpenSSL to always prefer AEAD cipher suites before CBC/HMAC-based ones: https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html I just checked openssl 1.1.0 alpha and it still orders ciphers in an imho problematic way. Browsers have largely decided to implement GCM-modes only with AES128. Chrome is now about to change that. Not sure if other browsers will follow. Right now if you configure a server with openssl's cipher suite ordering it is likely that a connection will happen with AES256 in CBC mode instead of the (most likely more secure) AES128 in GCM mode. Can this be changed before 1.1.0 gets out? -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev