Subject: Re: [TLS] draft-turner-ssl-must-not

From: Sean Turner <[email-masked]>
Date: Thu, 01 Jul 2010 17:06:35 -0400

Nikos Mavrogiannopoulos wrote:
> On Tue, Jun 29, 2010 at 7:15 PM, Nikos Mavrogiannopoulos
> <[email-masked]> wrote:
> 
>> For SSL 3.0:
>> * The main argument for SSL 3.0 is that it uses MD5 in the KDF which is
>> not collision resistant and pre-image resistant.
>> I don't think this is clear. I'd explicit mention the finished message
>> calculation, rather than the KDF, since in general a KDF does not really
>> need to be collision resistant and pre-image resistant, whilst the
>> algorithm used for the Finished messages needs to be.
> 
> To add to this, it seems that the SSL3 variation of HMAC is used in
> the finished messages, thus collision resistance and pre-image
> resistance might not even be relevant.

So this is pretty much what I was afraid of.  When you get back we 
should talk about this.

spt

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 02 Jul 2010 01:35:05 +0200

On Tue, 29 Jun 2010 19:15:06 +0200, Nikos Mavrogiannopoulos  
<[email-masked]> wrote:

> I just found out about:
> http://www.ietf.org/id/draft-turner-ssl-must-not-01.txt

I definitely agree that SSL v2 and v3 should be phased out.

Opera have already completely removed its support for SSL v2. The protocol  
was disabled by preference from v8.0, then disabled at code level in v9.0,  
and the code was completely removed in v9.50 (two years ago), when we  
introduced TLS 1.2 support.

Regarding SSL v3, Opera by default tries to negotiate TLS 1.0 in its first  
attempts to connect to a server, falling back to SSL v3 only if it is  
necessary. From Opera 10.0 we also have the ability to auto update Opera  
installation to warn about, or disable, SSL v3.

As mentioned earlier, my prober results currently indicate that 1.6% of  
deployed servers are SSL v3-only (the number for renego patched is about  
0.4%).

At present, as of Opera 10.50, Opera will always signal TLS 1.2 to servers  
that are renego patched, and will not fall back if the server is version  
intolerant. We will also attempt to signal TLS 1.2 to unpatched servers,  
but after testing each version before it, in order to handle version  
intolerance problems.

I understand that this document is about obsolete SSL/TLS versions, but I  
wonder if it would be possible to also give recommendations about  
ciphersuites that implementations should not support? I am particularly  
thinking about the export and DES cipher suites (which are deprecated in  
recent TLS versions), as well as the RSA_RC4_MD5 cipher suite.

I have actually seen requests from some of our users that we disable the  
RSA RC4_MD5 cipher suite due to its use of MD5, and I even tried to do so  
before receiving request, and was unable to do so because at least one  
major Norwegian credit card processing site (the VISA 3D Secure server)  
only supports this particular cipher suite in the 128+ bit range. When I  
asked, I got the distinct impression that this configuration was required  
by Visa, though I was never directly told so.

At present, my prober indicates that 0.9% of servers only support this  
ciphersuite.

I would very much prefer that this document, or another, specifically make  
recommendations that deprecates the MD5 ciphersuites.

Regarding TLS 1.2, the problem with getting it deployed is that MS Windows  
Server 2008 and Windows 7 have disabled it by default, both for clients  
and servers. The result is that the publicly available servers with TLS  
1.2 enabled can probably be counted on one hand, or at most two (I am just  
aware of 3 or 4 servers).

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Fri, 2 Jul 2010 02:50:55 +0200 (MEST)

Yngve Nysaeter Pettersen wrote:
> I definitely agree that SSL v2

Phasing out SSLv2 is fine with me.  When we acquired our OEM SSL
implementation 10 years ago, it did not support SSLv2 and I
remember only 2 support calls from customers who had to look
for workarounds with some of their old equipment.

>
> and v3 should be phased out.

I have not yet seen any convincing technical argument that there is
any real and serious problem with SSLv3.  For the timing attack issues
we could easily get fixes on the existing maintenance contract years
ago with zero risk of interop problems to the installed base.

Never shipping a questionable feature such as SSLv2 is magnitudes
easier than disabling an essential feature in an large installed base
that is 10 years old and where a significant fraction supports only
SSLv3.

To me, the reasoning in the current draft for disabling SSLv3 support
is insufficient.  I'm not able to justify breaking any currently running
setups at customer sites with such a poor explanation.

> RSA RC4_MD5 cipher suite due to its use of MD5,

I'm somewhat confused by the wording.

It should be possible and documented for users of the technology
to configure the subset of available cipher suites from those that
are implemented.  With Opera 8.54 I can select cipher suites individually.

Was this about customers (that ship Opera with their products) that
want to have the set of cipher suite changed that are permitted by default
rather than (end) users?

> recommendations that deprecates the MD5 ciphersuites.

Since we are aware about interop problems, we should be very careful
about recommendations to switch off features without BIG WARNING signs
unless there are convincing arguments why consumers of the technology
would want to disable the feature anyway and face the burden of fixing
all resulting interop problems with the installed base on a case-by-case
basis.

> aware of 3 or 4 servers).

Does anyone know the rationale why the _servers_ on Server 2008 and
Windows 7 have TLSv1.2 disabled?  Lack of confidence?  lack of seperate
configuration for TLS client and server side?  Any chance for improvement
through WindowsUpdate?

I can imagine why you would not want to use it on clients unless the
app on top of TLS is prepared to deal with resulting interop problems by
retrying with an older protocol version after each failure, and by
somehow caching the fact of the failure for a short amount of time
because of the performance&latency penalty this fail-back mode imposes.

IMHO the use of SSLv3 is by far not the weakest link in the chain
of our application security.  The lessen learned from rfc5746 is that
while there may be iterative improvements in TLSv1.2 over previous
versions, there is nothing ground-breaking either.  And TLSv1.2
turned out to be just as vulnerable to the TLS renegotiation
vulernability as SSLv3.

