3 ms·

Also note that s2n links with OpenSSL (or LibreSSL, BoringSSL) for the ciphers and ASN.1 functionality. At first I was really surprised/impressed/worried that

by wbond 11y ago

Also note that s2n links with OpenSSL (or LibreSSL, BoringSSL) for the ciphers and ASN.1 functionality. At first I was really surprised/impressed/worried that they managed to pull off an ASN.1 parser in C along with TLS is just 6,000 lines of code. Alas, they did not. So, when they mention the 500,000 lines of OpenSSL, they are probably actually using a good 20,000+ of it for ASN.1 and all of the ciphers. Yay marketing!

hga 11y ago
I think you're being unfair, for they say OpenSSL "contains more than 500,000 lines of code with at least 70,000 of those involved in processing TLS." And the next and last LOC reference is to their s2n, and it's entirely fair to say 6,000 LOC is qualitatively better than "at least 70,000", especially with all the focus, which they cite, on SSL/TLS protocol and implementation bugs.
danudey 11y ago
On the other hand, the attack area for OpenSSL is the TLS implementation itself, and not the ciphers. Linking against openssl/whatever for ciphers makes more sense than implementing them yourself, and now we can replace OpenSSL's huge, complete TLS implementation with a small, incomplete one that provides just what most people use in a small, auditable package.
gsnedders 11y ago
Still using it for ASN.1 is quite sad, given ASN.1 is where a fair few security bugs have been. If I'm not mistaken, this includes CVE-2015-0286, CVE-2015-0287, CVE-2012-2110, CVE-2009-0590, CVE-2009-0789, and CVE-2006-2937 from the last decade (and more if you go further back). The ciphers are pretty damned solid — the ASN.1 code… not so much. I'd argue that the ASN.1 parsing and the like is one of the areas that sorely needs replacing in OpenSSL, precisely because it has had so many vulnerabilities found in it over the years.
- userbinator 11y ago
  Incidentally, Fabrice Bellard has written a small ASN.1 compiler: http://bellard.org/ffasn1/ http://bellard.org/ffasn1/ However, he does not want to give it away. ASN.1 is a rather hairy standard overall, but AFAIK only a part of it is needed for TLS.

by wbond 11y ago

hga 11y ago

I think you're being unfair, for they say OpenSSL "contains more than 500,000 lines of code with at least 70,000 of those involved in processing TLS." And the next and last LOC reference is to their s2n, and it's entirely fair to say 6,000 LOC is qualitatively better than "at least 70,000", especially with all the focus, which they cite, on SSL/TLS protocol and implementation bugs.

danudey 11y ago

On the other hand, the attack area for OpenSSL is the TLS implementation itself, and not the ciphers. Linking against openssl/whatever for ciphers makes more sense than implementing them yourself, and now we can replace OpenSSL's huge, complete TLS implementation with a small, incomplete one that provides just what most people use in a small, auditable package.

gsnedders 11y ago

Still using it for ASN.1 is quite sad, given ASN.1 is where a fair few security bugs have been. If I'm not mistaken, this includes CVE-2015-0286, CVE-2015-0287, CVE-2012-2110, CVE-2009-0590, CVE-2009-0789, and CVE-2006-2937 from the last decade (and more if you go further back). The ciphers are pretty damned solid — the ASN.1 code… not so much. I'd argue that the ASN.1 parsing and the like is one of the areas that sorely needs replacing in OpenSSL, precisely because it has had so many vulnerabilities found in it over the years.

userbinator 11y ago
Incidentally, Fabrice Bellard has written a small ASN.1 compiler: http://bellard.org/ffasn1/ http://bellard.org/ffasn1/ However, he does not want to give it away. ASN.1 is a rather hairy standard overall, but AFAIK only a part of it is needed for TLS.