Subject: [TLS] Protecting against a MITM

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 15:31:57 -0800

Whatever the solution turns out to be, I think we all agree that it needs
to address these two simple issues:

    1)  A server needs to be able to protect against MITM attacks
    2)  A client needs to be able to protect against MITM attacks

    Solving #1 is trivial since a server can simply refuse to renegotiate a
    connection when the client doesn't use the agreed-upon solution.

    Solving #2 is more difficult, and it breaks down into the following two
    sub-issues:

       2a) A client needs to be able to protect against attacks
           when the server is patched
       2b) A client needs to be able to protect against attacks
           when the server is NOT patched

    Issue 2a is again trivially accomplished by the fact that the server
    is protecting the client (issue 1, since it is patched), so the
    important case is 2b and ONLY 2b, i.e. patched client / unpatched
    server.

Here is an analysis of whether proposed solutions address this case 2b:

RI with patched client / unpatched server:

    People continue to suggest that with the RI extension, a client doesn't
    need to send it on its initial handshake.  This is completely wrong.
    A MITM attack will absolutely succeed if the server is not patched and
    the client does nothing different than it always has in the past.  Thus
    if RI is not used by the client in its first handshake, it gets zero
    protection even though it is aware of the MITM attack.  And even if the
    client does use the extension, it must rely on a possibly forged Server
    Hello to decide whether to continue with the handshake.

    So the client has to send the extension on every handshake including
    the initial handshake.  This brings up all of the interoperability
    problems: lack of support for extensions even in TLS, no possible way
    to use extensions with SSLv3, mischief by a MITM (removing the
    extension from the hello messages, simulating a server "crash" when
    the extension is sent, etc.)

    This is at best "treacherous".

Modifying the Finished message calculation:

    If instead of RI we change the Finished message calculation, it needs
    to protect patched clients that connect to unpatched servers (the only
    case that matters -- see above).  If the Finished message calculation
    were to remain the same on initial handshakes, then again the client
    gets absolutely no protection when connecting to an unpatched server
    since it will use the old unchanged calculation even on renegotiations.

Here is my proposal for a backward-compatible solution that also protects
the important case 2b above:

This solution is to make available a modified Finished calculation that a
patched client can use for all handshakes including the initial one.  This
solution does not even break compatibility with old clients -- a server
would support BOTH the old and the new Finished message computation and do
the right thing based on which one was used by the client.  There are only
two possibilities:

    A) client uses the old (current) Finished calculation
    B) client uses the new Finished calculation

With (A), the server would allow an initial connection but prevent any
renegotiations, thus protecting against any MITM attacks.  If the client
uses the new Finished calculation (B), then the handshake succeeds whether
it was an initial handshake or a renegotiation.

If neither calculation matches, the server knows that there was tampering by
a MITM, and should not continue with the handshake.

We never need to stop supporting the old method for initial handshakes, so
this is completely backward-compatible for clients connecting to a new server
when renegotiation is not involved.  If renegotiation is required to use the
server, then the current type of insecure renegotiations are prevented as we
want.

The only interoperability "problem" is when a patched client uses the new
Finished calculation when talking to an unpatched server[*] -- the handshake
will fail.  This is precisely what SHOULD happen -- the client is protected
from a potential MITM attack!  A client that does not want this protection
does not need to use it.  Or if it is daring it can first try the new and
fall back to the old method if it's willing to risk an attack.  When the
server is patched and the client is convinced to fall back due to MITM
meddling, the server will reliably know this and can notify the proper
people to investigate the attack.

[*] A minimally-patched server might simply disable all renegotiation and
not want to support a new Finished calculation.  To signal this, the server
could do something special with the ServerHello.random, such as computing
a checksum of size x bytes over the first 32-x bytes (x needs to be small
enough to keep the random actually mostly random, but big enough to make
false positives unlikely).  Upon validating the checksum, a client could
at its discretion continue the handshake using the old Finished message
calculation.  A MITM could forge the checksum, but then the handshake would
fail anyway due to mismatched verify_data.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 01:47:44 +0200

At Sun, 15 Nov 2009 15:31:57 -0800,
>     This is at best "treacherous".

You misunderstand what I'm saying.

Yes, clients which want to ensure that they never connect to an unfixed
server need to generate RI on the initial handshake. If they don't
get an affirmative response, they abort the connection. However, since
this will cause incompatibility with most servers for the foreseeable
future, it's not practical to turn it on. 

> people to investigate the attack.

But this is *exactly* the same scenario as with RI. Namely, you can include
it in the handshake if you want to ensure that the server is upgraded
and you don't if you don't. 

I fail to see what the interop advantage of this scheme is.

-Ekr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 15:47:09 -0800

>     This is at best "treacherous".
[Joe] I disagree.  If the client has a lenient policy, meaning it will
connect with unpatched servers, then it doesn't need to send the
extension.  If the client has a strict policy then it needs to send the
extension, in this case it only needs to interoperate with servers that
support the extension.  I'm not sure what scenario you are trying to
address.

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 16:03:06 -0800

> I fail to see what the interop advantage of this scheme is.

1) Works with all versions of the protocol including SSLv3
2) Does not require TLS extensions
3) In fact no change to bits on the wire
4) Provides proof of an attempted MITM attack at the server

Are none of these important?

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 16:14:56 -0800

> support the extension.  I'm not sure what scenario you are trying to

But there are lots of problems with "it needs to send the extension."
Won't work for SSLv3.  Some TLS-capable servers even choke on them.
A MITM can simulate this problem for servers that DO support extensions,
possibly causing insecure fallback strategies to take place.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 02:18:10 +0200

At Sun, 15 Nov 2009 16:14:56 -0800,
> Won't work for SSLv3.  Some TLS-capable servers even choke on them.

All of which servers are presumptively vulnerable. Any server which
applies any of these fixes can clearly add support for extensions
trivially.

> possibly causing insecure fallback strategies to take place.

As I noted earlier, this is easily fixed with a fake cipher suite.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 18:29:44 -0600

> support the extension.  I'm not sure what scenario you are trying to

Well, for example, the server doesn't want to accept vulnerable
connections from unpatched clients. Some attacks are possible even if
the server does not renegotiate.

This plan of making the client signaling contingent on the client's
willingness to renegotiate seems suspicious to me. It raises a few
questions:

How often do SSL/TLS clients actually refuse renegotiation at the
request of a patched server?

Do we really want a situation where a patched client is talking to a
patched server, yet neither of them know it?

If an extension is really the solution, why wouldn't the client send one
every time? How does it help to make it conditional?

Does thus segment the protocol into "client will renegotiate" and
"client won't renegotiate" versions? Does the client have to decide that
in advance?

If the client does send the extension does that imply he will in fact be
willing to renegotiate later? If not, how will developers test that odd
case?

Does this effectively add a new flag to the TLS library API so the app
code can indicate its willingness to renegotiate? Can the client change
his mind later?

Assuming most TLS library APIs and apps using them don't change
immediately to use it, it will only be a small percentage of fixed
clients exercising their right not to send the extension. Do we really
want to add another under-used, under-tested corner case to the protocol?

Do we want network monitoring, IDS, firewall, and other TLS implementors
to have to consider this odd case? Doesn't this case prevent them from
warning about unsafe clients on the network?

- Marsh

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 01:42:33 +0000

>    need to send it on its initial handshake.  This is completely wrong.

It is not "completely wrong". For a patched client, not sending a signal
on the initial handshake (regardless of the form of that signal) matters
if-and-only-if the client is going to refuse to interoperate with
unpatched servers.

If a client would continue with an initial connection to a server that it
knows is unpatched, then the attack is unavoidable in that case. That is
true for *any* possible solution, not just RI.

>    the extension is sent, etc.)

These kinds of "mischief by a MITM" won't work. The Finished hashes will
fail to verify, and the attacker gains no advantage:

 - if the client policy is to connect to unpatched servers, then the
   "mischief" wasn't needed; the vulnerability is unavoidable.

 - if the client policy is not to connect to unpatched servers, then it
   MUST NOT fall back to a handshake that doesn't send the extension --
   but it doesn't need any such fallback, because all patched servers
   can be assumed TLS- and extension-tolerant.