Maybe the problem isn't so much with SSLv3 or TLSv1.0 itself,
but rather with the level of expectation on the part of the PKIX folks.
An implementation of SSLv3 and TLSv1.0 maybe much closer to
rfc-2459 than to rfc-3280 or rfc-5280, while there might be a
silent expectation that whoever adds TLSv1.1 and TLSv1.2
is also going to upgrade from rfc-2459 to rfc-5280, and the
latter might be a much larger effort than the TLS protocol
changes alone.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 02 Jul 2010 16:00:00 +1200

>introduced TLS 1.2 support.

Just out of curiosity, does it still send an SSLv2-compatible ClientHello or
does it start straight off with the SSLv3 one?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 02 Jul 2010 16:05:17 +1200

Martin Rex <[email-masked]> writes:

>Does anyone know the rationale why the _servers_ on Server 2008 and Windows 7
>have TLSv1.2 disabled?

I'd guess it was concerns about being the test load for every currently-
untested TLS 1.2 implementation out there on one side and no good reason for
enabling it on the other.

Peter.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 02 Jul 2010 10:41:33 +0200

> does it start straight off with the SSLv3 one?

As I recall, we have not been using the SSLv2 hello mode since v9.0, when  
we enabled TLS 1.1 and extension support by default. At the very least it  
has not been possible to do so since v9.50.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 2 Jul 2010 10:50:01 +0200

> I definitely agree that SSL v2 and v3 should be phased out.
[...]
> recent TLS versions), as well as the RSA_RC4_MD5 cipher suite.

About the Export ciphersuites I totally agree. Is there any use of
them today? I can only think of really legacy software that uses them.
The RSA_RC4_MD5 ciphersuite however is not the best ciphersuite out
there, but I wouldn't call it insecure. HMAC-MD5 (and not MD5) are
used for authentication and I am not aware of any attacks against this
construction. Attacks against RC4 have been found that might recover
the key, but do not to seem practical with TLS' usage of RC4. This
ciphersuite has however a very nice property. It is extremely fast
comparing to any other ciphersuite.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 02 Jul 2010 13:06:39 +0300

2.7.2010 2:35, Yngve Nysaeter Pettersen kirjoitti:
> Regarding SSL v3, Opera by default tries to negotiate TLS 1.0 in its 
> first attempts to connect to a server, falling back to SSL v3 only if 
> it is necessary. From Opera 10.0 we also have the ability to auto 
> update Opera installation to warn about, or disable, SSL v3.
>
> As mentioned earlier, my prober results currently indicate that 1.6% 
> of deployed servers are SSL v3-only (the number for renego patched is 
> about 0.4%).
>
> At present, as of Opera 10.50, Opera will always signal TLS 1.2 to 
> servers that are renego patched, and will not fall back if the server 
> is version intolerant. We will also attempt to signal TLS 1.2 to 
> unpatched servers, but after testing each version before it, in order 
> to handle version intolerance problems.

Thank you for this explanation, I've tried Opera and noticed it changes 
the TLS version it tries to negotiate, but didn't find out how it 
actually determines the negotiated version. Now I see that it attempts 
to negotiate TLS 1.0 and later tries other versions. What I see with one 
server I tried is following:

- attempt to negotiate TLS 1.0 with TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
cipher suite and no extensions
- server replies with a renegotiation extension, client closes the 
connection immediately after server hello with close_notify
- attempt to negotiate TLS 1.0 with TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
cipher suite, "renegotiation_info" extension and some other extensions 
(this is NOT RECOMMENDED in RFC 5746 by the way)
- server replies with "renegotiation_info" extension and other supported 
extensions, client closes the connection immediately after server hello 
with close_notify
- attempt to negotiate TLS 1.2 (record layer version TLS 1.0) without 
TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite, with 
"renegotiation_info" extension and other extensions
- server hello is accepted and connection is negotiated with TLS 1.2 (if 
supported by the server), server capabilities are stored for later use

It seems like a lot of connection attempts here, and I'm curious to why 
Opera has chosen to disconnect twice? A quick guess would be to work 
around servers that support extensions correctly but fail with TLS 
versions higher than 1.0. I think the probing method Opera has used 
could be documented as well, if someone is interested in practical 
applications. :)

With a server that doesn't support extensions at all only the first two 
probes are performed and versions higher than TLS 1.0 are not 
negotiated, which seems to make sense. I guess if the second or third 
probe fail it will fall back to the last successful negotiation?

> I understand that this document is about obsolete SSL/TLS versions, 
> but I wonder if it would be possible to also give recommendations 
> about ciphersuites that implementations should not support? I am 
> particularly thinking about the export and DES cipher suites (which 
> are deprecated in recent TLS versions), as well as the RSA_RC4_MD5 
> cipher suite.
>
> I have actually seen requests from some of our users that we disable 
> the RSA RC4_MD5 cipher suite due to its use of MD5, and I even tried 
> to do so before receiving request, and was unable to do so because at 
> least one major Norwegian credit card processing site (the VISA 3D 
> Secure server) only supports this particular cipher suite in the 128+ 
> bit range. When I asked, I got the distinct impression that this 
> configuration was required by Visa, though I was never directly told so.
>
> I would very much prefer that this document, or another, specifically 
> make recommendations that deprecates the MD5 ciphersuites.

I understand that some people feel very strongly about the hash 
algorithms, but the only real way to deprecate a cipher suite is simply 
stop using it. If Visa really has decided to require that particular 
cipher suite, I'm not sure an RFC _recommending_ not to use it would 
make much difference. I very much doubt the MD5 attacks are new 
information to the people making security decisions, which means there 
must be other reasoning behind that.

Personally I would also like to see some data about how the MD5 attacks 
can be used against TLS as well, it would seem that breaking the cipher 
first before breaking the hash algorithm is necessary, and even after 
that it's not just a simple MD5 hash but HMAC instead. I don't count 
myself as an expert so maybe someone could enlighten me on this, but I 
see the attitude that we have to get rid of MD5 just because we have to 
get rid of MD5.

> Regarding TLS 1.2, the problem with getting it deployed is that MS 
> Windows Server 2008 and Windows 7 have disabled it by default, both 
> for clients and servers. The result is that the publicly available 
> servers with TLS 1.2 enabled can probably be counted on one hand, or 
> at most two (I am just aware of 3 or 4 servers).

