OpenBSD has had two holes in a heck of a long time. By contrast OpenSSL has had a remote execute in 2010, and another 4 in 2002, and is regularly patching DOS's resulting from memory corruption that turns out not to be exploitable.
It is 453,000 or so lines, more than five times the size of xv6. It is ten times as big as PolarSSL. Documentation and internal structuring is wildly inconsistent. Features that make static analysis annoying are widely used. The API is far too low level.
Do you believe this is acceptable in a security library? Do believe that aspiring to the security of qmail or OpenSSH is a reasonable goal, even at the cost of features? Why should I use OpenSSL for TLS termination when formally validated alternatives exist?
> Why should I use OpenSSL for TLS termination when formally validated alternatives exist?
Oh please do share! (spoiler: alternatives which enable side channels because the pretty compiled-optimized-code (that is generated from source code that itself may feature immutable data etc. with no side effects) is ripe with leaks via cpu branching, caching, etc etc do not count.) This is not a spiteful rhetorical inquiry, by the way!
Those side-channel attacks are largely theoretical. OpenSSL and RSA in general are vulnerable to side channel attacks, because many of the fundamental operations are not constant-time. That can change eventually, but RSA is difficult to write in a constant-time manner. OpenSSL certainly has had its fair of lab-demonstrated side-channel attacks, but I don't think anyone has been able to demonstrate their use in virtualized hosting environments against arbitrary other tenants.
Side channel attacks once you've already got code running on the same operating system as the target are much easier. But if you can get arbitrary code to execute on the same machine running OpenSSL, you probably already have their keys.
So, I think the criticism to OpenSSL is valid. Why use it when it seems there are less bad alternatives? A lot of it comes down to network effects, inertia, and licensing. That's a much better answer than side-channel attack surface area, which all RSA implementations share :)
> Those side-channel attacks are largely theoretical.
Before you write secure software, you have to consider who your adversaries are, and what they are capable of doing. Side-channel attacks over the network are definitely practical [1] [2] [3]. If you're making even a basic SaaS product, you should assume your adversaries can carry out the above. You should assume that by now, even lowly script kiddies have side-channel exploits in his arsenal.
Nope: you can exploit the timing attacks from across a network link in AES. DJB did this long, long ago. Furthermore, I believe OpenSSL has constant-time RSA, but you can always use ECDSA for which constant time implementations in C exist. (I wrote one, but I still need to switch the hash function to SHA256 and add the unnecessary encoding steps to the output, so consider it a PoC).
Are you sure? Searching for "side channel OpenSSL" reveals a majority of the attacks are against ECDSA. Of course, searches aren't the best measure of vulnerability, it's just an indication of popularity.
PolarSSL has been validated with FRAMA-C by a company. Unfortunately you have to pay to see the results, and they use blinding for bignum arithmetic, not constant-time. (But they do have a decent curve implementation). http://trust-in-soft.com/news/
To remove side channels and preserve validation, you need to be slightly clever. You validate that a C implementation of one of the functions does the same thing as a function in the validated package, then swap them in the build output. This can be done for miTLS. Your validation of the C part is much more limited in scope than the whole thing.
> To remove side channels and preserve validation, you need to be slightly clever. You validate that a C implementation of one of the functions does the same thing as a function in the validated package, then swap them in the build output. This can be done for miTLS.
I am not defending OpenSSL but I am not sure your comparisons are very informative and quite frankly some of your sloccounts seem to wander far away from fact.
> OpenBSD has had two holes in a heck of a long time
Two remote holes in the default install. The default install is configured in such a way as to minimize the attack
surface area. Do you know what services are configured to respond to public internet traffic in the default install?
OpenSSL on the other hand essentially is always interacting with public internet traffic. Do you use OpenBSD on your
desktop and laptop?
> 453,000 or so lines, more than five times the size of xv6
Are you referring to Xv6, "the simple Unix-like teaching operating system" a project designed for education and not
commercial service offerings? How does this comparison of the size of xv6/OpenSSL inform the debate? The Linux
kernel has 12 million lines of code. What should I conclude from this number compared to OpenSSL? Do you think some
of PolarSSL's failures with frankencerts can be explained by how small the code base is? Please see the addendum for
more sloccount discussion.
> Do believe that aspiring to the security...even at the cost of features?
I don't mean to be difficult but I have no idea what you are asking here. Which features are you referring to?
Without some specificity of "cost of features" this seems to be more about showmanship and rhetorical style than
fostering meaningful debate. Do you run OpenBSD on your desktop/laptop?
> Why should I use OpenSSL for TLS termination when formally validated alternatives exist?
What are these alternatives? I did not realize there were multiple formally validated alternatives to OpenSSL.
Maybe we have different opinions about "alternatives" versus "implementations."
SLOCCOUNT Addendum:
I did not want to inject a pile of sloccount data in the main body of my comment but I do have some questions about
your counts. After a little research it seems that your numbers might be somewhat hand wavy which is unfortunate
because you gave no indication of this in your comment.
What versions of OpenSSL and PolarSSL are you referring to? My count for OpenSSL 1.0.1g puts it at 6.5 times the
size of PolarSSL and not the 10 times that you stated in your comment. I could not connect to OpenSSL.org so I do
not know if they have released a version since April 7th but I must say I am surprised that that the OpenSSL dev
team added 91,344 lines (25% increase) in the last seven days. And even if they did that still puts them 90,000
lines short of "ten times the size of PolarSSL."
My sloccount data:
# OpenSSL 1.0.1g:
Totals grouped by language (dominant language first):
ansic: 273820 (75.71%)
perl: 69192 (19.13%)
asm: 11015 (3.05%)
cpp: 4367 (1.21%)
sh: 3238 (0.90%)
lisp: 24 (0.01%)
Total Physical Source Lines of Code (SLOC) = 361,656
# PolarSSL 1.3.6-gpl
Totals grouped by language (dominant language first):
ansic: 52212 (94.71%)
sh: 2165 (3.93%)
perl: 748 (1.36%)
tcl: 4 (0.01%)
Total Physical Source Lines of Code (SLOC) = 55,129
# Linux kernel 3.14
Totals grouped by language (dominant language first):
ansic: 11828087 (97.00%)
asm: 275047 (2.26%)
!!!TRIMMED counts < 0.5%!!!
Total Physical Source Lines of Code (SLOC) = 12,193,312
# Xv6
Totals grouped by language (dominant language first):
ansic: 7022 (87.81%)
sh: 481 (6.01%)
asm: 301 (3.76%)
perl: 189 (2.36%)
lisp: 4 (0.05%)
Total Physical Source Lines of Code (SLOC) = 7,997
You are correct: I meant 10x the size of xv6 and 5 times that of PolarSSL. I used wc, so comments and blanks count. xv6 implements a multiuser operating system. This is not an easy undertaking by any means, and far more complex than TLS in terms of conditions to satisfy.
As for the rest of your comment, I have used OpenBSD on the desktop. I have never found the lack of a webserver running, or anything but sshd to be a hindrance to making a machine on which with a browser I can read papers, bank, listen to music, and program. sshd is of course attackable by anyone: good luck getting in though. Other OS's have followed OpenBSD, as do most hardening guides.
One of the features OpenSSL has is support for ciphers that long ago have been disabled, together with out-of-date TLS versions such as SSLv2(!). TLS is a specification, with multiple implementations. The specification is of poor quality, the protocol worse, but OpenSSL is in a class by itself, including implementations of national ciphers no one uses.
While Frankencerts were an issue, there was no realistic way to turn the two incorrect "OKAY" and the one "NOT OKAY" result of PolarSSL into an attack. You would need a CA to issue a cert with a start time in the future. It also does not take an enormous amount of code to fix this issue.
It is 453,000 or so lines, more than five times the size of xv6. It is ten times as big as PolarSSL. Documentation and internal structuring is wildly inconsistent. Features that make static analysis annoying are widely used. The API is far too low level.
Do you believe this is acceptable in a security library? Do believe that aspiring to the security of qmail or OpenSSH is a reasonable goal, even at the cost of features? Why should I use OpenSSL for TLS termination when formally validated alternatives exist?