(If a server accepts the extension but remains TLS- and extension-tolerant,
then that's simply a broken implementation of the patch, which should be
revealed immediately in interoperability testing with patched clients
configured to use the stricter policy.)

The RI proposal does have some disadvantages (I'll discuss those
separately), but it doesn't have the disadvantages you state here.

> the right thing based on which one was used by the client.

This has a significant disadvantage relative to the RI proposal:
Consider a patched client that wants to connect to unpatched servers.
With your suggested approach, such a client must use the old Finished
message computation on an initial handshake (or else it must add a fallback
in order to connect to those servers, which is undesirable). Therefore, it
isn't distinguishable from an unpatched client by looking at cleartext
handshake messages.

My proposal of changing the Finished hash computation for renegotiations
only, plus sending an empty extension to signal patched status, does not
have this disadvantage. It also does not rely on the extension for
anything other than detection of patched/unpatched status.

> Finished calculation when talking to an unpatched server[*] -- the
> handshake will fail.  This is precisely what SHOULD happen -- the client
> is protected from a potential MITM attack!

It is quite unrealistic to suppose that *all* client implementors will
want to refuse to interoperate with unpatched servers. That has to be
an option, not a requirement or assumption.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 18:39:10 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael D'Errico
> Sent: Sunday, November 15, 2009 4:15 PM
> To: [email-masked]
> Subject: Re: [TLS] Protecting against a MITM
> 
> >>     People continue to suggest that with the RI extension, 
> a client 
> >> doesn't
> >>     the client does nothing different than it always has 
> in the past.  
> >> Thus
> >>     if RI is not used by the client in its first 
> handshake, it gets 
> >> zero
> >>     client does use the extension, it must rely on a 
> possibly forged 
> >> Server
> >>     problems: lack of support for extensions even in TLS, 
> no possible 
> >> way
> > extension.  If the client has a strict policy then it needs to send 
> > the extension, in this case it only needs to interoperate 
> with servers 
> > that support the extension.  I'm not sure what scenario you 
> are trying 
> > to address.
> 
[Joe] I haven't been convinced of this.  

> Won't work for SSLv3.  
[Joe] Why not?  You will need to apply some patch to SSLv3, any of them
will be incompatible with. 

>Some TLS-capable servers even choke on them.
[Joe] Perhaps, but they won't be patched TLS servers.  The extension is
sent in the initial handshake when the client is implementing a strict
policy.  In this case you do not want to talk to broken servers.

> A MITM can simulate this problem for servers that DO support 
> extensions, possibly causing insecure fallback strategies to 
> take place.
> 
[Joe] A strict policy would not fallback.  

> Mike
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 15 Nov 2009 18:56:05 -0800

> Behalf Of Marsh Ray
> Sent: Sunday, November 15, 2009 4:30 PM
> Cc: [email-masked]
> Well, for example, the server doesn't want to accept 
> vulnerable connections from unpatched clients. Some attacks 
> are possible even if the server does not renegotiate.
> 
> This plan of making the client signaling contingent on the 
> client's willingness to renegotiate seems suspicious to me. 

[Joe] Perhaps I mis-spoke on another thread.  A strict policy does not
allow connection to unpatched servers.  A lenient policy allows
connection to unpatched servers.  These policies don't have to do with
whether the client wants to renegotiate, but rather whether they require
the server to do secure renegotiation.  