This is an issue that should be solved in my opinion, TLS 1.2 
specification is already two years old and barely seen anywhere. I could 
imagine it has something to do with signature_algorithms extension, 
which is not completely trivial to add, but not compulsory either. 
What's the situation with GnuTLS and TLS 1.2 after the 2.10.0 release? 
The website still says it's disabled by default, but I can't see why it 
couldn't be enabled by default.

Juho

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 2 Jul 2010 12:49:29 +0200

On Fri, Jul 2, 2010 at 12:06 PM, Juho Vähä-Herttua <[email-masked]> wrote:
> This is an issue that should be solved in my opinion, TLS 1.2 specification
> is already two years old and barely seen anywhere. I could imagine it has
> something to do with signature_algorithms extension, which is not completely
> trivial to add, but not compulsory either. What's the situation with GnuTLS
> and TLS 1.2 after the 2.10.0 release? The website still says it's disabled
> by default, but I can't see why it couldn't be enabled by default.

It is enabled by default in 2.10.0, although I've noticed that most of
it's users just disable every version after TLS 1.0 (in some cases
even TLS 1.0). Oddly using SSL 3.0 has the broadest compatibility with
all the servers out there. Unfortunately there are incompatibilities
in TLS implementations, that as versions increase become a bigger
issue. There not TLS compliance test or so...

regards,
Nikos

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 02 Jul 2010 16:06:59 +0200

> (this is NOT RECOMMENDED in RFC 5746 by the way)

As mentioned earlier, we send the signaling cipher whenever we don't know  
if the server tolerates extensions, even if we are sending extensions.  
This only happen during the feature testing mode.

> extensions, client closes the connection immediately after server hello  
<snip>
> Opera has chosen to disconnect twice? A quick guess would be to work

Actually, the second attempt is a bug in the feature testing. Thanks for
noticing it.

Opera should have gone directly to TLS 1.2 in this case, but don't since
the extensions aren't checked until after that particular restart decision
is acted upon.

The first time we connect to a server the purpose is to establish whether
it supports TLS 1.0. If it doesn't, then we  continue the handshake. If it
does support TLS 1.0, we're not interested in establishing a connection
until we have also established whether or not extensions are supported,
and what is the highest supported version (which is established by
incrementing the version one step at a time). In the first step it is not
necessary to complete negotiation, in the rest it is necessary to complete
the negotiation up until the Finished messages has been verified (some  
types of
non-compliance can't be detected until that stage).

With renego, the plan was to establish capability in the first handshake,
but as mentioned a bug caused that check to be done on the second test  
instead. This capability is also coded so that even if it has established  
parameters previously, it will go to TLS 1.2 hellos immediately even if it  
is not in feature test mode.

> could be documented as well, if someone is interested in practical  

It is an attempt to work around non-compliance issues, and detect the  
feature configuration that works best with a given site.

This detection system is problematic, and causes quite a bit of overhead,  
and as soon as we can turn on the renego strict mode, the plan is to  
remove all the code related to it (which is why it is IMO important to  
make sure all TLS servers are version tolerant, also for currently  
hypothetical TLS versions).

> probe fail it will fall back to the last successful negotiation?

That's right, except for a special situation where the server incorrectly  
states that it supports a version it doesn't, because it mirrors the  
client's version number; I am aware of 49 such servers, about 20 of them  
actually cause issues for Opera because they are extension tolerant or for  
other reasons.

>> I understand that this document is about obsolete SSL/TLS versions, but  
>> I wonder if it would be possible to also give recommendations about  
>> thinking about the export and DES cipher suites (which are deprecated  
>> in recent TLS versions), as well as the RSA_RC4_MD5 cipher suite.
>>
>> the RSA RC4_MD5 cipher suite due to its use of MD5, and I even tried to  
>> do so before receiving request, and was unable to do so because at  
> algorithms,but the only real way to deprecate a cipher suite is simply   
> stop using it.

The basic problem is that 0.9% of servers I have tested only support this  
particular cipher suite (which is actually almost twice that of any other  
cipher suite that is the only one supported for a server).

A client can't in such cases stop supporting a feature, unless there is a  
very clear danger. That is why it took close to 10 years to get rid of SSL  
v2 or the export cipher suites.

> If Visa really has decided to require that particular cipher suite, I'm  
> not sure an RFC _recommending_ not to use it would

I have no idea whether Visa actually made that requirement, but I got that  
impression. (And also: why disable methods unless you either don't trust  
them, or you are ordered to?)

> see the attitude that we have to get rid of MD5 just because we have to  

Well, in my case, it is indeed mostly to get rid of the MD5 method, both  
because there are doubts about MD5, even though it is combined with HMAC  
in TLS 1.x, and because there are better cipher suites available (there  
are actually servers that select the MD5 variant before the SHA-1 variant).

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 02 Jul 2010 16:07:02 +0200

On Fri, 02 Jul 2010 10:50:01 +0200, Nikos Mavrogiannopoulos  
<[email-masked]> wrote:

>> I

There is still the RSA_RC4_SHA suite for that.

I don't know how the security of different keylengths for RC4 matches with  
the security of SHA-256, but is there a specific reason that RC4 does not  
have a SHA-256 variant in TLS 1.2?

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 02 Jul 2010 16:38:11 +0200

> are implemented.  With Opera 8.54 I can select cipher suites  

You can enable or disable all the cipher suites Opera support.

> want to have the set of cipher suite changed that are permitted by  

IIRC, this was at least one ordinary end user that wanted us to remove  
support for the cipher suite because of the weaknesses emerging in MD5

As mentioned, I had already tried that during the testing of 10.00, and  
had to back off when it turned out that it broke all online shopping sites  
in Norway when paying with Visa or Mastercard.

>> Windows

I'll leave it to MS to answer that question definitely, but my impression  
was that the server side decision related to performance concerns  
(SHA-256), the client one to interoperability.

But then, it took quite a few years before Microsoft turned on TLS 1.0 by  
default, Win XP IIRC.

---

From: Marsh Ray <[email-masked]>
Date: Fri, 02 Jul 2010 10:15:16 -0500

On 07/02/2010 09:06 AM, Yngve Nysaeter Pettersen wrote:
>> If Visa really has decided to require that particular cipher suite,
>> I'm not sure an RFC _recommending_ not to use it would
>
> I have no idea whether Visa actually made that requirement, but I got
> that impression. (And also: why disable methods unless you either don't
> trust them, or you are ordered to?)

Some other reasons one might disable a cipher suite:

Perhaps they consume additional CPU which you don't feel is justified by 
added security.

Perhaps you have dedicated hardware for some algorithms.

You might disable EDH because you like to be able to decrypt your packet 
captures later.

You might be replacing an existing system and wanting it to match the 
older one as closely as possible.

You might have a personal bias, superstition, or a commercial interest 
in promoting certain algorithms. (Hey, I didn't say these would all be 
good reasons :-)

- Marsh

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 2 Jul 2010 23:10:34 +0300

On 2.7.2010, at 17.06, Yngve Nysaeter Pettersen wrote:
>> - server replies with "renegotiation_info" extension and other supported extensions, client closes the connection immediately after server hello with close_notify
> <snip>
>> It seems like a lot of connection attempts here, and I'm curious to why Opera has chosen to disconnect twice? A quick guess would be to work
> 

Ok, this explains a lot, including the NOT RECOMMENDED part I mentioned. So the first connect is basically just for broken SSL 3.0 and TLS 1.0 servers that can't handle higher version numbers and/or extensions. 

>> around servers that support extensions correctly but fail with TLS versions higher than 1.0. I think the probing method Opera has used could be documented as well, if someone is interested in practical applications. :)
> 
> It is an attempt to work around non-compliance issues, and detect the feature configuration that works best with a given site.
> 
> This detection system is problematic, and causes quite a bit of overhead, and as soon as we can turn on the renego strict mode, the plan is to remove all the code related to it (which is why it is IMO important to make sure all TLS servers are version tolerant, also for currently hypothetical TLS versions).

