Securing an HTTPS server(daemonology.net)
daemonology.net
Securing an HTTPS server
http://www.daemonology.net/blog/2009-09-28-securing-https.html
17 comments
Encapsulating parts in their jails is a good security measure. But this is not anything related to securing the SSL. It's about securing your system. But giving a "my cgi's are secure but I can't believe in Apache's security" thought to your customers is not a correct way I think.
I can't find any statistics right now but AFAIK security breach sources are mostly not the servers but user applications running over them.
But this is not anything related to securing the SSL. It's about securing your system.
Nonsense. This configuration both keeps other parts of my system safe from bugs in OpenSSL and keeps the SSL certificate safe from bugs in Apache.
I can't find any statistics right now but AFAIK security breach sources are mostly not the servers but user applications running over them.
Quite true, in general. But in my particular case I have far more confidence in my (very simple) CGI scripts than I have in Apache.
Nonsense. This configuration both keeps other parts of my system safe from bugs in OpenSSL and keeps the SSL certificate safe from bugs in Apache.
I can't find any statistics right now but AFAIK security breach sources are mostly not the servers but user applications running over them.
Quite true, in general. But in my particular case I have far more confidence in my (very simple) CGI scripts than I have in Apache.
OpenSSL is the part of the stack least likely to have an exploit.
Additionally, most interesting attacks on OpenSSL aren't done to root the system, but to subvert the level of authentication/privacy afforded by TLS.
Additionally, most interesting attacks on OpenSSL aren't done to root the system, but to subvert the level of authentication/privacy afforded by TLS.
OpenSSL is the part of the stack least likely to have an exploit.
I've had to write or be involved in writing 7 FreeBSD security advisories related to OpenSSL in the past six years. History indicates that OpenSSL is the most likely part of the stack to have a vulnerability.
I've had to write or be involved in writing 7 FreeBSD security advisories related to OpenSSL in the past six years. History indicates that OpenSSL is the most likely part of the stack to have a vulnerability.
And, being intimately familiar with what those advisories implied, I know how many of those had any impact on your system, and how many of them were well-addressed by FreeBSD jails. You're overstating your case, Colin.
My case wasn't that this would have protected me from past vulnerabilities in OpenSSL; my case was that OpenSSL is demonstrably crappy code. If code has a history of security vulnerabilities, odds are that it will have more in the future.
You make a fine case for not running OpenSSL at all, and a poor case for jailing OpenSSL. That would be nitpicking, except that you implicitly offer your strategy as advice for others.
It's funny that you're arguing this though, since, given your marketing message, I can understand making ineffective cost/security tradeoffs. I'm at some pains to say you're not crazy for doing it.
It's funny that you're arguing this though, since, given your marketing message, I can understand making ineffective cost/security tradeoffs. I'm at some pains to say you're not crazy for doing it.
You make a fine case for not running OpenSSL at all, and a poor case for jailing OpenSSL.
Believe me, if there was a good alternative to OpenSSL, I'd be recommending it. Running OpenSSL in a jail is a horrible solution; but at least it's better than anything else.
Believe me, if there was a good alternative to OpenSSL, I'd be recommending it. Running OpenSSL in a jail is a horrible solution; but at least it's better than anything else.
That's ~1.16 advisories per year. Show me an operating system, web server, and web application platform (Java, RoR, PHP, whatever) that average less than ~1.16 per year each.
Further, out of all of the advisories for OpenSSL, how many would be mitigated using the technique from the article? Few or none, because most security issues in OpenSSL are about the way it implements the protocols (problems in the PRNG, problems parsing X.509, etc.).
Further, out of all of the advisories for OpenSSL, how many would be mitigated using the technique from the article? Few or none, because most security issues in OpenSSL are about the way it implements the protocols (problems in the PRNG, problems parsing X.509, etc.).
OpenSSL is somewhat notorious for being a high-maintenance codebase. I personally think jailing it is overkill, but this argument (about whether the code is perfectly safe for a pre-auth attack surface) is a rathole.
7 advisory for 6 years? is it 1 advisory for year?
I'm not talking about securing the certificate. I'm talking about SSL protocol implementation. But what you are telling about securing both parts are true.
I think this is overkill, and add that a vulnerability that this FreeBSD jail setup would stop would be page 1 "the Internet is broken" news; hundreds of millions of dollars of transactions every day rely on there not being system integrity flaws in OpenSSL.
That doesn't make Colin crazy; it just makes this not general-purpose advice.
That doesn't make Colin crazy; it just makes this not general-purpose advice.
a vulnerability that this FreeBSD jail setup would stop would be page 1 "the Internet is broken" news
Not true. There have been potential code execution bugs in OpenSSL which have received very little attention in the past. One which comes to mind is a 'free an arbitrary pointer' bug -- in an application like Apache, if you can free the right pointer, it's not hard to get code execution. (I didn't produce an exploit for this OpenSSL bug, so it's possible that it was unexploitable for some reason -- I just saw 'bogus pointer being freed' and said 'wow, this really needs to be fixed'.)
That doesn't make Colin crazy
Thanks, I think.
it just makes this not general-purpose advice.
This is an easy step to take, and prevents a class of attacks. Why not err on the side of caution?
Not true. There have been potential code execution bugs in OpenSSL which have received very little attention in the past. One which comes to mind is a 'free an arbitrary pointer' bug -- in an application like Apache, if you can free the right pointer, it's not hard to get code execution. (I didn't produce an exploit for this OpenSSL bug, so it's possible that it was unexploitable for some reason -- I just saw 'bogus pointer being freed' and said 'wow, this really needs to be fixed'.)
That doesn't make Colin crazy
Thanks, I think.
it just makes this not general-purpose advice.
This is an easy step to take, and prevents a class of attacks. Why not err on the side of caution?
Nice setup. I've got a similar one on a server:
Each daemon runs on it's own jail. Each jail is created from a cloned ZFS "base" jail filesystem, so it doesn't take any additional space (except each jail's installed packages), plus there are all the nice ZFS goodies (snapshots etc). There is one package-building jail. Every http request is served from a jail running varnish, which serves as a caching front-end to all the other http daemons in each jail.