Clash
Sometimes, I tend to butt heads with a co-worker. Overall, we round each other off nicely (or perhaps I am butting heads there too?) Recently, we got into a discussion about security. What we were trying to accomplish was passing information securely over an (otherwise) insecure protocol, HTTP. My immediate answer was to use a public key implementation. Here was a brief description of my implementation:
-
Server launches a client application. The server passes the client data that is encrypted using a symmetric key (AES 256).
-
The client then generates a random public / private key pair.
-
The client then requests the server for the symmetric key. It also hands it the public key.
-
The server uses the public key to encrypt the symmetric key.
-
The client then uses the private key to decrypt the symmetric key.
-
The symmetric key is then used to decrypt the original data.
Not too hard, right? Well here is where we disagreed. The response from my co-worker was "Why use an RSA key at all? Just hand the symmetric key to the client".
Right then I sorta blanked out by what I just heard. After recovering, I asked, "You don't see a problem with that? That would be extremely easy to intercept for someone with a packet sniffer to pick up.
My co-workers response, was "We should just warn our users that they should be using SSL. You're RSA implementation is what SSL does to a degree".
Which, is correct. SSL does use a public and private key implementation. However, there are a few gotchas with that...
-
SSL uses the same public and private key every time. If someone managed to get the private key, they could read all SSL requests and responses.
-
-
What if they aren't using SSL? Do we require it? That will make the product hard to use. What if they don't want to use SSL?
-
How do we communicate that SSL is a good idea? Knowledge base post? Make a warning dialog on the page that enables that feature? It sounds reasonable.
The problem with #4 is not everyone reads. Clients and customers don't read every single thing on the page.
Someone
will ignore some text on a page, no matter what you do to make it stand out.
SOMEONE WILL FORGET TO READ THIS.
If the client or customer were to find out that some data was being passed in a was that was known to be compromised, you can be sure they will not be happy, and depending, might stain the reputation of whatever it is you are working on.
It's easy enough to pass data securely. web services are a great means of that, if you are using WSE or for you .NET 3.0 junkies, WCF.
In the end, the RSA implementation was used, much to my relief.
So, what am I really trying to say?
You will never be taken seriously about security if you keep your mind on assuming that the customer's / client's environment is secure. Do
everything
you can to secure things. SSL is not a poor means of securing communication, but in our case,
there is no way to guarantee it
. If we do it ourselves, we are
sure
they are using a decent security implementation because we are forcing it.
So, why not have the application not work if it can't use SSL? That's a poor customer experience. The more transparent the functionality is, the better it is for the end-user's experience.