I think we can agree on that one.

>> I understand that some people feel very strongly about the hash algorithms,but the only real way to deprecate a cipher suite is simply  stop using it.
> 
> The basic problem is that 0.9% of servers I have tested only support this particular cipher suite (which is actually almost twice that of any other cipher suite that is the only one supported for a server).
> 
> A client can't in such cases stop supporting a feature, unless there is a very clear danger. That is why it took close to 10 years to get rid of SSL v2 or the export cipher suites.

Also, having so many servers depending on it, recommending against its use is is more likely to cause problems than any other cipher suite. So should at least be careful with the wording, and probably make clear that it is not recommended to use RSA_RC4_MD5 cipher suite on the server side, but it might be a good idea to keep offering it when connecting as a client for backwards compatibility.

>> make much difference. I very much doubt the MD5 attacks are new information to the people making security decisions, which means there must be other reasoning behind that.
>> 
>> Personally I would also like to see some data about how the MD5 attacks can be used against TLS as well, it would seem that breaking the cipher first before breaking the hash algorithm is necessary, and even after that it's not just a simple MD5 hash but HMAC instead. I don't count myself as an expert so maybe someone could enlighten me on this, but I see the attitude that we have to get rid of MD5 just because we have to get rid of MD5.
> 
> Well, in my case, it is indeed mostly to get rid of the MD5 method, both because there are doubts about MD5, even though it is combined with HMAC in TLS 1.x, and because there are better cipher suites available (there are actually servers that select the MD5 variant before the SHA-1 variant).

Better is always subjective, I wouldn't be all that surprised if someone would have RSA_RC4_MD5 specific hardware somewhere, considering it's a combination that's been around for a very long time. And MD5 (not HMAC) needs to be kept in the algorithm stack anyway, at least until all the TLS implementations support at least version 1.2 or higher, which is not going to be any day soon. It may be ugly but it works...

Juho

---

From: Nasko Oskov <[email-masked]>
Date: Fri, 2 Jul 2010 20:37:55 +0000

>(SHA-256), the client one to interoperability.

Yngve is pretty much on the spot. For servers it is additional overhead and
for both sides it is compatability. 

TLS 1.1 and 1.2 are not actually disabled, rather, not enabled by default.
The distinction is that if an application wants to use TLS 1.2, they can
once they ask for it. It just doesn't get used if the app doesn't care about
the version. This is the most interoperable default configuration at the
time of release, which can be changed by admins/users at any point of time.

Thanks,
Nasko Oskov

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 03 Jul 2010 18:40:54 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>For SSL 3.0:
>* The main argument for SSL 3.0 is that it uses MD5 in the KDF which is not
>collision resistant and pre-image resistant.
>
>calculation, rather than the KDF, since in general a KDF does not really need
>to be collision resistant and pre-image resistant, whilst the algorithm used
>for the Finished messages needs to be.

Even then, you'd need to find a collision for the same input data for both MD5
and SHA-1, and there hasn't even been a hint in the crypto literature of how
to do this.  AFAIK there have been more published (although not practical)
attacks on SHA-2 than on a combination of MD5 and SHA-1.  So from the only
evidence we have to date, the MD5+SHA-1 combination may well be stronger than
SHA-2 (in practice we have no idea about either, there's just not enough data
either way, but the point is that there's no real argument in favour of
dropping SSL 3.0 because of the MD5+SHA-1 combination vs. SHA-2).

Peter.

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 03 Jul 2010 09:52:24 -0700

On 2010-07-02 23:40 PDT, Peter Gutmann wrote:
>> calculation, rather than the KDF, since in general a KDF does not
>> really need to be collision resistant and pre-image resistant, whilst
>> the algorithm used for the Finished messages needs to be.
> 
> Even then, you'd need to find a collision for the same input data for
> both MD5 and SHA-1, and there hasn't even been a hint in the crypto
> literature of how to do this.  AFAIK there have been more published
> (although not practical) attacks on SHA-2 than on a combination of MD5
> and SHA-1.  So from the only evidence we have to date, the MD5+SHA-1
> combination may well be stronger than SHA-2 (in practice we have no idea
> about either, there's just not enough data either way, but the point is
> that there's no real argument in favour of dropping SSL 3.0 because of
> the MD5+SHA-1 combination vs. SHA-2).

Hear! Hear!

---

From: Marsh Ray <[email-masked]>
Date: Sat, 03 Jul 2010 14:33:03 -0500

On 07/03/2010 01:40 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos<[email-masked]>  writes:
>
>> For SSL 3.0:
> to do this.

Surprisingly, it's not significantly harder to collide two hash 
functions at the same time than just the harder of the two by itself:

