On Mon, 2013-02-11 at 13:24 -0800, Ben Laurie wrote: > > Ah, it looks like you only moved the offending code; it was actually > > Ben's fault in commit 9f27de17 / 014265eb. > > Gah! I wish tests would pick up stuff like this!
As far as I'm aware there are no tests for DTLS1_BAD_VER. Apart from my users :) We don't even have server-side support for it in OpenSSL any more. It's only kept around for compatibility with Cisco AnyConnect, and I don't think *they're* doing anything at all towards its upkeep — and although they could happily run DTLS1.0 in parallel on the server and have a migration path to sanity, they aren't doing that *either*. However, we do *only* ever use it in 'session resume' mode. The session-id and master secret are negotiated out-of-band with the authentication, over TCP. When I was introducing SSL_OP_CISCO_ANYCONNECT and subsequently hacking on stuff to find breakage, I've hard-coded those and the random number generator and have at least used basic replay techniques for sanity checking. I ended up with stuff like http://david.woodhou.se/dtls-test.c -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
