Re: [openssl-dev] cipher order

[Emilia Käsper]

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

[Jeffrey Walton]

> 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

[Viktor Dukhovni]

> 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

[Emilia Käsper]

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

[Emilia Käsper]

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

[Blumenthal, Uri - 0553 - MITLL]

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

[Hanno Böck]

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

[Emilia Käsper]

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

[Blumenthal, Uri - 0553 - MITLL]

+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

[openssl-dev] cipher order

[Hanno Böck]

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


pgp9aiNaxHyXU.pgp
Description: OpenPGP digital signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev