Re: openssl DTLS support?
>>>>> On Wed, 25 May 2011 18:32:59 -0400, John Zavgren said: JZ> I've been trying to configure (and build) net-snmp so that it supports the JZ> DTLSUDP transport (as well as SSH). I keep getting informed that I need an JZ> openSSL library that supports DTLS. The most recent version of OpenSSL should have it turned on by default. Once you have it installed, then you should rebuild net-snmp using the net-snmp configure flags required ./configure --with-transports="DTLSUDP" --with-security-modules="tsm" And you should probably ask questions to the net-snmp mailing list about issues with DTLS in Net-SNMP itself. Any recent OpenSSL version should be fine to use. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: (DTLS) Nexuiz needs information on the open-ssl UDP stuff.
> On Thu, 16 Apr 2009 22:44:36 +0200, Michael Tüxen > said: MT> Steven has applied all patches Robin provided for DTLS. So MT> they should be included in the next releases of OpenSSL. That's certainly good news! -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: (DTLS) Nexuiz needs information on the open-ssl UDP stuff.
> On Sat, 11 Apr 2009 22:49:46 -0700 (PDT), Miguel Ghobangieno > said: MG> They're all multi-treaded. How to do it in a single threaded app MG> with multiple users? Here's another documented example of a working hack: http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes Hopefully future versions of OpenSSL will incorporate some of the necessary fixes posted by others to get around this type of method of doing things. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
> On Thu, 22 Jan 2009 06:10:36 +0100, Robin Seggelmann > said: RS> To avoid getting into trouble with already fixed bugs you should apply RS> the patches I sent to the dev list. I'll set up a website with a patch RS> collection and some instructions soon. You've certainly posted a lot! I've found a few and documented them at [1] but I'm sure the list isn't complete. A web page, when you get the chance, describing your work would be very helpful! Footnotes: [1] http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes#Writing_a_new_UDP_BIO -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
> On Mon, 26 Jan 2009 18:19:02 +0100, Daniel Mentz said: DM> I have some comments regarding your wiki article. But first of all DM> thanks for taking the time writing down all this information: Your welcome, and I'm sorry for taking so long to reply to your note... I was both sick for a week and out of town for a week and am just getting caught up again. (btw, I suspect if you followed the conversation that Robin's patches [1] to fix OpenSSL's DTLS handling are potentially much better than my hackary.) DM> I do not use a memory BIO for sending data. I create a datagram BIO DM> instead and let OpenSSL write to this datagram BIO directly. Yep, you're right that this would work as well. Outgoing wise, it's not an issue like it is incoming-wise. DM> When it comes to receiving data from the UDP socket I create a new DM> memory BIO for *each* packet I received via recvfrom() and pass that DM> memory BIO to OpenSSL. Hmm... ok, though I'm not sure why you can't reuse an existing BIO unless you're battling memory issues (which I suspect is the case). Either way, thanks for your notes on your implementation. DM> I've got a question regarding your solution for sending data: How do DM> ensure that the message boundaries are preserved? ... DM> What happens if the SSL_* function wants to send more than one UDP DM> datagram at once? I *guess* this could happen if someone wants to send DM> a very large certificate (chain). To me it seems like that you're DM> assuming that OpenSSL sends only a single packet during one invocation DM> of SSL_*, aren't you? If OpenSSL happens to send two packets you're DM> going to concatenate the payload and send out one large datagram DM> instead of two smaller ones. You're right... It technically should never happen according to the DTLS specs, *assuming* that the implementation isn't trying to send a second packet before waiting for the response to the first. The DTLS RFC requires that all DTLS messages must fit in a single UDP datagram and I doubt the internal implementation is sending multiple messages at once. But you're right, if it does try to I'm stuck as is and will fire both off in a single packet. On the bright side though, I suspect that if the other side is simply reading a bunch of data from the UDP socket and is openssl based it too will not care because the message boundaries on the incoming side are also ignored. This only works if both sides are equally broken and ignoring the UDP framing :-/ DM> As regards DTLS Cookie handling I suggest to ignore the information DM> hiding/data abstraction principle for now and to access OpenSSL's DM> internal variables in order to find out in which state the OpenSSL DM> state machine is right now. I guess that there's some way to find out DM> whether OpenSSL sent out a HelloVerifyRequest or a ServerHello. If it DM> just sent a HelloVerifyRequest we could just destroy the SSL object DM> and wait for the client to send back the Cookie. Yep. I've thought of that as well. sigh... but the right solution would be to fix the OpenSSL implementation. Footnotes: [1] http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes#Writing_a_new_UDP_BIO -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
> On Thu, 22 Jan 2009 06:10:36 +0100, Robin Seggelmann > said: RS> As a workaround you can use connected UDP sockets. Just use accept() RS> and connect() as you would with TCP connections and create new BIO and RS> SSL objects for every connection. I have tested that and it works RS> pretty well so far. And that prevents OpenSSL from reading too much data from the socket? If so, that's certainly a good thing. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS server implementation experiences and documentation
> On Thu, 22 Jan 2009 06:10:36 +0100, Robin Seggelmann > said: RS> As a workaround you can use connected UDP sockets. Just use accept() RS> and connect() as you would with TCP connections and create new BIO and RS> SSL objects for every connection. I have tested that and it works RS> pretty well so far. And that keeps OpenSSL from reading too much data from a single socket? If so, that'd certainly be a good thing. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DTLS server implementation experiences and documentation
I recently tried playing with the DTLS code within OpenSSL, but it contains multiple problems. I know from reading the archives that other people have had issues trying to figure out the details of what is needed to use the DTLS code. So, since I actually got things working (albeit in an interesting way) I thought I'd actually write up the results so that others might benefit. The biggest issue comes from needing to deal with multiple clients trying to talk through the same UDP port, which isn't handled by at least the 0.9.8i code at least. I'd love feedback on some of my conclusions. I'm not in any way an OpenSSL exert and dove further into the code this time than I have in the past. But I'm not swimming in the deep end yet. The write up is written on the Net-SNMP wiki, since that's what I was working on it for. It's written fairly generically so you don't need to understand SNMP (and people who know SNMP don't need to know a huge amount about OpenSSL). IE, There is a fair amount of introductory text. http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
