up vote 1 down vote favorite
2
share [g+] share [fb]

I currently have a group of web-services exposing interfaces to a variety of different client types and roles. Authentication is handled through a public/private key pairs (RSA) only to verify the URL as signature in the HTTP Header.

At this time the HTTP Body is not encrypted (I use a private/public key of 2048 bit which allows me to encrypt only small amounts of information), so RSA is not enough safe because the server can no longer prove to himself that there's not a Man-In-The-Middle. I can encrypt also the HTTP body, but what about performance?

My question is: what techniques are recommended to prevent a MITM attack in this case?

link|improve this question
83% accept rate
1  
You seem to believe there may be a performance problem. Have you considered simply testing to see if that will be the case? – Zoredache Feb 25 '11 at 17:05
@Zoredache I didn't tested that yet, but I think it is a problem with a lot of authentications. – user65567 Feb 25 '11 at 17:13
I'm not seeing where there's a (easy) MITM attack in here, unless neither side is authenticating the Cert against a CA. The key length also has nothing to do with encryption; they public/private keys are used to establish the session key, they don't actually encrypt the traffic (unless you coded your own custom system). – Chris S♦ Feb 25 '11 at 17:32
@Chris S "What techniques are recommended to prevent a MITM attack in this case?" refers to the possibility to change the HTTP body content (the important header values are signed). Public/private keys can be used to encrypt the HTTP body, but, since I need to encrypt a lot of data, 2048 bit are not enough to encrypt that (I get errors like 'OpenSSL::PKey::RSAError (data too large for key size)'). – user65567 Feb 25 '11 at 17:46
Why on earth wouldn't you just SSL encrypt the entire communication stream between the client and your server? – Chris Lively Feb 25 '11 at 18:35
show 1 more comment
feedback

migrated from stackoverflow.com Feb 26 '11 at 1:00

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 2 down vote accepted

There is absolutely no point in using HTTPS if you don't encrypt the entire authenticated session. If any point you transmit the session id over an insecure channel then an attacker can use this to authenticate (Like Firesheep). Further more you are violating OWASP a9.

From a performance perspective the most expensive part of SSL is the initial handshake. This is cached and there for only done once per client.

Another thing to keep in mind is that if you want to stop SSLStrip style attacks then you should set the STS-Header.

link|improve this answer
The fact is that I need to trasmit not only the session id, but also other datas that, using a public/private key pairs at 2048 bit, is not possible to encrypt. If I use 4096 bit, it is possible (for now), but what about the performance? P.S.: I updated the question! – user65567 Feb 25 '11 at 17:01
1  
@user502052 When i say the entire session i mean ALL DATA transmitted between you and the client from the moment you issue a set-cookie to the moment you destroy that session. – Rook Feb 25 '11 at 18:16
feedback
up vote 1 down vote

Go for tried and proven solution: use HTTPS with mutual authentication, as a bonus encrypt entire session. HTTPS performance isn't an issue unless your client running on TI calculator. Google using it for entire Gmail, this should be a good example.

link|improve this answer
What do you mean with "HTTPS with mutual authentication" and "TI calculator"? – user65567 Feb 25 '11 at 17:32
HTTPS performs mutual authentication when there are server certificate and client certificate used. This gives you protection from MITM attacks on both ends. TI calculator is just an example of very low computational power device :) – blaze Feb 25 '11 at 17:47
Ok. In my case I refer to the possibility to change the HTTP body content (the important header values are signed). Public/private keys can be used to encrypt the HTTP body, but, since I need to encrypt a lot of data, 2048 bit are not enough to encrypt the data (I get errors like 'OpenSSL::PKey::RSAError (data too large for key size)'). – user65567 Feb 25 '11 at 17:55
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.