[openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD

[Matt Caswell]

On 03/03/15 15:03, Nikos Mavrogiannopoulos wrote:
> On Tue, 2015-03-03 at 14:43 +0000, Matt Caswell wrote:
> 
>>> It's the wrong thing to test against *anyway* since there are plenty of
>>> failure modes in which a regression could be introduced in generic code
>>> and OpenSSL would remain compatible with *itself* anyway.
>>> So I'm torn between doing a minimal reimplementation of the server side
>>> and making OpenSSL talk to that, or a dirty replay attack such as the
>>> one I had when I was first working it out:
>>> http://david.woodhou.se/dtls-test.c
>> The minimal reimplementation sounds like it might be the more flexible
>> base to work from (and could even be the basis for future DTLSv1/1.2
>> tests). But it also sounds like quite a bit more work to me. Either way,
>> having *some* tests has got to be a lot better than *no* tests like we
>> have now!
> 
> I don't know whether you'd like to depend on gnutls for testing, but I
> have a test of most ciphersuites [0] in common under various protocols
> between openssl and gnutls. That currently doesn't cope with DTLS0.9
> (gnutls' name of DTLS_BAD_VER), but could easily extend to handle it.
> 
> regards,
> Nikos
> 
> [0].
> https://gitorious.org/gnutls/gnutls/source/3754af1c694c829c89ea7865ac1718a763c682c4:tests/suite/testcompat-main-openssl

That's an awesome idea. I love the idea of a cross-implementation test.

I see two problems:
1) Probably we can't introduce a gnutls dependency except for those that
explicitly request it (e.g. perhaps some developer config flag to enable it)
2) The killer: the gnutls licence is incompatible with the OpenSSL
licence ... I don't think (?) that causes a problem if we're just
executing the binary (we wouldn't be *linking* to it), but the test
script you point to couldn't be incorporated with that licence :-(

Matt