I have been working since mid-November in my "copious spare time" to bring DTLS support into ruby-openssl in order to bring DTLS into the Rails "David" CoAP server.
DTLS_listen() seems entirely focused on single-use situations like in RTP, where only a single connection (single DTLS session) is expected. If used in CoAP situation, there are a number of race conditions that make it hard to use correctly. I wrote another email about that, which I think did not get to the list, which I can resend. I have preserved DLTSv1_listen() functionality, refactoring most of it into DTLSv1_anwerHello(), and then adding DTLSv1_accept() on top of it. Unfortunately I was also forced to delve into dgram_bss.c in order to bring some additional information out; stuff which is rather OS dependant for IPv4, and which perhaps would be better done in the application somehow. I'm looking for advice. Also, I found it difficult to find the right incantation to get a static build; I noticed finally that my test/* programs were linking against the libssl that was in my /lib, rather than the code I was testing. I suggest that this be captured into a ./Configure option. I used: ./Configure no-shared --debug linux-x86_64 "no-dso" seemed like it ought to help, but it made things worse... I hope that I added the new exposed symbols correctly. I have yet to validate the complete david/coap/ruby-openssl/dtls functionality, but I wanted to post this sooner for review. https://github.com/openssl/openssl/pull/5024 says: This patch refactors the DTLSv1_listen() to create an alternative API that is called DTLSv1_accept(). DTLSv1_accept() is useable by programs that need to treat DTLS interfaces in a way similar to TCP: new connections must be accepted, and new sockets created. There are a number of changes included here: 1. dgram_write() and dgram_read() now use sendmsg(2) and recvmsg(2) in order to set and collect the local address used in the datagram. This allows a socket to bound to ::, while still sending traffic correctly from the address that the other peer used. The IPv6 version of this code is according to rfc3542 API, but the IPv4 of the code is Linux specific and needs to be either abstracted and translated for *BSD and Windows, or IPv6 mapped IPv4 sockets could be used. 2. a new BIO control SET_ADDR and GET_ADDR are added, and if the address is not set then it pulls it out of the socket using getsockname(2). 3. DTLSv1_accept() accepts a second SSL* on which new connections are setup. A new socket is set up using the addresses from the received message and it is inserted into the BIO. There is a race condition during setup which turned out to be unavoidable: between the bind(2) and the connect(2), the new socket could have the same address as the "listen" socket, and additional hello packets could arrive on the wrong socket. Such packets will hopefully be dropped as garbage. It was thought that connect(2) could be called before bind(2), but that seems to cause the kernel to allocate a local address for the new socket (a random port), which the subsequent bind(2) can not seem to change. 4. the use of POSIX socket APIs inside this code is likely inappropriate and this routine should be split up in some better way so that socket activities can be done by the application, using the correct abstractions for the OS. 5. a new test case dtlsaccepttest was created. It uses fork() and also calls system() on "openssl s_client". Probably it should just call code internally, but apps/* is not in a library form that can be used. Perhaps this use is acceptable. Other test functions just use canned packets in/out, but since this is testing the creation/adaption of socket code, real sockets would seem to be necessary. Probably this test case should be disabled on non-Unix platforms. 6. routines BIO_ADDR_sockaddr and BIO_ADDR_sockaddr_size exposed from libcrypto to libssl. There might be a better way to do this, perhaps a BIO_CTRL would be better? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Description: PGP signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev