So after a weekend of fun with DTLS, OpenSSL, and OpenSSL.NET, I am not entirely onboard with the idea of using it as the backend for our P2P Security system. So let me list my pros and cons of using DTLS:
Pros:
- Maintained by someone else
- FIPS certified
- Availble for all platforms
- Popular, well documented protocols
Cons:
- Lacks the level of documentation found for most of the other libraries I've used
- DTLS is scarcely mentioned on the website and it is unclear to me how well it is actually maintained
- DTLS (manual) renegotiation is broken
- The library doesn't really make it easy to determine when a SSL session should be aborted
- There is no async callbacks for when data is ready, which would be really helpful for handshake messages
- Platform dependent (i.e. library -- ABI -- is not portable, API is)
- The DTLSv1_methods lack the reliability layer that is actually in the DGRAM BIO
Given that there is an existing Security library in Brunet that actually handles the above cons lacking FIPS and support by others, it feels like I am between a rock and a hard place. My real goal was to get enough knowledge to add the details in my paper comparing my experiences with a standard DTLS implementation in comparison to a home brewed version. Since the transition to DTLS hasn't been entirely smooth sailing, I am a little hesitant to jump on board. I suppose two things need to be ensured to me, that renegotiation works and that messages are still transferable during renegotiation. While waiting, I may just test out what actually happens in systems that rely on DTLS, because I have a feeling that the libraries are significantly faster than .NET crypto libraries.
Note: I stand corrected, the DTLS bug is fixed in version 1.0.0 betas, though with a new added twist of segmentation faults!
longchamp outlet
ReplyDeletepg 1
yeezys
nike sb dunk high
bape clothing
nike lebron 15
supreme new york
lebron shoes
supreme hoodie
pg shoes