I would like to ship a client for Cisco's "AnyConnect" VPN in Fedora. AnyConnect uses a version of the DTLS protocol which slightly predates RFC4347, and is in fact based on the version that was implemented in OpenSSL around version 0.9.8e. I've reverse-engineered the differences, and posted a patch to the openssl-dev list: http://marc.info/?l=openssl-dev&m=122268270219339&w=2 It could do with someone more clueful about TLS and OpenSSL going over it -- and because it adds a new compatibility option, it should probably get into OpenSSL upstream before we ship it.
Yes, it should definitely go into upstream first.
It could do with someone more clueful than I to shepherd it there. I am entirely clueless when it comes to this stuff. Could I trouble you to respond to my patch on openssl-dev with a basic review? Thanks.
Just looking quickly at it - there might be problem with setting the s->version to DTLS1_BAD_VER based on the option which means you have to modify so many tests for the DTLS. IMO clearer approach would be to just use the option on places where the CISCO protocol really requires to use the DTLS1_BAD_VER instead of the DTLS1_VERSION.
Actually I think the patch comes out smaller that way. We do modify s->version elsewhere, when we want to start communicating with a different version of the protocol. If we don't do that, we have a lot more sites to modify, where we no longer send or expect s->version in a packet but instead hard-code DTLS1_BAD_VER instead. I tried it; the patch at http://david.woodhou.se/no-change-version.patch still isn't working and is already larger than the previous one.
We're now shipping the openconnect client for Cisco VPN, but it still doesn't work with DTLS because we need this patch... http://rt.openssl.org/Ticket/Display.html?id=1751 (guest/guest)
Unfortunately upstream rejected this patch.
I don't think so. Someone expressed reservations about applying it to HEAD, where we don't even have _server_ support for DTLS1_BAD_VER at the moment. But for the 0.9.8 branch I think they're just being characteristically slow. I'm sure they're not really going to tell us that we need to do our own completely new implementation of DTLS just to interoperate with the older OpenSSL-specific version of DTLS, rather than applying this simple patch.
Now committed to OpenSSL upstream (both 1.0.0 and 0.9.8 branches). http://cvs.openssl.org/chngview?cn=18037 http://cvs.openssl.org/chngview?cn=18036
openssl-0.9.8k-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/openssl-0.9.8k-4.fc11
openssl-0.9.8g-13.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/openssl-0.9.8g-13.fc10
openssl-0.9.8g-13.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openssl'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3806
openssl-0.9.8g-13.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
openssl-0.9.8k-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.