On October 8, 2003 02:41 am, Richard Levitte - VMS Whacker wrote: > geoff> Which reminds me, I'm not sure yet about my last post's > geoff> comments on this "sslv3/tlsv1 methods can't internegotiate" > geoff> stuff - I'm less sure now of what I was seeing than I was when > geoff> I was seeing it. > > In the OpenSSL implementation, that does seem to be true.
Good, I'm not going mad then. However, your quotation from the TLS1 spec did seem to confirm that clients and servers supporting SSLv3 and/or TLS1 should be able to negotiate version 0x0300 or 0x0301 whilst using the v3/1 record-layer and ClientHello format. The question becomes what to do to OpenSSL's implementation for this to happen. > geoff> However I still leave my other comments from that post up as > geoff> open questions; in particular, I'm still wondering how an > geoff> attacker could be prevented from rewriting SSLv2-compatible > geoff> ClientHellos as v2-only and getting away with it. > > I doubt an attacker can be prevented from doing that. After all, the > returned ServerHello will (or will not) confirm that v2 is the > protocol they will run. I personally believe that accepting SSLv2 is > a mistake. Do you mean that we should remove SSLv2 support from > OpenSSL? I would welcome that, but considering there are still > SSLv2-only servers out there (!!!), I'm not sure what the impact would > be for us, support-wise. Well it's a no-win situation I think. If you send a v2-compatible hello, you have to accept the price; (a) you can't negotiate compression, and (b) you could be forcibly downgraded to v2 by an attacker and thus you're subject to v2 weaknesses (no detection of truncation, no MAC over the handshake, ...). I think from the client point of view at least, it makes sense that if v2 is not required, we shouldn't send a v2-compatible ClientHello. If the server only supports v2, then the handshake will fail whichever way you go. OTOH: if the server supports sslv3/tls1, this will let the client propose compression if it wants and it will avoid/detect downgrade attacks. > However, my topic here isn't about SSLv2. My focus is much more on > SSLv3 and TLSv1 interoperability (and whenever that comes out, TLSv1.1 > should be included in that group as well). Well they go hand in hand. v2-compatible ClientHellos are already no doubt confusing your compression efforts, and moreoever they weaken the entire SSL/TLS system to the level of SSLv2's known deficiencies. The alternative, to use sslv3/tls1 ClientHellos, suffers from the fact that OpenSSL's only "negotiable" methods seem to be the v23 ones. FWIW: I think the main problem with having a 0x03 version-major method will be how to rewind the handshake MAC depending on which version-minor is selected. The server method should be able to substitute in sslv3 or tlsv1 methods, state, and initialisations the moment the first handshake message is parsed, but the client one will be trickier. Perhaps it should simply emit and cache the ClientHello binary data without performing sslv3 or tlsv1 logic, and then handle that once the server's response has been parsed - I would expect that logic could be generated from the SSLv3 method anyway (seeing as TLSv1 seems to steal/reuse most of it). No doubt the devil is in the details though. > geoff> I need to look closer at this too but I have a suspicion that > geoff> the vtable-gymnastics in the v23 wrapper might need to be > geoff> replicated for v31. Ie. perhaps we'll need a new > geoff> negotiator-method just for versions with major number 0x03? > geoff> Then again, perhaps this is already "there" but I just don't > geoff> see it yet ... :-) > > It looked like something of that sort is there already, but I'm still > pretty new at reading the ssl/ code... <AOL>Me too</AOL>. However I've been messing with it more extensively now than ever before, and I'm given to wondering if working on a parallel libssl directory (perhaps "./tls/" instead of "./ssl/"?) mightn't be a bad idea. The SSL/TLS layer itself is pretty horrid - loads of globals, some messy handling of cipher-suite lookups/tables, and some hairy and fungal growth seems to have taken over the SSL_METHOD/SSL design (particularly the hooking in of SSL3/SSL2 handlers and state). If we did this, we'd also have a chance to pin ourselves to a more strictly defined set of interfaces from libcrypto, making cleanups in libcrypto easier later on. There's also aspects of libssl that make bulk processing (hardware) extremely awkward. Dunno, I'm mostly thinking out loud here - I'm sure it could be a useful undertaking, but it would certainly need more concentration than I have right now. For what you're discussing, it would make sense to concentrate on the existing code (of course) - but I think this example is just one more reason that some "next generation" thinking is required, sooner or later. > I'd like there to be a much more general wrapper. It looks like the > current one is mostly built to allow the SSLv2-compatibility mode and > not much more (hence the name SSLv23). A more general wrapper would > be able to have any suitable version of SSL/TLS interoperate, > including future versions of TLS. Maybe there are already things in > place to do that, but I sure haven't been able to make them talk with > each other, yet. Well, I think that the point of that wrapper is to send or receive any kind of ClientHello and handle the necessary glue to sslv2, sslv3, and tlsv1 implementation code. The PITA is not just that v2-compatibility creates security and protocol headaches, but it also seems to be responsible for a lot of complexity that could disappear if v2-compatibility/formatting wasn't required. To this end, I think having a wrapper for protocol versions with a 0x03 major would allow a nice migration path. Client code could switch to it straight away if they want to be rid of SSLv2 (a good thing), and server code could selectively switch to it depending on whether v2 support is required or not - but right now you need to use the v23 methods even just to have negotiability between sslv3 and tlsv1, which is a bit nuts. 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]
