
Comments on a Formal Verification of PolarSSL - jeffreyrogers
http://blog.regehr.org/archives/1261
======
tptacek
My advice hasn't changed in the last few years: avoid the idiosyncratic TLS
libraries, and stick with OpenSSL / BoringSSL / LibreSSL. Libraries like
PolarSSL are (somewhat) less likely to have the simple memory corruption bugs
that OpenSSL has had, but more likely to have crypto flaws.

~~~
jly
I don't disagree with you, but mbed TLS and other similar libraries partly
exist to solve the need for high-quality crypto/TLS in very small operating
environments, where it may not be possible or easy to use OpenSSL. They are
designed to be highly modular and lightweight, and easy to integrate custom
crypto acceleration hardware. I don't know enough about OpenSSL to say whether
it's easy to work with in these environments, but this is why these
idiosyncratic libraries exist, and it may not be as simple as 'just use
OpenSSL' in all cases, especially for the non-TLS crypto parts.

~~~
richm44
Last time I checked mbed TLS omitted lots of pretty critical functionality
such as certificate verification to the user - this stuff is far from trivial
and is a core component of the MITM protection.

------
diafygi
> _If we don’t want UBs, why not just use a TLS written in Java or C# or some
> other safe language? Of course that’s a fine idea! But we’ll have to somehow
> shoehorn a Java runtime onto those embedded processors with ~64 KB of RAM
> where PolarSSL / mbed TLS run._

Would this be a good use case for Rust? Are there any Rust TLS projects that
are credible?

~~~
aroch
A couple people have attempted re-implementations of OpenSSL's TLS functions
(with API compat) in Rust. As far as I know, all of these are stalled /
abandoned. It is too hard for one individual to do it, especially when that
individual isn't a security pro.

Mostly Rust uses libraries that wrap OpenSSL and attempt to do some
verification of "safeness" before passing to OpenSSL

~~~
viraptor
I don't think that anyone (unless it's a sponsored team effort) will implement
tls in Rust for a long time. At least not as pure-rust library. Before you
even touch the tls layer you need: asn1, x509, crypto, network libs. Out of
those, only crypto and network libs exist and are fairly young. Asn1 and x509
are slightly insane and will require months of development on their own. (and
that's before you even get into useful extensions everyone wants, like ocsp)

What's good though is that someone writing pure-rust-tls in a year or two can
start with implementation that ignores anything below TLS1.2 and save a lot of
code and scope for errors that way.

~~~
aroch
I once looked at making a toy ASN.1 parser for project...and quickly decided
my time and sanity were best spent elsewhere