http://www.cs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
"Even cascading a 160-bit iterated hash function and a 160-bit random 
oracle does not really increase security above the initial 2^80 level 
for collision resistance and above 2^160 for preimage (or second 
preimage) resistance."

Raw MD5 and SHA-1 are both "iterated hash functions" in the sense needed 
for this attack, they even have the same block length. But in some 
places, for new versions of the protocol, they are used in the HMAC 
construction which may or may not be a mitigation.

>  AFAIK there have been more published (although not practical)

Raw SHA-256 looks way better to me than a simple concatenation of raw 
MD5 and SHA1.

- Marsh

---

From: Ben Laurie <[email-masked]>
Date: Sat, 3 Jul 2010 21:18:14 +0100

On 3 July 2010 20:33, Marsh Ray <[email-masked]> wrote:
>>> not
>>> need
> Surprisingly, it's not significantly harder to collide two hash functions at
> the same time than just the harder of the two by itself:
>
> "Even cascading a 160-bit iterated hash function and a 160-bit random oracle
> does not really increase security above the initial 2^80 level for collision
> resistance and above 2^160 for preimage (or second preimage) resistance."
>
> Raw MD5 and SHA-1 are both "iterated hash functions" in the sense needed for
> this attack, they even have the same block length. But in some places, for
> new versions of the protocol, they are used in the HMAC construction which
> may or may not be a mitigation.

But they are not cascaded, are they?

> Raw SHA-256 looks way better to me than a simple concatenation of raw MD5
> and SHA1.
>
> - Marsh
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Marsh Ray <[email-masked]>
Date: Sat, 03 Jul 2010 17:29:48 -0500

On 07/03/2010 03:18 PM, Ben Laurie wrote:
> On 3 July 2010 20:33, Marsh Ray<[email-masked]>  wrote:

