Re:A New Development for Coverity and Heartbleed
by tptacek on Saturday April 12, 2014 @06:11PM
(#7579398)
My advice is not to use obscure TLS libraries in production. Look at the recent Frankencerts paper to see what goes wrong: only OpenSSL, NSS, and Bouncycastle (the mainstream libraries) properly rejected pathological X.509 certificates.
If you're trying to deploy pure-Python applications, I like tlslite. Of course, I have to say that, because Trevor is much smarter than me.
Personally, I think your realistic production choices are OpenSSL or NSS.
Re:A New Development for Coverity and Heartbleed
by hf on Saturday April 12, 2014 @06:28PM
(#7579446)
Vacillating between floating away on my recently-inflated feeling of
self-worth and trying to keep you engaged on a very uneven playing field
(as in my not knowing Adam from Eve, so to speak), I'll simply opt for
another Thank you.
Re:A New Development for Coverity and Heartbleed
by tptacek on Saturday April 12, 2014 @06:29PM
(#7579456)
Apropos nothing else: tlslite and Adam Langley's golang/crypto/tls are the two best codebases on the Internet to (a) learn TLS from and (b) build tools with. They are both extremely great projects.
Re:A New Development for Coverity and Heartbleed
by ghshephard on Saturday April 12, 2014 @09:40PM
(#7579841)
The TLS library that our company uses for its applications is http://www.yassl.com/yaSSL/Home.html. Not sure if it's considered obscure or not.
What, however, hinders adoption as a "working man's" TLS library? Neglecting performance and variety of cipher support, would or should anything prevent me from using Tiny TLS to secure channels between "inner circle machines" (that talk to a set of well-known participants)?