Re: [openssl-users] openSSL and SLOTH attack

[Jeffrey Walton]

> So here are the things mentioned in the paper:
> 1) Some things that were believed to require preimage resistance
>need collision resistance.  This by itself reduces security bits
>of the hashes by a factor 2.  Assuming MD5 and SHA1 didn't have
>any problem with collision resistance it would be reduced from
>128 and 160 bit to 64 and 80.  But they have a problem with
>collision resistance and so it's worse, specially for MD5.
> 2) Some implementations support MD5 based signatures in TLS 1.2
> 3) Some implementations accept the MD5 based signatures in TLS 1.2
>while it would appear they didn't.
>
> SLOTH really is just about 1).  It says that you should stop using
> MD5 and really look at stopping to use SHA1.  And so 2) and 3) are
> just 2 cases where MD5 is used.
>
> But just fixing 2) and 3) is just fixing the problem with MD5,
> while we should also look at stopping SHA1.  TLS 1.0 and 1.1 use
> MD5 + SHA1, so while those are enabled we're stuck at the level of
> SHA1.

Forgive my ignorance... Aren't these two different application of the
hash? The latter, TLS 1.0 and 1.1, is approved when they are used as
the PRF.

Is the PRF in danger? (I only skimmed the paper, but I did not get the
impression the PRF was in jeopardy).

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Kurt Roeckx]

On Mon, Jan 11, 2016 at 09:38:05PM +0100, Jakob Bohm wrote:
> On 08/01/2016 18:43, Salz, Rich wrote:
> >Are you going to keep posting and posting until you get a response? :(
> >
> >Master branch, 1.1, is not released but will not be vulnerable (may already 
> >be fixed)
> >1.0.2 is not vulnerable.
> >1.0.1f and later are not vulnerable.
> >1.0.0 might be, and is end of life anyway so you should move of that.
> >0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable.
> If you read the description of SLOTH (linked in the OP), you
> will see that it is not limited to TLS 1.2 and probably
> affects the TLS/SSL versions implemented by older (end of
> life) OpenSSL versions such as 0.9.8.
> 
> Basically, it is a laundry list of ways that backward
> compatible hash uses in the SSL/TLS protocols are weaker
> than some people assume.  Their summary list doesn't even
> consider the possibility that some people still need to use
> TLS 1.1 or older, so barely mentions those.
> 
> This also means that completely protecting an
> implementation against SLOTH is not possible without
> breaking interoperability with implementations that
> are not or cannot be updated to the latest protocol
> versions and features (This happens to include some
> widely deployed embedded operating systems).
> 
> Now it so happens that SLOTH also includes an attack on
> implementation bugs that can be tricked into
> using/accepting MD5-based signatures when they shouldn't.
>  That *particular* aspect of SLOTH was apparently fixed
> in 1.0.1f and 1.0.2.
> 
> The entire discussion would have been easier if the SLOTH
> team at INRIA had given specific names and CVE ids for
> each of the issues in their report, such that one might say
> "SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3:
> hypothetical for now, can be fixed with a cipher string
> setting, etc. etc."  But no such names exist.

So here are the things mentioned in the paper:
1) Some things that were believed to require preimage resistance
   need collision resistance.  This by itself reduces security bits
   of the hashes by a factor 2.  Assuming MD5 and SHA1 didn't have
   any problem with collision resistance it would be reduced from
   128 and 160 bit to 64 and 80.  But they have a problem with
   collision resistance and so it's worse, specially for MD5.
2) Some implementations support MD5 based signatures in TLS 1.2
3) Some implementations accept the MD5 based signatures in TLS 1.2
   while it would appear they didn't.   

SLOTH really is just about 1).  It says that you should stop using
MD5 and really look at stopping to use SHA1.  And so 2) and 3) are
just 2 cases where MD5 is used.

But just fixing 2) and 3) is just fixing the problem with MD5,
while we should also look at stopping SHA1.  TLS 1.0 and 1.1 use
MD5 + SHA1, so while those are enabled we're stuck at the level of
SHA1.


Kurt

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Jakob Bohm]

On 08/01/2016 18:43, Salz, Rich wrote:

