Apologies for delayed response. There was some bureaucracy to go through to make sure I had management approval for releasing the code which explains my interest in the subject.
That's done now; we have a full open source client for the VPN in question, and OpenSSL client support for BAD_DTLS_VER is the last piece in the jigsaw for me. http://git.infradead.org/users/dwmw2/openconnect.git git://git.infradead.org/users/dwmw2/openconnect.git On Wed, 2008-10-15 at 09:13 +0200, Andy Polyakov wrote: > >>> Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling > >>> is not present in HEAD (0.9.9). > >>> > >> That makes sense. > >> > >> I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the > >> pre-RFC version of DTLS was considered to be an OpenSSL-specific thing > >> that would quickly die out as people upgraded to 0.9.8f and beyond? > > Right. > > >> Now we've observed that there are servers in the wild which implement > >> that old OpenSSL-specific version of the protocol, but which we'd like > >> to be compatible with. > > Could you clarify? Haven't you mentioned that it's about Cisco > AnyConnect VPN? Isn't it OpenSSL-based? If it's pre-0.9.8f-based, then > shouldn't you question if it's appropriate to use it at all because of > security problems? They do update to a new version of OpenSSL periodically, and they also backport security patches even more frequently than that, allegedly. But their products use the pre-RFC version of DTLS, so they have to remain compatible with that. So even though they're currently on 0.9.8f, they're still using DTLS1_BAD_VER. Their server _does_ seem to accept some variant of the _real_ DTLS protocol, but it's strangely broken -- you have to calculate the MAC as if the version number in the packets was DTLS1_BAD_VER, even though it isn't. And although the _handshake_ works that way, the server still seems to ignore all incoming data packets. I strongly suspect that their implementation of REAL_VER is completely broken, and that there is _no_ way to interoperate with it. The real clients use DTLS1_BAD_VER, and that's what we need to use too. > And if it turns out that their REAL_VER is not RFC-compliant, then > why did they choose REAL_VER and not VENDOR_VER? They don't care about REAL_VER and probably aren't even aware that their server seems to accept it. They never use it, and it's not tested. If they do ever realise, they'll probably turn it off. > In other words, can you remind the reason for re-introducing > BAD_DTLS:-) _My_ reason for wanting to re-introduce DTLS1_BAD_VER is purely interoperability. There are servers out there which use it, which we really really want to talk to. And it's a fairly simple patch. > Even in worst case is DTLS the only option in > AnyConnect? I mean if it doesn't work, why not use TLS [till DTLS is > fixed to be RFC-compliant]? This is a VPN, and TCP over TCP _really_ sucks. The only viable option for connecting to these VPN servers is to use DTLS1_BAD_VER, really. > >> If I can actually get that working in HEAD, would > >> a patch to support it be acceptable? > >> > > I had a deeper look into the mailing list archive and I did not find > > any explicit statement on why this was handed differently in 0.9.8 > > and in HEAD. > > Finally we would of course prefer to move people to update to an > > RFC compliant version, so I guess the pre-RFC support should be > > configurable somehow. Andy, what do you think? With my patch, the pre-RFC support is only available if you manually set up a session to be 'resumed' that way. We don't need anything more, because the master-secret and session-id for the DTLS session are actually exchanged over HTTPS in advance. > My vote still goes for *not* implementing BAD_VER in HEAD. Please reconsider. Obviously the _correct_ thing for them to do is make REAL_VER work on the server in parallel with BAD_VER, then slowly migrate their clients to use REAL_VER and over time they can completely forget about BAD_VER. But this is a vendor of proprietary software. Of _course_ they don't have the wit to do that, and we have to interoperate with what we're given. -- dwmw2 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