> It raises a few
> questions:
> 
> How often do SSL/TLS clients actually refuse renegotiation at 
> the request of a patched server?
> 
> Do we really want a situation where a patched client is 
> talking to a patched server, yet neither of them know it?
> 
> If an extension is really the solution, why wouldn't the 
> client send one every time? How does it help to make it conditional?
> 
> Does thus segment the protocol into "client will renegotiate" 
> and "client won't renegotiate" versions? Does the client have 
> to decide that in advance?
> 
> If the client does send the extension does that imply he will 
> in fact be willing to renegotiate later? If not, how will 
> developers test that odd case?
> 
> Does this effectively add a new flag to the TLS library API 
> so the app code can indicate its willingness to renegotiate? 
> Can the client change his mind later?
> 
> Assuming most TLS library APIs and apps using them don't 
> change immediately to use it, it will only be a small 
> percentage of fixed clients exercising their right not to 
> send the extension. Do we really want to add another 
> under-used, under-tested corner case to the protocol?
> 
> Do we want network monitoring, IDS, firewall, and other TLS 
> implementors to have to consider this odd case? Doesn't this 
> case prevent them from warning about unsafe clients on the network?
> 
> - Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 20:35:37 -0800

> if-and-only-if the client is going to refuse to interoperate with

"Interoperating with unpatched servers" means exposing yourself to an attack.
We can't protect against that behavior.  It may initially be necessary to
do this until widespread adoption of the fix happens, but it is certainly
not safe long term.

Any fix that we come up with, if it is not used it will not protect you.
That is obvious.

> true for *any* possible solution, not just RI.

Agreed.

The difference is that if you *DO* want to avoid handshaking with unpatched
servers then with RI it requires you to a) use TLS, not SSL, because you need
to b) send and receive an extension; you also c) base your decisions on in-
the-clear hello messages that are subject to tampering, and d) don't send a
Finished message if the server *appears* not to support RI, thus you can't
prove or disprove an attack was underway.

With my proposal, you simply switch to a new Finished message calculation;
no changes to the bits on the wire, thus perfectly interoperable up until
the Finished message fails because the server is not upgraded.  And that is
what you want to happen if you are not being "lenient."  Further, if an
attack is happening and the server *is* upgraded, it can prove it since
neither of the two Finished calculations will match.  A MITM can not do
anything to cause one of them to match since it doesn't know the master
secret.

> fail to verify, and the attacker gains no advantage:

In most cases I think you are right, but imagine there is a server out there
that requires renegotiation to obtain client credentials.  In order to
continue providing service to clients, it may be configured to still perform
insecure renegotiations during a transition period.  A MITM can easily make
this server appear to break upon receiving the RI extension.

If the client has a fallback to not use the RI extension, then the MITM is
able to cause the client and server, both of which are patched, to revert
back to insecure behavior.

With my proposal, it is also possible for a MITM to alter the handshake, but
the difference is that the server can prove it happened since neither Finished
computation will match.  Because it notices an active attack, it can mount a
more effective defense, such as locking out that client's IP address (range)
from renegotiating and instead ask for client auth in the initial handshake.

> isn't distinguishable from an unpatched client by looking at cleartext

I'm suggesting to give up cleartext patch status for better attack detection
and better interoperability since there is NO change to bits on the wire, no
need for extensions or even TLS (SSLv3 can be fixed in exactly the same way).

A server can actually log when neither Finished message calculation matches
and alert the proper people to investigate the attack.  With RI this is not
possible since the client can't send its Finished message without risking an
attack.

> anything other than detection of patched/unpatched status.

This has the same problems as RI w.r.t. not being compatible with SSLv3 and
requiring extensions.  But it would work for peers that both support TLS with
extensions.

> an option, not a requirement or assumption.

The whole premise of my message was based on providing a solution for a
patched client trying to protect against an unpatched server.  Any solution
we come up with MUST protect a patched client talking to a patched server, so
the only issue worth discussing is how to protect patched clients from an
unpatched server.  Or if a proposed solution fails the MUST, such as with the
fallback possibility when an RI client can be tricked into reconnecting
insecurely and a server accepting it.

If a client wants to throw caution to the wind and connect using the old
Finished message, that is its choice.  Nobody can force a client to be secure
if it doesn't want to be.  That does not mean that we shouldn't provide a
completely secure method to avoid and detect these attacks.

Mike

---

From: <[email-masked]>
Date: Sun, 15 Nov 2009 23:50:06 -0500

RSA, The Security Division of EMC, has created a TLS Interoperability Server 
to allow inter-op testing of TLS.