Are you going to keep posting and posting until you get a response? :(

Master branch, 1.1, is not released but will not be vulnerable (may already be 
fixed)
1.0.2 is not vulnerable.
1.0.1f and later are not vulnerable.
1.0.0 might be, and is end of life anyway so you should move of that.
0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable.

If you read the description of SLOTH (linked in the OP), you
will see that it is not limited to TLS 1.2 and probably
affects the TLS/SSL versions implemented by older (end of
life) OpenSSL versions such as 0.9.8.

Basically, it is a laundry list of ways that backward
compatible hash uses in the SSL/TLS protocols are weaker
than some people assume.  Their summary list doesn't even
consider the possibility that some people still need to use
TLS 1.1 or older, so barely mentions those.

This also means that completely protecting an
implementation against SLOTH is not possible without
breaking interoperability with implementations that
are not or cannot be updated to the latest protocol
versions and features (This happens to include some
widely deployed embedded operating systems).

Now it so happens that SLOTH also includes an attack on
implementation bugs that can be tricked into
using/accepting MD5-based signatures when they shouldn't.
 That *particular* aspect of SLOTH was apparently fixed
in 1.0.1f and 1.0.2.

The entire discussion would have been easier if the SLOTH
team at INRIA had given specific names and CVE ids for
each of the issues in their report, such that one might say
"SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3:
hypothetical for now, can be fixed with a cipher string
setting, etc. etc."  But no such names exist.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Michael Sierchio]

"Since the HMAC is only 96 bits long, even a generic collision requires
only about 248 HMAC computations"

But a sequence/call-flow diagram is on the page Sandeep referenced:
http://www.mitls.org/pages/attacks/SLOTH

- M
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Michael Sierchio]

2^48. Which is larger than 248, which was a cut-and-paste error. ;-)

On Fri, Jan 8, 2016 at 11:00 AM, Michael Sierchio 
wrote:

> "Since the HMAC is only 96 bits long, even a generic collision requires
> only about 248 HMAC computations"
>
> But a sequence/call-flow diagram is on the page Sandeep referenced:
> http://www.mitls.org/pages/attacks/SLOTH
>
> - M
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Salz, Rich]

Are you going to keep posting and posting until you get a response? :(

Master branch, 1.1, is not released but will not be vulnerable (may already be 
fixed)
1.0.2 is not vulnerable.
1.0.1f and later are not vulnerable.
1.0.0 might be, and is end of life anyway so you should move of that.
0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Jeffrey Walton]

On Fri, Jan 8, 2016 at 2:00 PM, Michael Sierchio  wrote:
> 2^48. Which is larger than 248, which was a cut-and-paste error. ;-)

Right The bad guy should *not* be able to compute a MAC to perform
the forgery within TCP's 2MSL bound and TLS timers. However, there's a
keep alive the authors used in the past to basically make their attack
windows unbounded in time. From the earlier paper on Logjam
(http://weakdh.org/imperfect-forward-secrecy-ccs15.pdf):

TLS warning alerts. Web browsers tend to have shorter timeouts,
but we can keep their connections alive by sending TLS warning
alerts, which are ignored by the browser but reset the handshake
timer.

As far as I know, there's no interest in fixing it in the TLS working group.

Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Blumenthal, Uri - 0553 - MITLL]

What is the problem with truncated 96-bit HMAC value?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Jakob Bohm
Sent: Thursday, January 7, 2016 19:25
To: openssl-users@openssl.org
Reply To: openssl-users@openssl.org
Subject: Re: [openssl-users] openSSL and SLOTH attack

On 07/01/2016 23:06, jonetsu wrote:
Does this mean that running 1.01e in FIPS mode is protected regarding this
SLOTH attack ?
Does FIPS mode prevent use of MD5: Yes.

Does FIPS mode prevent insecure uses of SHA-1 (a FIPS 
algorithm): No.

Does FIPS mode prevent the SSL/TLS handshake from using 
96 bit truncated HMAC values: Probably not.

Does FIPS mode prevent use of the insecurely designed 
'tls-unique' feature: Probably not.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[jonetsu]

> Does FIPS mode prevent use of MD5: Yes.

> Does FIPS mode prevent insecure uses of SHA-1 (a FIPS
> algorithm): No.

> Does FIPS mode prevent the SSL/TLS handshake from using 96 bit
> truncated HMAC values: Probably not.

> Does FIPS mode prevent use of the insecurely designed
> 'tls-unique' feature: Probably not.

This is what I read so far, thanks for the confirmation.  1.01f though, will
be good, will it, FIPS mode or not ?




--
View this message in context: 
http://openssl.6102.n7.nabble.com/openSSL-and-SLOTH-attack-tp62055p62080.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Miriam Celi]

Hello again OpenSSL users,

I'm still trying to find out if the 1.0.2 and 1.0.0 branches are affected,
and if so which versions and if there are versions with fixes available.

