DTLS Protocol Support

[mestery]

This adds support for processing DTLS packets, specifically to acquire the
SNI value from the ClientHello packet. DTLS and TLS packets are different
enough that a separate parser was required. However, it appears extension
processing is the same. So I've moved both parse_extensions() and
parse_server_name_extension() into new sni.[c,h] files so those functions
can be shared by both the tls and dtls processors.

This code includes functional test for the DTLS parsing.

Related to issue #352.

Signed-off-by: Kyle Mestery mestery@mestery.com

[mestery]

@dlundquist Let me know your thoughts here. After this, some guidance on how I should approach the connection/listener code would be appreciated. Thanks so much!

[dlundquist]

Looks good, but I would like to hold off on merging until we get UDP support proved out.

[dlundquist]

@mestery I've started on adding datagram support to the listener and connection objects: 4f34b67...udp-poc, the recvmsg(), socket(), bind(), connect() sequence works to receive additional UDP packets of the same socket tuple on the connection's client socket. I'm not sure how portable this approach is, but we already have Linux specific features.

I tried testing with openssl s_client --connect 127.0.0.1:2000 -dtls1_2 and it the dtls protocol module was unable to process the request:

2020-03-28 10:47:07 Parsed localhost 127.0.0.1:2001
2020-03-28 10:47:10 Requested version of DTLS not supported.
2020-03-28 10:47:10 Unable to parse request from 127.0.0.1:45565: parse_packet returned -5

I think the next step is to get a DTLS functional test going.

[mestery]

Thanks for starting that work! Let me work on the functional test now as well.

[mestery]

I'll add a functional test now, thanks for working on this!

[mestery]

@dlundquist Functional test for DTLS added and the parsing code passes now, let me know how your branch looks! I think we're getting closer!

[mestery]

I rebased your udp-poc branch on top of mine and the openssl s_client commands appear to work now! I'll try your branch with my actual setup on Monday morning, but I think we're close to perhaps getting this merged!

[dlundquist]

@mestery I think we are going to need to preserve datagram framing in the buffer module, the present buffer was designed for a stream. My first though would be to just prepend a uint16_t with the UDP payload length. This may introduce alignment issues on platforms that do not allow unaligned word access. This could be resolved by always making the length prefix aligned, that would also avoid the edge case where the length is wrapped around the end of the circular buffer. But this requires either the connection module reaching into the buffer implementation to retain a pointer to where the length is to be stored before the receive, or making the buffer module stream/dgram type dependent.

Also, initiate_server_connect() will need to be taught to use UDP, but this is an outgoing UDP connection so it should be just changing SOCK_STREAM to con->listener->protocol->sock_type, maybe it's worth storing the socket type in the connection object too.

Honestly dynamic dispatch would make all of these stream/datagram differences a lot cleaner.

[mestery]

OK, I folded your commits into this branch, and added an initial stab at adding socket type to both Connection and Buffer structures. I don't quite follow what you're saying in terms of adding the UDP packet size to the buffer object, can you elaborate a bit more on that so I can tackle that next? Thanks for all the help here, this is moving quite nicely!

[mestery]

I tested the patch above and it is able to successfully proxy DTLS as well as TLS now for my application! I'm curious about your comments around datagram framing because I'm guessing something is still missing here, so let me know. Thanks for the help with this, it's pretty cool to see it working!

[dlundquist]

I think all the DGRAM specific bits can go in setup_read_iov(), setup_write_iov(), advance_read_position() and advance_write_position(). advance_write_position() would be responsible for storing the length prefix.

[dlundquist]

buffer_pop() and buffer_peek() can't differentiate between a zero length datagram and no more data -- I wonder if this is going to cause any unexpected problems?

[mestery]

Now that I've sorted out the issues on my end this is working perfectly well! From my perspective this code is ready to merge into master now, let me know your thoughts @dlundquist I will prioritize addressing whatever needs to happen to get this into master. Thanks!

[mestery]

@dlundquist I've got a few buffer fixes we've found running this PR internally, and I've got working functional testing via some DTLS code I found and a docker-compose.yml file. I shall update this PR by Friday with those changes.