The paper uses the term "cascaded" a bit counter-intuitively (to me 
anyway, but as PG points out that's no great feat ;-). I would have 
thought it mean, do one then the other with the output of one affects 
the input of the other a` la HMAC.

But halfway through (section 4) it makes it clear that the simple 
concatenation of the two component hashes counts as 'cascaded':

"A natural construction to build large hash values is to concatenate 
several smaller hashes. For example, given two hash functions F and G, 
it seems reasonable given Multicollisions in Iterated Hash Functions a 
message M to form the large hash value (F (M ) G(M )). In this 
construction, F and G can either be two completely different hash 
functions or two slightly different instances of the same hash function3 
. If F and G are good iterated hash functions with no attack better than 
the generic birthday paradox attack, we claim that the hash function F G 
obtained by concatenating F and G is not really more secure that F or G 
by itself. Moreover, this result applies both to collision resistance, 
preimage resistance and second preimage resistance."

Adding or xoring the two hashes together ought to be even easier to 
collide because once could simply expand it to a concatenated form by 
choosing any of a large number of pairs which recombine to the target value.

This occurs in a few places in different versions of the protocol. For 
example, the TLS 1.0 (RFC 2246) Finished message content is defined as:

verify_data
            PRF(master_secret, finished_label, MD5(handshake_messages) +
            SHA-1(handshake_messages)) [0..11];

And the Certificate Verify message for RSA client certs comes from:

        select (SignatureAlgorithm)
        {   case anonymous: struct { };
            case rsa:
                digitally-signed struct {
                    opaque md5_hash[16];
                    opaque sha_hash[20];
                };
            case dsa: ...
        } Signature;

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 04 Jul 2010 02:25:03 +0200

> concatenation of the two component hashes counts as 'cascaded':

Note that this result from that paper only shows that if you have two
hash functions that are as strong as good cryptographic hash functions
should be, their concatenation won't be much stronger: so if they are
160-bit hash functions (meaning you'd expect to find a collision in on
the order of 2^80 steps for each of them), finding a collision of the
concatenation will still only require on the order of 80 * 2^80 steps.

The proof does *not* show that the concatenation of weak hash functions
will still be as weak: if you try to find a collision using the strategy
from the proof, then no matter how easily broken the first hash function
is, you'd still have 2^80 different inputs to try on the second.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Sat, 03 Jul 2010 21:19:05 -0500

> concatenation will still only require on the order of 80 * 2^80 steps.

Good point. One of the functions must be of the iterated form, but the 
other can be treated as ideal. So, at least in this way iterated hash 
functions like MD5 and SHA-1 are non-ideal. Note that if both functions 
happen to be iterated, the attacker gets to choose.

> is, you'd still have 2^80 different inputs to try on the second.

Hmmm, I wouldn't count on that!

In the example of TLS 1.0, the composite hash is based on the 
concatenation of SHA-1 (160 bits) and MD5 (128 bits). The Joux attack 
gives the attacker a choice. He can use known weaknesses to easily 
generate lots of collision pairs on the MD5 and then attempt a pure 
birthday on the SHA-1 at 2^80. Alternatively, he might decide it would 
be better to use the (far milder) known weaknesses in SHA-1 to find 
colliding pairs and then treat MD5 as the random oracle (sounds funny 
saying that) and birthday it at only 2^64.

Also, exploitable weaknesses in a hash function would have to be 
expressable as a series of constraints on the inputs (e.g. set this 
input bit to 0 and that bit to the xor of these other two to yield 
better than average chances for a collision). In the case of, say, the 
same hash function concatenated with itself but just different initial 
chaining values, all of those constraints which are based on solely on 
input will remain satisfied for both component hashes. Constraints with 
dependencies on the chaining values could be satisfied by pure 
probability (i.e., ignored), or a method might be found to steer the 
output of the previous blocks to satisfy them.

The concatenation of two imperfect hash functions challenges the 
attacker to resolve any differences in the attack constraints of the two 
functions. This may or may not be a big deal in practice. Some 
constraints may be flexible and can be rewritten in a compatible form, 
and perhaps some constraints can be left unsatisfied with an acceptable 
loss of efficiency.

Where the two hash functions have differing input block lengths, they 
can be considered to form a longer input function pair at the least 
common multiple of the lengths. The sub-block constraints' relative 
shift out and back into phase within the longer outer block length. This 
might provide more options for resolving constraint conflicts, but since 
it's the output from the final sub-block that really counts it's 
uncertain that this phasing phenomenon would be of much help. So if you 
must concatenate hashes, you might periodically duplicate a bit of input 
to one of them in order to raise the block size LCM as high as practical.

So the proof stops after destroying the weaker of the concatenated 
hashes, but the attacker still has plenty of possibilities to do 
better-than-birthday for the remaining one.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 4 Jul 2010 13:31:44 +0200

On Jul 4, 2010, at 4:19 AM, Marsh Ray wrote:

> Good point. One of the functions must be of the iterated form, but  
> the other can be treated as ideal. So, at least in this way iterated  
> hash functions like MD5 and SHA-1 are non-ideal. Note that if both  
> functions happen to be iterated, the attacker gets to choose.
>

Oh, of course there's no guarantee that the concatenated hash couldn't  
be very weak  too, depending on what weaknesses the ingredients have.   
It's easy to imagine hash function weaknesses that would make the  
concatenated hash just as bad; that's just not what the paper shows,  
and there's no indication that it's generically true (i.e., no matter  
what the specific weaknesses might be).  [As an aside, note that the  
result is just about iterated, i.e. Merkle-Damgard style, hash  
functions with their small innner state, which allows Joux's attack  
approach.  The claim is not true otherwise: say you have a perfect 160- 
bit hash function; you can define two 80-bit hash functions from it by  
taking the first and last half of its output, and both can be broken  
rather easily -- which of course doesn't mean that the full hash as  
their concatenation is suddenly bad too.  MD5 and SHA-1, of course,  
*do* use a small state, but let's be clear what the scope of the  
theoretical result actually is.]

Also, don't forget that the use of these hash functions in TLS 1.0  
doesn't actually have the ambitious goal of collision resistance --  
it's just that it uses ingredients that were meant to deliver this  
(but which, even if failing at this, don't completely break apart: http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html) 
.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Jul 2010 01:02:39 +0200 (MEST)

> (this is NOT RECOMMENDED in RFC 5746 by the way)

This "NOT RECOMMENDED" is mathematically provable nonsense in RFC-5746
and a clear violation of rfc-2119 section 6.

The most sensible approach is to always send SCSV and never
include TLS extension RI in the ClientHello of an initial handshake.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Jul 2010 01:23:12 +0200 (MEST)

Yngve Nysaeter Pettersen wrote:
> it supports TLS 1.0. If it doesn't, then we  continue the handshake.

I'm actually confused by this strategy.

The goal is that you can get a correct handshake on first attempt
without any bad side effects from poposed extensions.  And while
there may be some servers today where this approach results in a
handshake failure, the number is server was claimed by a number of
folks on this list to be very minor and decreasing.

Therefore the logical first ClientHello should contain TLSv1.2
all desired TLS extensions and all desired ciphersuites.  If that
handshake fails, a more conservative ClientHello could by tried
by those apps that implement re-try functionality (currently
this is limited to newer Web Browsers).

I really see no point in publishing draft-turner-ssl-must-not, which
basically suggests just that, when the Browser vendor, that has
most aggressively been pushing for TLSv1.2--and has it implemented
_with_ an application-level TLS-handshake-fallback-retry-logic,
does not dare sending TLSv1.2 in the initial discovery ClientHello.

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 06 Jul 2010 01:52:36 +0200

> this is limited to newer Web Browsers).

Given how badly some servers behaved (see my interoperability draft) I  
decided a ladder approach was the best to the feature capability test.

Starting with TLS 1.0 without Extensions allow us to determine whether to  
try TLS 1.0 with Extensions, then 1.1 and 1.2, or if we should go down and  
try TLS 1.0 with SSL v3.0 as the record protocol version, and if that  
fails just SSL v3.0.

Using extensions in the first step might have prolonged the search, or at  
least made the route more difficult, since there are TLS 1.0 servers that  
does not tolerate higher version and/or extensions.

An approach with TLS 1.2 and extension would be the ideal (and strictly  
speaking should be possible according to the spec), and it is what we are  
using with renego patched servers, but there are enough servers behaving  
badly in such a scenario that IMO starting (relatively) low and climbing  
the ladder is at least slightly better. Starting low also allows a test  
for whether there is actually a server there that speaks SSL/TLS.

IIRC we used the step down procedure when we only supported TLS 1.0 and  
SSL v3.0,

My plan is to remove the entire test procedure once we can go to strict  
mode for renego.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Jul 2010 04:17:14 +0200 (MEST)

> concatenation will still only require on the order of 80 * 2^80 steps.

The base result is that the strength of concatenation of two
hash functions improves the result not as much as one might hope.

It always does improve the result, however.

Which means that SSLv3 is stronger than TLSv1.0 and TLSv1.1
in that respect.

Personally, I dislike the extreme truncation of the Finished
messages in TLS to 12 octets.  My expectation is that this limits
the overall strength, and that it spoils the use of SHA-2 in TLSv1.2.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 06 Jul 2010 14:39:52 +1200

Martin Rex <[email-masked]> writes:

>Personally, I dislike the extreme truncation of the Finished messages in TLS
>to 12 octets.

But if we didn't use exactly 96 bits for this then the IPsec cargo cult gods
might smite us!

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 6 Jul 2010 03:04:55 +0000

> But if we didn't use exactly 96 bits for this then the IPsec cargo cult gods

Is that where that came from, IPsec?

I was wondering about that design decision, 2^48 birthday resistance seems absurdly small.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 06 Jul 2010 15:31:28 +1200

>Is that where that came from, IPsec?

In IPsec there were exactly 96 bits left in a (evenly-sized) packet for a 24- 
byte AH header (to fit the IPv6 8-byte quantisation) so they decided to 
truncate the MAC value to fit it.

Since then, cargo cult design has seen it adopted in TLS, in SSH, in SNMP, in
RADIUS, in iSCSI, in Kerberos, in Gigabeam, in HIP, heck I bet there's a
standards group trying to put it into DHCP somewhere... rot bilong kago.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 6 Jul 2010 05:00:00 +0000

On Sun, Jul 04, 2010 at 01:31:44PM +0200, Bodo Moeller wrote:
>
> MD5 and SHA-1, of course, *do* use a small state, but let's be 
> clear what the scope of the theoretical result actually is.

Well, I thought it was pretty cool. :-)

Last I heard SHA-1 was down to 2^69 and MD5 2^24.
http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf
http://www.win.tue.nl/hashclash/On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf

> doesn't actually have the ambitious goal of collision resistance

It would be really great if this kind of thing had been documented as
part of the design process. The Glossary section of RFC 4346 talks
about collision resistance as a property of MD5 and SHA-1.

Recently there have been some proposals for extensions to TLS which
loosen up some ordering dependencies or even change the crypto quite
dramatically. It would be unfortunate if some under-documented
assumptions were accidentally violated because they weren't well
understood.

> -- it's 
> just that it uses ingredients that were meant to deliver this (but
> which,  even if failing at this, don't completely break apart: 
> http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html).

Again, RFC 4346:
------------------
   When this message will be sent:

      This message is used to provide explicit verification of a client
      certificate. 
	.....
      struct {
           Signature signature;
      } CertificateVerify;

      struct {
          select (SignatureAlgorithm) {
              case anonymous: struct { };
              case rsa:
                  digitally-signed struct {
                      opaque md5_hash[16];  <----- Note concatenated
                      opaque sha_hash[20];  <----- non-HMAC hashes here.
                  };
              case dsa: ...
              };
          };
      } Signature;

      CertificateVerify.signature.md5_hash
          MD5(handshake_messages);

      CertificateVerify.signature.sha_hash
          SHA(handshake_messages);

   Here handshake_messages refers to all handshake messages sent or
   received starting at client hello up to but not including this
   message, ....
------------------

So we definitely have some red flags going up here:
   * Raw hashes used without HMAC for signing important stuff
   * Concatenated iterated hash functions
   * Mitm can manipulate variable-length data under the hash in both
     directions

These suggest the possibility of a client cert credential stealing attack
(for the purely theoretical attcker who can collide SHA-1s within the
handshake timeout).  There are any number of reasons this might not
translate into a practical attack, but I think it supports a couple of
points:

   * Some aspects of TLS security have excessively subtle dependencies.

   * The Joux attack on concatenated iterated hashes is relevant to TLS.

   * TLS 1.0 and 1.1 are quite possibly pwned with the first published
     collision of SHA-1 and should be deprecated along with other uses
     of SHA-1.

   * Client certificates are not the solution to everything ;-)
 
- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 06 Jul 2010 17:30:20 +1200

>   * Mitm can manipulate variable-length data under the hash in both

For its use in Finished though we also have some anti-red flags: The attacks
on MD5 rely on fixed, known input and huge amounts of offline computation.  In
this case we have unknown input (until the time the handshake takes place), a
limited timeout period after which a collision won't be useful any more, and
the need to break (find a collision) for both MD5 and SHA-1 simultaneously,
not just MD5.  On my list of things to worry about I've got it somewhere down
near "server struck by meterorite".

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 6 Jul 2010 06:47:08 +0000

> It always does improve the result, however.

Putting it another way, if you spend 36 bytes (288 bits) on space
for your hash and it turns out to have only about 2^75 collision
resistance, I'm not sure many people would call that an improvement.

> the overall strength, and that it spoils the use of SHA-2 in TLSv1.2.

+1.

There's no logic to it, or whatever there might be is too clever by half.

Apparently, someone was convinced that collision resistance was
irrelevant. So convinced that they were willing to bet your data
on it and not use another 8 or so bytes to transmit the full hash
that had already been computed. I wonder if they realized that
higher layer protocols were attaching semantic value to the
receipt of the Finished message.

But since their reasoning didn't make it into the RFCs so we must
live without it when reviewing things like False Start/Snap Start.
It'd be nice to know what other unstated dependencies and assumptions
the security rests on.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 6 Jul 2010 10:28:54 +0300

> But if we didn't use exactly 96 bits for this then the IPsec cargo cult gods

No, we won't. We've come around. In RFC 4868 we allow up to 256 bits for integrity validation, as long as you're using algorithms that we like.

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Jul 2010 16:25:02 +0200 (MEST)

> resistance, I'm not sure many people would call that an improvement.

It is an improvement because it is harder to find a collision
for both hashes than finding it for only one of them.  And it used
the commonly available cryptographic hashes at that time
(sha-2 was not available back then).

I see it as an improvement, even if it is a small one.

> There's no logic to it, or whatever there might be is too clever by half.

There appears to be a lack of logic by not adjusting the truncation size
when going from a SHA-1 (=160 bits) based PRF to a SHA-256 (=256 bits)
based PRF.  In case a 96 bit truncation is deemed adequate for SHA-1,
then a truncation like 144 or 160 bits appears more appropriate for SHA-2.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 06 Jul 2010 16:40:35 +0200

> then a truncation like 144 or 160 bits appears more appropriate for SHA-2.

Or just sending the whole output. I don't even know why truncation is
there. I'd understand truncation in the record layer HMAC that is sent
on every message, there it would save bandwidth... but on the finished
message?

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Tue, 06 Jul 2010 11:04:15 -0500

> on every message, there it would save bandwidth... but on the finished

Well the RFC defines it as a number of bytes output from the PRF, which 
is a byte-by-byte data source in the abstract sense. Under the hood we 
know that there are whole hashes being produced but it seems reasonable 
that the spec wouldn't be defined in terms of that.

12 bytes though, that's shorter than any of the hashes anywhere else in 
the system.

- Marsh

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Tue, 6 Jul 2010 13:17:25 -0400

There are two attacks: (a) finding collisions, and (b) offline
guessing/brute-forcing the key. The fewer bits of the complete hash you have
- the less ability to verify & disambiguate your guess.

The balance is between outputting enough bits to defeat collision-based
attacks, yet omitting enough bits to prevent disambiguating the key in
offline trials.

Most of the sources prioritize fending off collision seekers.

Barring a discovered cryptographic weakness in the underlying hash function,
the likelihood of finding collisions in SHA256 output (say even truncated to
160 bits) is comparable with the likelihood of guessing a key used for HMAC.
Both currently aren't high on my list of concerns. :-)

P.S. Of course there are also bandwidth and packet size concerns that matter
even though they're not "security" issues.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 06 Jul 2010 15:42:51 -0500

On 07/06/2010 12:17 PM, Blumenthal, Uri - 0668 - MITLL wrote:
> - the less ability to verify&  disambiguate your guess.
>

My impression was that preventing the occurrence of known plaintext was 
no longer considered an important design principle.

Even if the Finished message were made very short, it's probable that 
there will be plenty of known plaintext in record headers, padding 
bytes, not to mention the application data itself. Any text based is 
going to have a zero high bit on a great majority of chars, compression 
is far from standard and it presumably brings its own known headers.

So, from what I hear, modern ciphers are expected to be resistant to 
known plaintext attacks.

> Both currently aren't high on my list of concerns.

Even if the hash functions are broken, the PRF is very conservatively 
designed. The hash functions are doubled-up in the HMAC construct, and 
HMAC is then performed recursively to generate the output! For TLS 1.0 
and 1.1, this is done separately for MD5 and SHA-1 and those results get 
combined. It's nice that there are some parts of the design with a 
generous safety margin!

- Marsh

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 07 Jul 2010 17:11:03 +0200

Marsh Ray <[email-masked]> writes:

> My impression was that preventing the occurrence of known plaintext
> was no longer considered an important design principle.
>
> going to have a zero high bit on a great majority of chars,
> compression is far from standard and it presumably brings its own
> known headers.
>

TLS has integrity-only ciphersuites that does not provide
confidentiality, making the TLS Finished message visible to attackers.
But I don't follow the logic here and want to challenge you with a
question: what attack is enabled if an attacker can find a collision?
It may help to consider what attacks are enabled if the TLS Finished
messages is truncated to, say, 10 bits instead.

/Simon

---

From: Marsh Ray <[email-masked]>
Date: Wed, 07 Jul 2010 18:40:45 -0500

> confidentiality, making the TLS Finished message visible to attackers.

Yeah I was ignoring that because I was under the impression that it was 
deprecated in TLS 1.2. May be misremembering though.

> messages is truncated to, say, 10 bits instead.

The attack is if a MitM can convince a client and server that they 
should exchange the same client or server Finished hash, yet the 
handshake has been manipulated by the attacker.

Possible consequences:
* Version downgrade
* Ciphersuite downgrade attack
* Re-establishing unsafe renegotiation with a compatible-mode client and 
a strict server.
* Client credentials stealing/forwarding attack.

The bar is pretty high for this kind of attack:

* It likely needs to be an on-line attack (i.e., attacker has to be able 
to calculate the collision within the timeout window of the handshake. 
One could imagine some systems having no enforced timeout however.

* Mitm needs to obtain the client's premaster secret as part of the 
attack (the key material is needed to generate the hash). Note this is 
trivial with some real clients in common use that don't validate the 
server cert until they receive the Finished message.

* Mitm probably needs to be able to manipulate ~48 bits of data in each 
direction, after any unpredictable values in that direction. For 
example, MitM may inject or manipulate a Certificate Request message in 
the server-to-client direction, this occurs after the unpredictable data 
in the hello and key exchange messages. But an actual cert verify 
message sent in response would mess it up again.

* Probably only a single 96 bit finished message is collide-able. 
Colliding the combined 192 bits may never be practical. Nevertheless, an 
HTTPS server executes a buffered transaction with client cert 
renegotiation on receipt of the single finished message. A client will 
begin transmitting confidential data when he receives the server's 
single Finished message and Mitm may not need the server to accept one 
generated by the client.

I gave this a bunch of thought a while back but couldn't come up with 
anything that could affect a plausible use case of TLS. But the reasons 
why it wouldn't work varied greatly with the negotiated auth mechanism, 
it was not because of any obvious design principle of TLS which resists 
a mitm from engineering a Finished message collision.

With only minor changes, such an attack would be possible. For example, 
if a TLS implementation were to ignore unrecognized handshake messages 
yet included them in the hash.

Consider the case of fixed-parameter DH client-server certificates. I 
don't recall any unpredictable data being sent by either side after the 
random data in the hellos. Mtim could manipulate the server hello as 
seen by the client, inject arbitrary handshake data into an extraneous 
cert presented or cert request received by the client. He might inject 
data into the client key exchange or certificate verify as seen by the 
server, and so on. Mitm could even convince the server to do one type of 
key exchange (e.g., DHE) and the client some other.

Of course, if there is insufficient entropy in the Client Hello random, 
Server Hello random, or the premaster secret then a whole new set of 
possibilities opens up. For example, with a predictable server hello 
random, mitm might be able to modify data as early as the client hello 
in order to engineer a collision in one of the finished messages. It 
might also allow this attack to be partially precomputed offline. (This 
is one reason why I objected so strongly to the idea that a secure TLS 
endpoint could be implemented without a sufficient source of entropy.)

Like I said, there may not be an effective attack here. The use of the 
secret key material in the Finished calculation rules out a lot of 
mischief. But since the "collision insensitivity" of TLS seems to be 
highly dependent on parameters which can be controlled by the attacker, 
we must be extremely careful when extending the handshake, changing 
Finished calculations, or relaxing constraints.

- Marsh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 8 Jul 2010 10:07:41 +0200

[...]
> * Mitm needs to obtain the client's premaster secret as part of the attack
> (the key material is needed to generate the hash). Note this is trivial with
> some real clients in common use that don't validate the server cert until
> they receive the Finished message.

Why is this trivial? If you do mitm it will be discovered at the
verification point and game is over.

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Thu, 08 Jul 2010 10:33:53 -0500

On 07/08/2010 03:07 AM, Nikos Mavrogiannopoulos wrote:
> Why is this trivial?

Mitm can present his own cert that he has the private keys to. It might 
be self signed, signed by a CA cert calling itself "Verisign", or signed 
by the real Verisign but issued to mitm.example.com.

Another possibility is that he could downgrade the connection to 
something he could break.

> If you do mitm it will be discovered at the

Maybe not. Attacker may have accomplished his objective, he may only 
need 50 ms of unauthorized access (or to commit one transaction) in 
order to install a persistent backdoor.

Considering the lack of concern typical web users have for certificate 
warnings, I think there's plenty of room for an attacker to avoid or 
delay detection. When was the last time you compared the binary RSA 
parameters on a cert warning? A successful attack on unattended systems 
may be recorded in the logs as simply a single connection failed.

- Marsh