Stitched vs non-Stitched Ciphersuites

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Stitched vs non-Stitched Ciphersuites

OpenSSL - User mailing list
The latest security advisory:

https://www.openssl.org/news/secadv/20190226.txt

mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate on which ciphersuites are stitched and non-stitched.

"In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites."

Can someone give some examples of both?

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

Matt Caswell-2


On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
> The latest security advisory:
>
> https://www.openssl.org/news/secadv/20190226.txt
>
> mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate on
> which ciphersuites are stitched and non-stitched.

The actual list in use is platform specific - the stitched ciphers are based on
asm implementations. Libssl in 1.0.2 knows about these stitched ciphers:

https://github.com/openssl/openssl/blob/56ff0f643482b19f7b2d7ed532dfb94ed3a4e294/ssl/ssl_ciph.c#L651-L671

Any TLS ciphersuite based on the above ciphers will use the stitched
implementation if it is available on that platform.

So, for example, if a stitched implementation of AES-128-CBC-HMAC-SHA1 is
available on your platform then it will be used if you negotiate the AES128-SHA
ciphersuite (aka TLS_RSA_WITH_AES_128_CBC_SHA). Similarly it will be used if you
negotiate DH-RSA-AES128-SHA (aka TLS_DH_RSA_WITH_AES_128_CBC_SHA) The combined
encrypt and mac operation will be performed in one go by the stitched
implementation. If you don't have a stitched implementation then the encrypt and
mac operations are performed individually.

Matt


>
>> "In order for this to be exploitable "non-stitched" ciphersuites must be in
>> use. Stitched ciphersuites are optimised implementations of certain commonly
>> used ciphersuites."
>
> Can someone give some examples of both?
>
> --
> -Todd Short
> // [hidden email] <mailto:[hidden email]>
> // "One if by land, two if by sea, three if by the Internet."
>
Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

OpenSSL - User mailing list
Thanks Matt, 

So, just the cipher+MAC matter, the authentication/key-exchange are irrelevant.

What about AEAD ciphers? Are they considered "stitched"?

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Feb 26, 2019, at 10:40 AM, Matt Caswell <[hidden email]> wrote:



On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
The latest security advisory:

https://www.openssl.org/news/secadv/20190226.txt

mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate on
which ciphersuites are stitched and non-stitched.

The actual list in use is platform specific - the stitched ciphers are based on
asm implementations. Libssl in 1.0.2 knows about these stitched ciphers:

https://github.com/openssl/openssl/blob/56ff0f643482b19f7b2d7ed532dfb94ed3a4e294/ssl/ssl_ciph.c#L651-L671

Any TLS ciphersuite based on the above ciphers will use the stitched
implementation if it is available on that platform.

So, for example, if a stitched implementation of AES-128-CBC-HMAC-SHA1 is
available on your platform then it will be used if you negotiate the AES128-SHA
ciphersuite (aka TLS_RSA_WITH_AES_128_CBC_SHA). Similarly it will be used if you
negotiate DH-RSA-AES128-SHA (aka TLS_DH_RSA_WITH_AES_128_CBC_SHA) The combined
encrypt and mac operation will be performed in one go by the stitched
implementation. If you don't have a stitched implementation then the encrypt and
mac operations are performed individually.

Matt



"In order for this to be exploitable "non-stitched" ciphersuites must be in
use. Stitched ciphersuites are optimised implementations of certain commonly
used ciphersuites."

Can someone give some examples of both?

--
-Todd Short
// [hidden email] <mailto:[hidden email]>
// "One if by land, two if by sea, three if by the Internet."


Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

Matt Caswell-2


On 26/02/2019 15:44, Short, Todd wrote:
> Thanks Matt, 
>
> So, just the cipher+MAC matter, the authentication/key-exchange are irrelevant.
>
> What about AEAD ciphers? Are they considered "stitched"?

No, they are not "stitched" but they are not impacted by this issue. We should
probably make that clearer in the advisory.

Matt


>
> --
> -Todd Short
> // [hidden email] <mailto:[hidden email]>
> // "One if by land, two if by sea, three if by the Internet."
>
>> On Feb 26, 2019, at 10:40 AM, Matt Caswell <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>
>> On 26/02/2019 15:03, Short, Todd via openssl-users wrote:
>>> The latest security advisory:
>>>
>>> https://www.openssl.org/news/secadv/20190226.txt
>>>
>>> mentions stitched vs. non-stitched ciphersuites, but doesn’t really elaborate on
>>> which ciphersuites are stitched and non-stitched.
>>
>> The actual list in use is platform specific - the stitched ciphers are based on
>> asm implementations. Libssl in 1.0.2 knows about these stitched ciphers:
>>
>> https://github.com/openssl/openssl/blob/56ff0f643482b19f7b2d7ed532dfb94ed3a4e294/ssl/ssl_ciph.c#L651-L671
>>
>> Any TLS ciphersuite based on the above ciphers will use the stitched
>> implementation if it is available on that platform.
>>
>> So, for example, if a stitched implementation of AES-128-CBC-HMAC-SHA1 is
>> available on your platform then it will be used if you negotiate the AES128-SHA
>> ciphersuite (aka TLS_RSA_WITH_AES_128_CBC_SHA). Similarly it will be used if you
>> negotiate DH-RSA-AES128-SHA (aka TLS_DH_RSA_WITH_AES_128_CBC_SHA) The combined
>> encrypt and mac operation will be performed in one go by the stitched
>> implementation. If you don't have a stitched implementation then the encrypt and
>> mac operations are performed individually.
>>
>> Matt
>>
>>
>>>
>>>> "In order for this to be exploitable "non-stitched" ciphersuites must be in
>>>> use. Stitched ciphersuites are optimised implementations of certain commonly
>>>> used ciphersuites."
>>>
>>> Can someone give some examples of both?
>>>
>>> --
>>> -Todd Short
>>> // [hidden email] <mailto:[hidden email]>
>>> // "One if by land, two if by sea, three if by the Internet."
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