The static content of the server is here http://203.166.62.199/

Please email me the following information so I can have your IP address added 
to a white list so you can access the inter-op servers themselves.

* Contact Information
  Name
  Organization or Company name and Business Unit
  Address
  Phone Number
  Email address
* IP Address(es) which you will be connecting from.
* Product(s) and version(s) you will be testing.
* TLS protocol versions, cipher suites and curves you wish to test.

Peter
------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, 
AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 15 Nov 2009 21:18:20 -0800

> anything to cause one of them to match since it doesn't know the  

Where we are requiring changes in both clients and servers anyway, I  
don't see a problem about using an extension in a SSL 3.0 handshake.   
We can just assume that the updated software will support this one  
extension (while maybe ignoring any other extension).

> back to insecure behavior.

If both the client and the server allow this fallback to legacy  
renegotiation, they might be downgraded to insecure behavior.  We have  
a proposal that could be used to avoid this without extensions,  
though: have the client list use a magic ciphersuite to indicate  
support for the new handshake scheme.  If the server sees this listed  
by the client, it would refuse this Client Hello in a renegotiation  
handshake.

I don't see how your proposal would avoid the problem: A client that  
wants to support legacy servers couldn't use the modified Finished  
computation in the first place.  But if it doesn't, it wouldn't be  
secure, would it?

Bodo

---

From: Ben Laurie <[email-masked]>
Date: Sun, 15 Nov 2009 21:38:02 -0800

> to allow inter-op testing of TLS.

Does it support the renegotiation extension?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 07:45:05 +0200

At Sun, 15 Nov 2009 18:29:44 -0600,
> the server does not renegotiate.

What attacks are those?

> request of a patched server?

I don't understand the relevance of this question.

> patched server, yet neither of them know it?

I don't see the problem ehre.

> every time? How does it help to make it conditional?

It avoids the claimed backward compatibility problem with

> "client won't renegotiate" versions? Does the client have to decide that

No, it doesn't segment the population. You can still renegotiate
even if you didn't send the extension on initial handshake.

> willing to renegotiate later? If not, how will developers test that odd

As I said before, not sending the extension does not mean you wouldn't
renegotiate.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 15 Nov 2009 21:47:07 -0800

> don't see a problem about using an extension in a SSL 3.0 handshake.  We 
> can just assume that the updated software will support this one 

Patched clients talking to patched servers is not the issue since they
won't be vulnerable anyway.  We need to focus on interoperability between
peers where only one of them is patched.

There are likely going to be lots of interoperability problems caused by
RI with SSLv3 servers since they don't currently expect any extensions.

> renegotiation, they might be downgraded to insecure behavior.  We have a 
> proposal that could be used to avoid this without extensions, though: 
> have the client list use a magic ciphersuite to indicate support for the 
> new handshake scheme.  If the server sees this listed by the client, it 
> would refuse this Client Hello in a renegotiation handshake.

It's good that an extension is not needed, but how does the client find
out that the server recognized it?  It can't send its Finished message
safely unless it knows for sure the server is patched.

> computation in the first place.  But if it doesn't, it wouldn't be 

A so-called "lenient" client might as well just continue using the old
(current) handshake and hope that all the servers it talks to are
patched.  This is true for both RI and my proposal.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 07:57:05 +0200

At Sun, 15 Nov 2009 21:47:07 -0800,
> RI with SSLv3 servers since they don't currently expect any extensions.

Again, this only obtains if the client sends RI on the initial
handshake which it only does if it is strict and would refuse to
handshake with an insecure server. 

> safely unless it knows for sure the server is patched.

Again, it can if it's willing to negotiate with unpatched servers, which
many clients will be for the foreseeabe future.

> patched.  This is true for both RI and my proposal.

No, that's not correct.

The purpose of RI is twofold:
1. To allow a lenient client to RENEGOTIATE with a patched server, 
   which would otherwise refuse to renegotiate.
2. To allow a strict client to detect whether a server is patched.

The first benefit is what is relevant here.

-Ekr

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 09:06:55 +0000

