Re: TLS break

2009-11-25 Thread Nicolas Williams
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:
 Anyone care to give a layman's explanation of the attack? The 
 explanations I have seen assume a detailed knowledge of the way TLS/SSL 
 handle re-negotiation, which is not something that is easy to come by 
 without reading the RFC. (As opposed to the main protocol, where one can 
 find textbook descriptions.)

Not to sound like a broken record, and not to plug work I've done[*],
but IMO the best tool to apply to this situation, both, to understand
the problem, produce solutions, and to analyze proposed solutions, is
channel binding [0].

Channel binding should be considered whenever one combines two (or more)
two-peer end-to-end security protocols.

In this case two instances of the same protocol are combined, with an
outer/old TLS connection and an inner/new connection negotiated with the
protection of the outer one.  That last part, negotiated with the
protection of the outer one may have led people to believe that the
combination technique was safe.  However, applying channel binding as an
analysis technique would have made it clear that that technique was
vulnerable to MITM attacks.

What channel binding does not give you as an analysis technique is
exploit ideas beyond try being an MITM.

The nice thing about channel binding is that it allows you to avoid
having to analyze the combined protocols in order to understand whether
the combination is safe.  As a design technique all you need to do is
this: a) design a cryptographically secure name for an estabilished
channel of the outer protocol, b) design a cryptographically secure
facility in the inner protocol for veryfying that the applications at
both ends observe the same outer channel, c) feed (a) to (b), and if the
two protocols are secure and (a) and (b) are secure then you'll have a
secure combination.

[*] I've written an RFC on the topic, but the idea isn't mine -- it
goes as far back as 1992 in IETF RFCs.  I'm not promoting channel
binding because I had anything to do with it, but because it's a
useful technique in combining certain cryptographic protocols that I
think should be more widely understood and applied.

[0] On the Use of Channel Bindings to Secure Channels, RFC5056.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-17 Thread Ben Laurie
On Mon, Nov 16, 2009 at 11:30 AM, Bernie Cosell ber...@fantasyfarm.com wrote:

 As I understand it, this is only really a vulnerability in situations
 where a command to do something *precedes* the authentication to enable
 the command.  The obvious place where this happens, of course, is with
 HTTPS where the command [GET or POST] comes first and the authentication
 [be it a cookie or form vbls] comes later.

This last part is not really accurate - piggybacking the evil command
onto authentication that is later presented is certainly one possible
attack, but there are others, such as the Twitter POST attack and the
SMTP attack outlined by Wietse Venema (which doesn't work because of
implementation details, but _could_ work with a different
implementation).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-17 Thread Stefan Kelm

Jonathan,

Anyone care to give a layman's explanation of the attack? The 


I find this paper to be useful:

  http://www.g-sec.lu/practicaltls.pdf

Cheers,

Stefan.

--
Stefan Kelm   sk...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstrasse 100 Tel: +49-721-96201-1
D-76133 Karlsruhe Fax: +49-721-96201-99

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-16 Thread Jonathan Katz
Anyone care to give a layman's explanation of the attack? The 
explanations I have seen assume a detailed knowledge of the way TLS/SSL 
handle re-negotiation, which is not something that is easy to come by 
without reading the RFC. (As opposed to the main protocol, where one can 
find textbook descriptions.)


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-16 Thread Eric Rescorla
At Tue, 10 Nov 2009 20:11:50 -0500,
d...@geer.org wrote:
 
 
  | 
  | This is the first attack against TLS that I consider to be
  | the real deal. To really fix it is going to require a change to
  | all affected clients and servers. Fortunately, Eric Rescorla
  | has a protocol extension that appears to do the job.
  | 
 
 ...silicon...

Is the relevant silicon really this unprogrammable?

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-16 Thread Victor Duchovni
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:

 Anyone care to give a layman's explanation of the attack? The 
 explanations I have seen assume a detailed knowledge of the way TLS/SSL 
 handle re-negotiation,

The re-negotiation handshake does not *commit* both parties in the
new handshake to the previous cryptographic state of the TLS connection.

If the man in the middle is willing to encrypt/decrypt handshake packets
between a client new to the connection, and a server with which the
MITM completed an earlier handshake, the MITM can transfer an existing
session from himself to the client (victim), after injecting some initial
data into the connection.

The integrity and confidentiality properties of the origimal MITM-server
connection only protect both parties if neither party is willing to
compromise those properties by proxying a 3rd party into the session.

The new ingredient here, is that the 3rd party can be a victim, who is
unaware of the proxying. The victim's handshake with the intended server
is proxied into an already established TLS session by the MITM who is
privy to the session state.