Sam Roberts
On Tue, Feb 26, 2019 at 8:42 AM Matt Caswell <[hidden email]> wrote:
> > What about AEAD ciphers? Are they considered "stitched"?
>
> No, they are not "stitched" but they are not impacted by this issue. We should
> probably make that clearer in the advisory.

That would be helpful!

Even though this is fixed, would the general advice still be "avoid
CBC in favour of AESCCM and AESGCM when using TLS1.2"? Or update to
TLS1.3.
Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

Matt Caswell-2


On 27/02/2019 16:33, Sam Roberts wrote:
> On Tue, Feb 26, 2019 at 8:42 AM Matt Caswell <[hidden email]> wrote:
>>> What about AEAD ciphers? Are they considered "stitched"?
>>
>> No, they are not "stitched" but they are not impacted by this issue. We should
>> probably make that clearer in the advisory.
>
> That would be helpful!

It has been updated:

https://www.openssl.org/news/secadv/20190226.txt

>
> Even though this is fixed, would the general advice still be "avoid
> CBC in favour of AESCCM and AESGCM when using TLS1.2"? Or update to
> TLS1.3.

IMO, and in order:
- TLSv1.3 is preferable to TLSv1.2
- in TLSv1.2 forward secret ciphersuites are preferable to non-forward secret ones
- in TLSv1.2 using an AEAD based ciphersuite is preferable to a CBC one

Probably there is a whole bunch of other stuff that should be added to that list
- but I'm sure others will chip in with their advice :-)

Matt
Reply | Threaded
Open this post in threaded view
|

RE: Stitched vs non-Stitched Ciphersuites

Michael Wojcik
In reply to this post by Sam Roberts
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Sam Roberts
> Sent: Wednesday, February 27, 2019 11:33
>
> Even though this is fixed, would the general advice still be "avoid
> CBC in favour of AESCCM and AESGCM when using TLS1.2"? Or update to
> TLS1.3.

The general advice is to avoid CBC mode where possible, full stop. Too many deployed implementations are still vulnerable to one form or another of padding-oracle attacks. Unless you control both ends of the conversation, you can't guarantee the peer isn't vulnerable.

Frankly, this latest vulnerability in OpenSSL 1.0.2 feels pretty minor in that regard, since it depends on two different (if related) behaviors by the application to be vulnerable. The application has to incorrectly attempt a second SSL_shutdown if the first one fails (it should only do the second if the first succeeds), and it has to have different behavior that's visible to the attacker for the two cases, in order to be a useful oracle. AND it has to be using a non-stitched implementation of a vulnerable cipher.

It's a relatively narrow branch of the attack tree.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

Matt Caswell-2


On 27/02/2019 16:47, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Sam Roberts Sent: Wednesday, February 27, 2019 11:33
>>
>> Even though this is fixed, would the general advice still be "avoid CBC in
>> favour of AESCCM and AESGCM when using TLS1.2"? Or update to TLS1.3.
>
> The general advice is to avoid CBC mode where possible, full stop. Too many
> deployed implementations are still vulnerable to one form or another of
> padding-oracle attacks. Unless you control both ends of the conversation, you
> can't guarantee the peer isn't vulnerable.
>
> Frankly, this latest vulnerability in OpenSSL 1.0.2 feels pretty minor in
> that regard, since it depends on two different (if related) behaviors by the
> application to be vulnerable. The application has to incorrectly attempt a
> second SSL_shutdown if the first one fails (it should only do the second if
> the first succeeds),

This is not quite correct. It requires you to incorrectly call SSL_shutdown()
twice (once to send a close_notify, and once to receive one) having previously
encountered a fatal error.

For example if you call SSL_read() which returns <=0 and SSL_get_error() returns
SSL_ERROR_SYSCALL or SSL_ERROR_SSL then a fatal error has occurred. You should
*not* then attempt to call SSL_shutdown().

Matt
Reply | Threaded
Open this post in threaded view
|

RE: Stitched vs non-Stitched Ciphersuites

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Matt Caswell
> Sent: Wednesday, February 27, 2019 12:07
>
> On 27/02/2019 16:47, Michael Wojcik wrote:
> >
> > Frankly, this latest vulnerability in OpenSSL 1.0.2 feels pretty minor in
> > that regard, since it depends on two different (if related) behaviors by the
> > application to be vulnerable. The application has to incorrectly attempt a
> > second SSL_shutdown if the first one fails (it should only do the second if
> > the first succeeds),
>
> This is not quite correct. It requires you to incorrectly call SSL_shutdown()
> twice (once to send a close_notify, and once to receive one) having previously
> encountered a fatal error.

Thanks for the correction. Still the general point applies: it depends on the application having rather suspect error handling, and on having visibly different behavior for the two cases in order to provide an oracle.

Perhaps that's not uncommon, but I checked some of our products which use OpenSSL, and they didn't have either behavior.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: Stitched vs non-Stitched Ciphersuites

Sam Roberts
In reply to this post by Matt Caswell-2
On Wed, Feb 27, 2019 at 8:42 AM Matt Caswell <[hidden email]> wrote:
> On 27/02/2019 16:33, Sam Roberts wrote:
> > That would be helpful!
>
> It has been updated:

Thank you, that is helpful.