Michael D'Errico wrote:
>>>    People continue to suggest that with the RI extension, a client
>>>    doesn't need to send it on its initial handshake.  This is completely wrong.
>>

I didn't say that it was.

The solution must support at least both strict and lenient client policies,
i.e. either refusing or allowing connections to unpatched servers. I don't
think there is any dispute about that, is there?

> servers then with RI it requires you to a) use TLS, not SSL,

More precisely, it requires you to send a TLS ClientHello. It is possible
for an SSL-only server to recognize that ClientHello and negotiate SSLv3,
but still use the extension.

That is, RI only requires servers to support extensions and be TLS-tolerant,
not necessarily to be able to negotiate TLS. RI does require *clients* to
support TLS (since sending the ClientHello with a TLS client version
promises that TLS is supported, and since the interoperability consequences
of sending an SSLv3 ClientHello with extensions are completely untested).

> because you need to b) send and receive an extension; you also c) base
> your decisions on in-the-clear hello messages that are subject to tampering,

This is discussed below.

> and d) don't send a Finished message if the server *appears* not to
> support RI, thus you can't prove or disprove an attack was underway.

I addressed this point before:

# Being able to prove that an attack took place (or to distinguish an attack
# from, say, line noise or any of many possible implementation errors) was
# not a design goal of TLS, and the protocol doesn't achieve that for
# numerous reasons.

> the Finished message fails because the server is not upgraded.

Yes, I wasn't arguing that your proposal had any interoperability problems.

>> These kinds of "mischief by a MITM" won't work. [...]
> 
> In most cases I think you are right, but imagine there is a server out
> there that requires renegotiation to obtain client credentials.

OK...

> In order to continue providing service to clients, it may be configured
> to still perform insecure renegotiations during a transition period.

Then it is not fixed, and is nonconformant to the RI draft.

> A MITM can easily make this server appear to break upon receiving the
> RI extension. If the client has a fallback to not use the RI extension,
> then the MITM is able to cause the client and server, both of which are
> patched, to revert back to insecure behavior.

That's not clear. I think it depends on precisely how the fallback
mechanism is implemented. If the patched client refuses to renegotiate
when it is in fallback mode, then I cannot immediately see any attack.

I agree that both your proposal and mine are potentially more robust
than RI here, since they both change the Finished hash computation for
renegotiations even when extensions are *not* sent.

> With my proposal, it is also possible for a MITM to alter the handshake,
> but the difference is that the server can prove it happened since neither
> Finished computation will match.

If the server is configured to perform insecure renegotiations, then
in your proposal it must accept a client Finished message with the
unchanged hash computation. So an attack is certainly possible when the
client is unpatched. I'll have to think some more about the security
of RI in the fallback case when both client and server are patched
(but lenient); it's not at all obvious.

>>> This solution is to make available a modified Finished calculation
>>> that a patched client can use for all handshakes including the
>>> initial one.  This solution does not even break compatibility with
>>> old clients -- a server would support BOTH the old and the new
>>> Finished message computation and do the right thing based on which
>>> one was used by the client.
>>
>> message computation on an initial handshake (or else it must add a
>> fallback in order to connect to those servers, which is undesirable).
>> Therefore, it isn't distinguishable from an unpatched client by
>> looking at cleartext handshake messages.
> 
> I'm suggesting to give up cleartext patch status for better attack
> detection and better interoperability since there is NO change to bits
> on the wire, no need for extensions or even TLS (SSLv3 can be fixed in
> exactly the same way).

My proposal also fixes the Finished hash computation for SSLv3 in
exactly the same way as for TLS.

> A server can actually log when neither Finished message calculation
> matches and alert the proper people to investigate the attack.

Such logging is not particularly useful if the attacker will just
avoid attacks that won't work and would be logged.

All else being equal, being able to distinguish attacks that failed
from interoperability problems would be nice, but it often isn't
feasible, and I don't think that's a big problem.

>> have this disadvantage [of not signalling patched status in cleartext].
>> It also does not rely on the extension for anything other than detection
>> of patched/unpatched status.
> 
> requiring extensions.