The solution is to *commit* the two parties to a re-negotiation handshake
to the previous handshake.

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-16 Thread Bernie Cosell
On 11 Nov 2009 at 10:57, Jonathan Katz wrote:

 Anyone care to give a layman's explanation of the attack? The 
 explanations I have seen assume a detailed knowledge of the way TLS/SSL 
 handle re-negotiation, which is not something that is easy to come by 
 without reading the RFC. (As opposed to the main protocol, where one can 
 find textbook descriptions.)

I had a hard time with this, too, but this PDF really clarified it for 
me:

http://extendedsubset.com/Renegotiating_TLS_pd.pdf

Let me try a layman's explanation (assuming I have it right)

We start assuming the attacker can to hijack or MITM the victim's TCP 
connections.

The attacker opens *its*own* TLS connection to the server [so that is now 
being encrypted by a symmetric key the attacker picked] and sticks some 
data into the pipe.

The victim wants a TLS connection and so begins negotiating one.  The 
attacker just MITM's that as a *renegotiation* with the server for its 
TLS connection.  (that is, the victim thinks they're negotiating a NEW 
TLS connection, but the attacker proxies that into a *renegotation* on 
the existing TLS connection).  In short order the attacker is frozen out 
of the connection [since it will then be encrypted by a key picked by the 
victim], BUT: the victim's data will ride over the TLS connection that 
the attacker had previously set up and pre-loaded with some data, and so 
the victim's data *FOLLOWS* the attacker's -- the attacker was able to 
inject arbitrary data *in*front* of the victim's data.

As I understand it, this is only really a vulnerability in situations 
where a command to do something *precedes* the authentication to enable 
the command.  The obvious place where this happens, of course, is with 
HTTPS where the command [GET or POST] comes first and the authentication 
[be it a cookie or form vbls] comes later.

  /bernie\

-- 
Bernie Cosell Fantasy Farm Fibers
mailto:ber...@fantasyfarm.com Pearisburg, VA
--  Too many people, too few sheep  --   



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-11 Thread Chimpy McSimian IV, Esq.
On Mon, Nov 9, 2009 at 5:08 PM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:

 attack, checking Referrer headers is no longer effective, so anti-CSRF
 defenses have to be more sophisticated (they *should* of course be more

Checking the Referer header never was effective. It's not even
guaranteed to be present, let alone true.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-11 Thread dan

 | 
 | This is the first attack against TLS that I consider to be
 | the real deal. To really fix it is going to require a change to
 | all affected clients and servers. Fortunately, Eric Rescorla
 | has a protocol extension that appears to do the job.
 | 

...silicon...

--dan

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-10 Thread Victor Duchovni
On Sun, Nov 08, 2009 at 01:08:54PM -0500, Perry E. Metzger wrote:

 I'll point out that in the midst of several current discussions, the
 news of the TLS protocol bug has gone almost unnoticed, even though it
 is by far the most interesting news of recent months.

Not entirely unnoticed:

http://www.porcupine.org/postfix-mirror/wip.html#tls-renegotiation

For HTTPS, it has been observed that this is not entirely different
from existing CSRF attacks, but it should be noted that with the new
attack, checking Referrer headers is no longer effective, so anti-CSRF
defenses have to be more sophisticated (they *should* of course be more
sophisticated, but they rarely are, if they are present at all).

I am looking forward to analyses for other protocols.

There is almost certainly a problem for FTP (over TLS), where just
banning re-negotiation on the server is perhaps reasonable.

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: TLS break

2009-11-10 Thread Tom Weinstein

Perry E. Metzger wrote:

I'll point out that in the midst of several current discussions, the
news of the TLS protocol bug has gone almost unnoticed, even though it
is by far the most interesting news of recent months.


Perhaps because there have been so many false alarms over the years. 
Usually when I hear about an SSL MITM attack, it's really a browser UI 
spoofing attack with a bogus cert.


This is the first attack against TLS that I consider to be the real 
deal. To really fix it is going to require a change to all affected 
clients and servers. Fortunately, Eric Rescorla has a protocol extension 
that appears to do the job.


--
Give a man a fire and he's warm for a day, but set | Tom Weinstein
him on fire and he's warm for the rest of his life.| twei...@pacbell.net

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


TLS break

2009-11-09 Thread Perry E. Metzger

I'll point out that in the midst of several current discussions, the
news of the TLS protocol bug has gone almost unnoticed, even though it
is by far the most interesting news of recent months.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com