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? If it's post-0.9.8f-based, what's the problem?
Haven't you mentioned that it too accepts non-BAD_VER connections? If
it's not 0.9.8f, then we have to assume they patch it themselves.
Wouldn't it be reasonable to assume that their REAL_VER is
RFC-compliant? If it doesn't inter-operate, wouldn't it be more
appropriate to devote effort to figure out why? And if it turns out that
their REAL_VER is not RFC-compliant, then why did they choose REAL_VER
and not VENDOR_VER? In other words, can you remind the reason for
re-introducing BAD_DTLS:-) 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]?
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?
My vote still goes for *not* implementing BAD_VER in HEAD.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
