Man-in-the-middle, or MITM, is a specific attack whereby an attacker injects themselves into the communication stream between a recipient of a message and the sender of that message. The most common example on the Internet is between a web browser and a web server. I am not disputing the necessity of verification in that example despite being nearly impossible to detect (e.g. generation/issuance of rogue but legitimate-looking certs to law enforcement). Last-hop MITM defense is an essential component of SSL security even though it is nearly impossible to detect rogue certs. However, server-to-server MITM defense is far more dubious.
Let's suppose I am an attacker for a moment and I find a way to inject myself between two servers in your web application (e.g. web server and database server). What is my behavior? Dumb attackers will simply take the low-brow approach and try to access the communication stream in a continual fashion, which seems to be the use-case that's bandied about for SSL with verification in the server world. However, ask any business owner which is more important to them: Application security or application uptime? Given the choice, the business owner chooses uptime over security every single time. Therefore, as an attacker, I simply let traffic through and only intercept one out of every 1,000-ish requests or for a random 5-10 minutes outside of regular business hours and 20 minutes on weekends. I also use a bogus certificate because my goal isn't to intercept the traffic but rather randomly take down the application over and over and over again for short periods of time. IT and web developers believe that turning on SSL with verification offers better security, so this strategy actually works against them in a MITM scenario because that security reduces application uptime. The first approach (1 out of 1,000 requests) is likely to NEVER be discovered but really irritate and annoy everyone especially both IT and the web development team while the latter is going to be more obvious but infuriating because it wakes multiple people up in IT and on the web development team anywhere from 10 p.m. to 4 a.m. weekly during the night shift and is always followed up shortly with the horrifying words, "never mind, it started working again." Assuming anyone ever finds and fixes the MITM attack, the result is only a bittersweet victory because you can't punch the attacker in the face. I, the attacker, have won by driving you insane and depriving you of much-needed sleep. After all, IT is the modern insane asylum.
SSL verification does NOT defend against the intelligent MITM attack in a server-to-server environment. There is also no real reason to turn it on in the first place. See, most servers sit in a data center. Data centers are generally only one or two hops away from a BGP router (the core Internet routers). The distance between servers is typically 4 to 6 hops (at most) and the amount of traffic that has to be processed at that level is pretty mind-blowing. To conduct a MITM attack, an attacker would have to attack a single application, which is a pointless example, or break the whole data center, at which point your paltry web app is not the only thing that's been violated. Or break a BGP router, which the NSA apparently did when Egypt's Internet access went out a couple of years ago. Supposedly that was a bad firmware modification made by the NSA that hosed the BGP router and took out an entire country's Internet access. Oops. My heroes. (#sarcasm) So the only logical conclusion is that nothing anyone does will ever stop a MITM attack at the server-to-server level and an attacker will more likely break the entire data center the server sits in than an individual application. Because the larger target is far more tempting - as evidenced even by the NSA.
To add one final nail to this coffin, SSL with verification in server-to-server communications also causes problems in setting it up and keeping it up. First you have to construct a PEM certificate chain. Then you have to get the software to actually use the certificate chain, which can be a challenge in its own right. Then you have to reconstruct the PEM certificate chain because you found the wrong certs or they are in the wrong order or you forgot one because no one documents anything. And, when they do document things, the documentation isn't kept up to date. Then the application finally starts working after wasting four hours of your life. Then around 2038, the application suddenly stops working because one of the certs expired and you have to remember how to do it all over again. Is your web app still going to be around that long? You hope not today but...surprise, surprise! Some applications stick around that long. Remember Y2K? Yeah, well, tossing in an expiration date into an application is totally going to come back to haunt you when you are 60+ and have early-onset dementia or Alzheimer's. But you defended against MITM attacks. Or did you? You can't remember and don't actually know...so why actually care until someone makes this extremely simple and easy to do in a way that makes sense?
In a MITM attack scenario: You and your personal sanity, not your web application, are already hosed. So you can turn off SSL with verification now in your web applications and SDKs - it has less maintenance overhead and may even help long-term application uptime and therefore your personal sanity remains intact. In the case of an SDK, you can at least make it an option to turn off verification instead of turning off SSL altogether. Finally, everything surrounding SSL certs needs to be made easier. Way easier.
Let's suppose I am an attacker for a moment and I find a way to inject myself between two servers in your web application (e.g. web server and database server). What is my behavior? Dumb attackers will simply take the low-brow approach and try to access the communication stream in a continual fashion, which seems to be the use-case that's bandied about for SSL with verification in the server world. However, ask any business owner which is more important to them: Application security or application uptime? Given the choice, the business owner chooses uptime over security every single time. Therefore, as an attacker, I simply let traffic through and only intercept one out of every 1,000-ish requests or for a random 5-10 minutes outside of regular business hours and 20 minutes on weekends. I also use a bogus certificate because my goal isn't to intercept the traffic but rather randomly take down the application over and over and over again for short periods of time. IT and web developers believe that turning on SSL with verification offers better security, so this strategy actually works against them in a MITM scenario because that security reduces application uptime. The first approach (1 out of 1,000 requests) is likely to NEVER be discovered but really irritate and annoy everyone especially both IT and the web development team while the latter is going to be more obvious but infuriating because it wakes multiple people up in IT and on the web development team anywhere from 10 p.m. to 4 a.m. weekly during the night shift and is always followed up shortly with the horrifying words, "never mind, it started working again." Assuming anyone ever finds and fixes the MITM attack, the result is only a bittersweet victory because you can't punch the attacker in the face. I, the attacker, have won by driving you insane and depriving you of much-needed sleep. After all, IT is the modern insane asylum.
SSL verification does NOT defend against the intelligent MITM attack in a server-to-server environment. There is also no real reason to turn it on in the first place. See, most servers sit in a data center. Data centers are generally only one or two hops away from a BGP router (the core Internet routers). The distance between servers is typically 4 to 6 hops (at most) and the amount of traffic that has to be processed at that level is pretty mind-blowing. To conduct a MITM attack, an attacker would have to attack a single application, which is a pointless example, or break the whole data center, at which point your paltry web app is not the only thing that's been violated. Or break a BGP router, which the NSA apparently did when Egypt's Internet access went out a couple of years ago. Supposedly that was a bad firmware modification made by the NSA that hosed the BGP router and took out an entire country's Internet access. Oops. My heroes. (#sarcasm) So the only logical conclusion is that nothing anyone does will ever stop a MITM attack at the server-to-server level and an attacker will more likely break the entire data center the server sits in than an individual application. Because the larger target is far more tempting - as evidenced even by the NSA.
To add one final nail to this coffin, SSL with verification in server-to-server communications also causes problems in setting it up and keeping it up. First you have to construct a PEM certificate chain. Then you have to get the software to actually use the certificate chain, which can be a challenge in its own right. Then you have to reconstruct the PEM certificate chain because you found the wrong certs or they are in the wrong order or you forgot one because no one documents anything. And, when they do document things, the documentation isn't kept up to date. Then the application finally starts working after wasting four hours of your life. Then around 2038, the application suddenly stops working because one of the certs expired and you have to remember how to do it all over again. Is your web app still going to be around that long? You hope not today but...surprise, surprise! Some applications stick around that long. Remember Y2K? Yeah, well, tossing in an expiration date into an application is totally going to come back to haunt you when you are 60+ and have early-onset dementia or Alzheimer's. But you defended against MITM attacks. Or did you? You can't remember and don't actually know...so why actually care until someone makes this extremely simple and easy to do in a way that makes sense?
In a MITM attack scenario: You and your personal sanity, not your web application, are already hosed. So you can turn off SSL with verification now in your web applications and SDKs - it has less maintenance overhead and may even help long-term application uptime and therefore your personal sanity remains intact. In the case of an SDK, you can at least make it an option to turn off verification instead of turning off SSL altogether. Finally, everything surrounding SSL certs needs to be made easier. Way easier.
Oh, and by "made easier", I didn't mean "Let's Encrypt". See my blog post on that topic.
ReplyDelete