Summary
I've been listening to your feedback regarding VMM and a lot of it has centered around VMM and how it impacts the security of your existing infrastructure. Well, to sum it up:
VMM does not make your environment any more secure, nor does it make it any less. Of course, I won't make you take my word for it (as I am obviously biased about my desire for you to run VMM), so I'll leave brevity at home and take a trip with my good friend, Mr. D. Tail.
An Analogy
Application security over any type of network can be a tricky subject to understand, so, if you will, allow me to paint you a seemingly unrelated picture about two people in two rooms. Imagine for a moment that there are two people, we'll call them Lucy and CJ, in adjoining rooms. Lucy and CJ cannot see or hear each other -- in fact the only way they can communicate is via a small opening in the shared wall through which they can pass little slips of paper with messages written on them. Another way to put it is two people chatting with each other computers connected directly to one another.
Existing Relationships
One might think because they are in adjoining rooms (or on two computers directly connected), Lucy and CJ should know with absolute certainty the authenticity of a message they receive from one another. However, what if someone crept into the room, replaced CJ (sat down at CJ's computer while he was at lunch), and was sending messages in his place? How would Lucy know the messages she was receiving from CJ were not not authentic? Well, supposing Lucy and CJ already had a pre-existing relationship they could have set up some type of secret key which they used to encrypt all of their communication.
However, what if Lucy had never met CJ before? She would still need to be able to verify that messages from CJ were actually from CJ, and that no one had supplanted his identity and was sending communiques in his stead.
Server Authentication
Enter Mr. Ver E. Sign. Although Lucy and CJ have never met, they both have a mutual friend, Mr. Sign. So the very first time Lucy and CJ exchange a message, CJ gives Lucy a copy of one of his business cards with Mr. Sign's stamp of approval on it (which Mr. Sign only gives out to the most trusted individuals). Having proven that he is a friend of Mr. Sign, Lucy feels confident that the person sending messages as CJ is CJ. Lucy and CJ then establish an encryption key that they will use to secure all of the messages they send to each other. We'll call this process server authentication (because CJ is serving Lucy with responses to her messages).
If this sounds a little familiar it is because you go through this process every time you log in to your bank's website using SSL. When you go to https://mybank.com/ the bank's website sends you a copy of its business card with a mutual friend's stamp of approval (the bank's server certificate which has been signed by a Verisign certificate authority).
Mutual Authentication
You may have noticed that while Lucy is reasonably sure she knows CJ is who he says he is, CJ never requested proof of Lucy's identity. So what if someone was sending messages to CJ on Lucy's behalf. Or to put it another way, what if someone knew your online banking password and was having a little bit of fun with your account? Not a good thing. Luckily there is a safeguard for this known as mutual authentication. Suppose CJ is a very busy person (alone in his room) and cannot be bothered to reply to messages through his little hole-in-the-wall unless he is reasonably sure they messages are from someone who is also a friend of Mr. Ver E. Sign. Well, just as Lucy can examine the stamp of approval on CJ's business card, CJ can do the same to Lucy's. CJ in fact will not even respond to Lucy with his business card unless Lucy's business card indicates that she is a friend of Mr. Sign as well. This process is known as mutual authentication. Some websites use this method to prevent unknown individuals from even reaching the front gates to attempt an unauthorized entry.
Man In The Middle
So it would seem that Lucy and CJ can communicate in a fairly secure fashion now, right? Well. Kind of. You see, the problem with all of the security measures that have been discussed thus far is that they are all susceptible to what is affectionately known as a man in the middle attack (MITM) (http://www.rsa.com/rsalabs/node.asp?id=2248). This type of attack was alluded to earlier when I suggested someone could might sneak into CJ's room and replace him and send responses to Lucy's messages while pretending to be CJ. You might ask, doesn't server authentication prevent this type of attack? No, unfortunately it doesn't. It does make it harder, but a person could still knock CJ out and present a business card that looks a lot like CJ's, and is even stamped by Mr. Ver E. Sign. Or perhaps CJ threw out one of his old business cards that he didn't use anymore. The impersonator could have found it, hit CJ with a blunt object, and started responding to Lucy as CJ. CJ's old business card might even have a note on it that it is no longer valid and should be consider void (or expired), but Lucy might not be checking that (although she should).
More Rooms
A MITM attack where both people are in adjoining rooms (on computers that are directly connected) is unlikely since there is a direct line (non-interceptable) of communication between them. In this scenario a MITM attack would require replacing one of the conversation's participants.
Imagine however that Lucy and CJ are not in adjoining rooms, but are in rooms separated by a great number of other rooms and their messages are couriered between each other. Given that someone else is ferrying the message, and that courier must travel a great distance until they reach the intended target with the message, how many opportunities does someone have to intercept the message and perform a MITM? The answer -- a lot.
Congratulations, you've just envisioned the Internet and the problem of ensuring secure communication over a large network.
The Internet
When Lucy (you) try to communicate securely with CJ (any other computer on the end-point), your message travels through countless rooms (computers/routers/switches/hubs,etc.) until it gets to its destined recipient. At any point someone could initiate a MITM attack and spoof either side of the communication. We've discussed measures that can be put into place to heighten security:
- Server Authentication
- Mutual Authentication
And it is getting easier and easier to intercept communiques. On wired networks you had to physically attach to a network segment that the message would travel across. With WiFi and cellular networks broadcasting your messages over the air, anyone with a radio can sift through the noise to find your message.
Second-Factor Authentication
However, there is no protection against a MITM attack without some form of second factor authentication. Imagine that Lucy and CJ were not strangers before they entered their rooms. In fact, Lucy and CJ agreed upon a secret phrase that they would use to encrypt all of their transmissions. Now they can communicate securely without worry. This is why some companies issue little FOBs or smart cards. These devices are second factor authentication implementations which are used to protect against MITM attacks. CJ will never respond to Lucy unless her messages are encrypted with a pre-arranged piece of information.
So why don't all web applications implement second factor authentication? Including VMM? Because it is costly to do so and sometimes isn't even possible depending on the client device being used to communicate with the server.
The very basis of true second factor authentication requires both parties to exchange a piece of information over a channel that is absolutely, 100%, trusted to be secure. Otherwise this super-secret second factor authentication key could also be considered subject to a MITM attack. In the real world this means that a user must receive a smart card via a secure postal service or some type of PIN number via an encrypted telephone transmission. Generally speaking, the only fool-proof method of obtaining a piece second-factor authentication information is to do so physically and in person. And if you are truly paranoid even this may not be good enough as the person you are receiving the information from could be a master of disguise impersonating the person you think you are talking to (I'm not kidding -- experts in the security field really do worry about stuff like this).
But let's suppose that the level of threat isn't that high and you can accept the risk of obtaining a PIN number over the phone, or better yet, imagine you've deployed VMM in your environment and you give a user their PIN number to use as their piece of second factor authentication. That user brings up VMM on their iPhone and it asks for their user name, password, and PIN number. The PIN number is used to encrypt the password which can only be decrypted by the server on the other end because that server already knows the PIN number associated with the given user name.
Oops. We missed a step.
Because VMM is a web application all of its code that it is executing was retrieved from ... a server! That's right, including the encryption libraries that would be used to encrypt the user's password with the given PIN number. The very code that would make use of the second factor authentication is itself subject to a MITM attack before it is ever delivered to your mobile device's web browser!
This is why VMM does not implement second factor authentication. Mobile devices generally do not have the capacity to accept a smart card or FOB that could contain the second factor authentication and the necessary encryption routines, nor do mobile browsers implement JavaScript in such a way that such information could be accessed.
My proposed solution is for all browser manufacturers to implement standard security routines that can be used to encrypt data on the client before it is ever sent to the server using a pre-arranged PIN number of even certificate of some sort.
VMM Isn't Secure?
You may take from this that VMM isn't secure. However, I want you to pay close attention to the first sentence of the last paragraph, specifically where I say "...all browser manufacturers...". I did not say mobile, because the fact of the matter that all internet browsers, even the one you are reading this blog post on are susceptible to the scenarios I have mentioned. In fact, unless you have a smart card from your bank or some special type of banking software on your computer that you received from your bank, when you check your account balance online, using SSL, you are subjecting yourself to a possible MITM attack, even with all of the bank's supposed online security.
VMM Is As Secure As Your Bank
That's right, using VMM is as secure as when you log onto your bank's website. The problem -- if you are really, really security conscious, it may not be secure enough. However, unless you are one of the people in the world that believe anything less than 100% foolproof security, VMM is secure enough. In fact, VMM is as secure as your bank.
Configuring VMM Security
Out of the box VMM does not enable SSL or mutual authentication, but these security measures are easily configured. For information on how to configure VMM, SSL, and even mutual (revokable client) authentication please see the Apache documentation at http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html. Of course, if you need additional help you can always e-mail me at akutz at hyper9 dot com.
Update - 2009/05/22 - 12:37 PM GMT-6
A respected professional colleague of mine pointed out that VMM is as secure as US banks as many EU banks already require customers to use FOBs or smart cards to access online banking. I will point out that most mobile devices do not support this, so mobile, browser-based banking is still susceptible to MITM attacks