Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> 
> The DH_anon ciphersuites have been known and documented to be 
> susceptible to man-in-the-middle attacks for several years. This much
>  more a defect in the design of the DH_anon ciphersuites, not of the 
> TLS protocol itself.  This flaw of those ciphersuites seems to have 
> been so non-interesting, that no-one has tried to do anything about 
> it.

It's a fundamental property of anon-anon connections, not any "defect in
the design of DH".

> Btw. the TLS secure renegotiation spec does _not_ affect the 
> susceptibility of the DH_anon ciphersuite to man-in-the-middle 
> attacks in any way.

Not true.

The RI fix allows you to negotiate an anonymous connection then
renegotiate it to provide certificate authentication which retroactively
covers data exchanged over the previous session.

This is how HTTPS client certificates work, but you know that already.

> Which particular (broken) clients do you have in mind that you think 
> need to be educated with a complete ban on interoperability?

Probably anything implemented with Perl:

http://search.cpan.org/dist/Net_SSLeay.pm/SSLeay.pm
> At this moment the implementation of verify_callback is crippeled in 
> the sense that at any given time there can be only one call back 
> which is shared by all SSL contexts, sessions and connections...
> ...
> KNOWN BUGS AND CAVEATS
> 
> Callback set using SSL_set_verify() does not appear to work. This may
> well be eay problem (e.g. see ssl/ssl_lib.c line 1029). Try using
> SSL_CTX_set_verify() instead and do not be surprised if even this
> stops working in future versions.
> 
> Callback and certificate verification stuff is generally too little
> tested.

Except perhaps things using a higher-level
Net::HTTP("https://dns.name/")-type API.

Take a look at the client example code:
http://search.cpan.org/dist/Net_SSLeay.pm/SSLeay.pm#EXAMPLES
I would say it's vulnerable to this except that it doesn't bother to
check the name on the cert at all. :-)

Show me one tutorial on the web of "Here's how to use this SSL/TLS
library safely" which provides example code that does this correctly. It
may exist, but I haven't found it yet. The fact that I haven't found it
suggests strongly to me that there are plenty of vulnerable client apps
out there.

- Marsh