Hi,
On October 7, 2003 03:58 am, Richard Levitte - VMS Whacker wrote:
> As has been seen in my last few commits, I got a bit obsessed with
> compression. The way it works now, at least in 0.9.8-dev, is
> compliant with draft-ietf-tls-compression-05.txt, as far as I can
> tell.
Cool.
> The only thing that remains is something that itches me quite a bit.
> As soon as SSLv23 is used, we can kiss compression goodbye, even if
> SSLv2 has been disabled.
This is a side-effect of SSLv2 (and thus v2-compatible ClientHellos) not
having any concept of a compression method.
> Since I haven't gone too much into the ssl/ part of OpenSSL, I have a
> hard time figuring out what's appropriate to do here. What I would
> *like* to do is have the SSLv23 connect make a SSLv3-compatible
> connect when SSLv2 has been disabled, instead of the current behavior
> (always a V2ClientHello, no matter what). Is that a feasible thing to
> do? What traps could I fall in to? What quirks should I watch out
> for? Will that work with the servers out there (provided they aren't
> SSLv2-only)? Other thoughts?
Not being the ultimate SSL/TLS guru, I can't tell you offhand what you
should do. One of the problems is that using using a sslv3 (0x0300) or
tlsv1 (0x0301) method for connect/accept will not negotiate with the
other. AFAICS, the only way to negotiate the version number at all is via
the v2-compatible method which is a bit annoying. Then again, perhaps I'm
missing something salient here. (You can see it by specifying "-ssl3"
and/or "-tls1" to s_server and s_client).
However, it seems to me that the arguments that show that SSLv2 is
vulnerable to cipher-selection attacks, equally show that using a
v2-compatible hello allows any attacker who can manipulate traffic to
force v2 even when both sides would prefer sslv3 or tlsv1. Eric-R or
someone else into this sort of thing, would you care to comment? My
half-baked analysis goes something like this; the v2-compatible hello (to
my eyes at least) can be easily rewritten as a v2-only hello and because
v2 handshaking would then follow (or an alert+close if the server doesn't
support v2) and no finish mac would arrive that would detect that the
original v2-compatible hello had been altered.
If I'm not too far lost in my logic here, we have;
(i) if the client does not use v2-compatible hellos, there is no
flexibility to dynamically select sslv3 or tlsv1.
(ii) if the client does use v2-compatible hellos, an active attack can
force the use of sslv2 whether or not both parties would have
prefered sslv3 or tlsv1.
(iii) compression can not be negotiated when using v2-compatible hellos.
Does any of that seem wrong? If not, what can be done? I'm not sure how
easy it would be to create a wrapper similar to "v23" that would
negotiate between sslv3 and tlsv1 using a tlsv1 ClientHello. In
particular, the handling of the handshake MAC might get a bit slimy in
the client and server code, and there may be protocol-related reasons why
this can't be deterministic anyway. (Thanks Richard for reminding me to
dump these thoughts BTW, though I've not helped much with your question
about compression have I?)
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