That is not correct, it is compatible with SSLv3:

 - If the client is using the lenient policy, then it still SHOULD send
   the extension, but sending the extension is not *required* -- even on
   renegotiations, unlike RI. There is no loss of security by not doing
   so, only a loss of information to the server.

   The disadvantage to the client of not sending the extension on the
   initial handshake is that a strictly configured server might refuse to
   accept that connection. I wouldn't expect this to be much of a problem
   in practice, because that server policy is only tenable in tightly
   controlled environments where there is an intention to upgrade all
   clients and servers together, which is rather inconsistent with the
   assumption that SSLv3 is still in use.

   (Note: all patched servers would reject connections where they see
   a renegotiation and the client didn't include the verify_data in the
   hash. The above stricter policy is only needed to prevent attacks in
   which an unpatched client sees the renegotiation, and is connecting
   to a patched server that sees an initial handshake.)

 - Like RI, it is fully compatible with SSLv3-only servers that are
   TLS- and extension-tolerant.

 - Unlike RI, a lenient client that does not send the extension need not
   support TLS. (I don't think this is really an important advantage in
   most situations, since almost all software-implemented clients already
   support TLS. There might be some SSLv3-only embedded clients where
   you want an absolutely minimal patch, I suppose.)

---

From: Nasko Oskov <[email-masked]>
Date: Mon, 16 Nov 2009 19:14:50 +0000

David-Sarah Hopwood wrote:
>>> It is not "completely wrong". For a patched client, not sending a 
>>> signal on the initial handshake (regardless of the form of that 
>>> signal) matters if-and-only-if the client is going to refuse to 
>>> interoperate with unpatched servers.
>> 
>> We can't protect against that behavior.  It may initially be necessary 
>> to do this until widespread adoption of the fix happens, but it is 
>> certainly not safe long term.
>

I agree that we should allow both strict and lenient client policies. This
can only be done if the server signals its patched state to the client.

>> In order to continue providing service to clients, it may be 
>> configured to still perform insecure renegotiations during a transition period.
>
>> RI extension. If the client has a fallback to not use the RI 
>> extension, then the MITM is able to cause the client and server, both 
>> of which are patched, to revert back to insecure behavior.
>
>mechanism is implemented. If the patched client refuses to renegotiate when
>it is in fallback mode, then I cannot immediately see any attack.
>
>I agree that both your proposal and mine are potentially more robust than
>RI here, since they both change the Finished hash computation for

One benefit of sending information on the wire between the client and the
server is that if both ends are patched and configured as lenient, they are
still secure. MiTM mocking with any of the traffic is bound to break the
finished message comparison, so as long as client and server signal each
other, they are safe. This IMHO is a big plus of signaling between the two
sides. It can be achieved using an extension or with mocking with the
*Hello messages. I believe the extension approach will have more defined
interop story than changing anything in the messages.

>> With my proposal, it is also possible for a MITM to alter the 
>> handshake, but the difference is that the server can prove it happened 
>> since neither Finished computation will match.
>
>If the server is configured to perform insecure renegotiations, then in
>your proposal it must accept a client Finished message with the unchanged
>hash computation. So an attack is certainly possible when the client is
>unpatched. I'll have to think some more about the security of RI in the
>fallback case when both client and server are patched (but lenient); it's
>not at all obvious.

It should be secure. MiTM should not be able to alter the messages in the
TLS handshake without detection (otherwise we have bigger problem). As long
as client and server both send the info to the other party, we are secure
even in lenient mode. Am I missing something?

>>>> one was used by the client.

I believe this requires keeping a more state data than the finished messages
-> more memory intensive on the server side.

>My proposal also fixes the Finished hash computation for SSLv3 in exactly the same way as for TLS.

Now, can you add *reliable* signaling in both directions?

Nasko

---

From: <[email-masked]>
Date: Mon, 16 Nov 2009 17:47:36 -0500

>>RSA, The Security Division of EMC, has created a 
>>TLS Interoperability Server to allow inter-op 
>>testing of TLS.

>Does it support the renegotiation extension?

Yes it does.