Based on the changelog for the 1.0.2 branch
(http://openssl.org/news/cl102.txt), version 1.0.1f which contains the fix
was released (Jan 2014) prior to OpenSSL 1.0.2 (Jan 2015), so 1.0.2d should
contain the fix for this, but we are not sure about this and would like
confirmation on this. 

Based on the changelog for the 1.0.1
(https://www.openssl.org/news/cl101.txt) and 1.0.0
(http://openssl.org/news/cl100.txt) branches, version 1.0.1f was released
prior to 1.0.0r (Mar 2015), so 1.0.0r should contain the fix for this, but
again we are not sure and would like confirmation.

The detailed technical paper
(http://www.mitls.org/downloads/transcript-collisions.pdf) that was
published with the attack disclosure, describes a vector for an MD5 based
attack against TLS 1.0 and TLS 1.1. So, there's a possibility for an OpenSSL
1.0.0 version to be vulnerable.

Thanks for any additional information you can provide on this.

Regards,
Miriam 
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Jakob Bohm]

On 07/01/2016 23:06, jonetsu wrote:

Does this mean that running 1.01e in FIPS mode is protected regarding this
SLOTH attack ?

Does FIPS mode prevent use of MD5: Yes.

Does FIPS mode prevent insecure uses of SHA-1 (a FIPS
algorithm): No.

Does FIPS mode prevent the SSL/TLS handshake from using
96 bit truncated HMAC values: Probably not.

Does FIPS mode prevent use of the insecurely designed
'tls-unique' feature: Probably not.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[jonetsu]

Does this mean that running 1.01e in FIPS mode is protected regarding this
SLOTH attack ?





--
View this message in context: 
http://openssl.6102.n7.nabble.com/openSSL-and-SLOTH-attack-tp62055p62074.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openSSL and SLOTH attack

[Sandeep Umesh]

Hello users,

Is there any fixes available from openSSL community for the SLOTH attack - 

http://www.mitls.org/pages/attacks/SLOTH

or what are the  possible mitigation points?

Thanks
Sandeep


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Miriam Celi]

Michael Wojcik  writes:

> 
> As described on that web page, use OpenSSL 1.0.1f or later. That  prevents
the currently-practical SLOTH
> attack against RSA-MD5 client authentication.
> 
> If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably
not your biggest problem.
> 
> The authors recommend discontinuing use of MD5 and SHA-1 in general. So
does nearly everyone else. Really
> the risk of continuing to support MD5 and SHA-1 can only meaningfully be
evaluated in the context of your
> own threat model; but either you already know that, or you don't know what
your threat model is, in which
> case the safe move is to drop support for MD5 and SHA-1 as soon as you can.
> 

Are the 1.0.0 and 1.0.2 branches also affected? The article states that the
issue is present in openssl versions prior to 1.0.1f. If the issue is also
present in the 1.0.0 and 1.0.2 branches, will fixes be provided on those
branches to address the issue?

Thanks very much for your feedback.

Best regards,
Miriam

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openSSL and SLOTH attack

[Jakob Bohm]

On 07/01/2016 16:46, Michael Wojcik wrote:

As described on that web page, use OpenSSL 1.0.1f or later. That  prevents the 
currently-practical SLOTH attack against RSA-MD5 client authentication.

If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably not 
your biggest problem.

The authors recommend discontinuing use of MD5 and SHA-1 in general. So does 
nearly everyone else. Really the risk of continuing to support MD5 and SHA-1 
can only meaningfully be evaluated in the context of your own threat model; but 
either you already know that, or you don't know what your threat model is, in 
which case the safe move is to drop support for MD5 and SHA-1 as soon as you 
can.


The above is not a very accurate summary.

In particular, the following would be a clearer summary:

1. Whenever possible, configure both servers and clients
  to avoid using MD5 or SHA-1 alone.

2. My suggestion: If it is necessary to retain SHA-1
  support due to some correspondents stuck with older
  weak algorithms (looking at you Microsoft!), then
  isolate it as much as possible, e.g. with different
  certificates etc.

3. If possible, configure servers and clients to not
  choose encryption modes where the TLS handshake is
  confirmed using only 96 bits of the relevant HMAC.

4. Do not use the "official" tls-unique token to bind
  something to a TLS handshake, it is unsuited to purpose,
  even with the recent extension of its format.
   My suggestion:  Instead do a strong hash (SHA-256 or
  better) of the complete handshake (all handshake
  messages in both directions, including record headers).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users