Can encryption beat a man in the middle attack?

[UlyssesOfEpirus]

If I could get physical access to a server and store a few GB of truly random text onto the server (or somehow connect and transfer the text to it at a time when there is NO man-in-the-middle scheme going on), I could then program a special proxy in the server so that the link between me and the proxy is encrypted by simply XORing the data with the random text according to the one-time pad method. Then it is impossible to break the encryption, but it is also impossible for a man in the middle to harm me by directing me to another server of theirs, because that other server would not have a copy of the secret random text so there could be no communication.

1. Can the same be achieved by conventional encryption schemes like SSL or PGP where I do NOT have physical access to a proxy?

2. Can an authentication with these conventional schemes occur somewhere where there is NO man-in-the-middle attack going on, at a cafe or something, and then continue my encrypted access at a place where I know there most likely is a man-in-the-middle attack going on?

[kirklarsen]

If I could get physical access to a server and store a few GB of truly random text onto the server (or somehow connect and transfer the text to it at a time when there is NO man-in-the-middle scheme going on), I could then program a special proxy in the server so that the link between me and the proxy is encrypted by simply XORing the data with the random text according to the one-time pad method. Then it is impossible to break the encryption,

Sure, assuming that you don't reuse any part of the pad, and that the perfect random pad remains a secret forever.

but it is also impossible for a man in the middle to harm me by directing me to another server of theirs, because that other server would not have a copy of the secret random text so there could be no communication.

Well not that there is no communication, there is communication. And man in the middle can do harm, there is no reason that the man-in-the-middle has to forward your packets to their intended destination. And there is no reason why an attacker wouldn't mess with your data. I wonder what wonderful commands would be run by passing random bits into the stream? Change a single bit here, a single bit there...

So I hope you can see that this is an imperfect solution.

The problem with man-in-the-middle attacks is that your not connecting to who you think you are connecting to. The man-in-the-middle problem isn't just about encryption, it's authentication that is really important in preventing man-in-the-middle attacks, but integrity of the communication is also important. That is why SSL does all of these.

1. Can the same be achieved by conventional encryption schemes like SSL or PGP where I do NOT have physical access to a proxy?

If your talking about a way of creating a root of trust or a way to authenticate. Yes SSL and PGP have methods to securely 'boot up' trust.

2. Can an authentication with these conventional schemes occur somewhere where there is NO man-in-the-middle attack going on, at a cafe or something, and then continue my encrypted access at a place where I know there most likely is a man-in-the-middle attack going on?

I think there are several concepts that need to be broken out. One concept is confidentiality.

Assuming that you have previously connected/authenticated and packets are flowing. Then you move to a hostile network. The packets could theoretically be viewed in the hostile network and if the SSL session that was established between the server and the client is still valid, and you can actually get to your real destination, you could still pass that data securely in a hostile network. But this is not man-in-the-middle.

Man-in-the-middle is not just about confidentiality, it's really about authentication, but it can also be integrity of the data as the example with one time pads illustrates.

Now consider a scenario where there isn't a existing SSL session. And there is a man-in-the-middle attack going on. There is no way to create a secure SSL session through a man-in-the-middle connection. The SSL handshake will fail when you the client try to validate the server SSL certificate (hopefully).

If you are told by an application using SSL or PGP that you shouldn't connect. You REALLY shouldn't connect. (You know that SSL security warning dialog box that everyone just presses ignore to get around.) PGP has a similar warning if something about it's trust is wrong.

If you press "Ignore" then usually the next bit of communication is username / password. Then the man-in-the-middle has what they want.

One other interesting thing is not just the negative warnings when something is wrong, but positive warnings are just as important. Consider SSLStrip, it does a man-in-the-middle attack but it keeps the client connection in plain text (trying to fool the user) and encrypts communication to the server. See http://tinyurl.com/ycx7uzs for a Defcon talk about More Tricks for Defeating SSL by Moxie Marlinspike

This is just one important reason why you should replace your default VMware SSL certificates. They are not signed by a valid certification authority and can't authenticate without being pre-trusted in every client. Otherwise they will also pop up a SSL warning. It's never a good idea to get people into the practice of pressing "Ignore" to SSL warnings.

Best regards,

--Ksl

[Texiwill]

Hello,

1. Can the same be achieved by conventional encryption schemes like SSL or PGP where I do NOT have physical access to a proxy?

SSL has so many holes... that are fixed by proper SSL hygiene (PKI) and proper programming of SSL, Microsoft .NET for example provides enough code to do what a web browser does, but you have to explicitly tell it to perform mutual authentication. That is the server verifying the client and the client verifying the server. When the Ignore message appears review the certificate and compare the fingerprint at the very least to what is expected. I recently did this via a phone conversation. Once I confirmed the certificate as legitimate I then accepted it, etc. Certificate acceptance has to be done out of band using some mechanism such as the phone call I made or by pre-sharing critical information such as the fingerprint using some other non-network or proper PKI mechanism. Until this happens consider SSL insecure... There are even attacks that make use of properly signed and secured certificates so do not think that saves you either.

As for PGP, just make sure the bitstrength is proper then you have to use an out-of-band mechanism to transfer the public key to your intended recipients. This key exchange is the major problem. If you transfer a Public key over the network then anyone can read your data just by using the public key.... They cannot retransmit this data encrypted but by then the damage is done. So once more it boils down to proper key exchange or PKI.

2. Can an authentication with these conventional schemes occur somewhere where there is NO man-in-the-middle attack going on, at a cafe or something, and then continue my encrypted access at a place where I know there most likely is a man-in-the-middle attack going on?

Only with proper key exchange can you be safe within an internet cafe..... For example, I have a VPN which I use. Prior to leaving my office I pick up a new 'Key' from my VPN server. Now I have 'pre-shared' my keys. Tie this 'what I have' with passwords 'what I know' and fingerprint scanners built into my laptop 'what I am' and I now have 3 factor authentication.

It all boils down to Key Exchange basically using out-of-band mechanisms. The book 'The 19 Deadly Sins of Software Security Programming' is a good way to find out about how to fix this.... The new revision I believe is the 24 deadly sins....

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[howardcat]

Ed:

I may actually earn some points today....

Regarding the PGP points below, I think you may have it a tad tilted....

"...If you transfer a Public key over the network then anyone can read

your data just by using the public key...."

In PKI, the Private Key is used for all decryption, and the Public

Key, as I am quite sure you are realizing again at this moment, is

used only for encryption. Only the holder of the Private Key can read

the message.

You are quite correct in asserting that the key management is the fly

in the PKI ointment. Do not worry, I am fixing that next...

Best regards,

Howard

[Texiwill]

Hello,

Actually either can be used to 'encrypt' and 'decrypt' data. But yes, you are correct the proper way to decrypt is with the private key. However if you 'encrypt' with your 'private key' for some reason... It can be decrypted with the public key.

For this to work properly for email for example, if you send encrypted email to userA, then you must have userA's public key. userA decrypts with the private key. userA would have to have your public key so they can encrypt a message back. In this case there are 4 keys in use.

However, userA could ALSO encrypt using your public key which is then decrypted with your private key. In this case there are only 2 keys in use. This is NOT the best method of using PGP.

However, the key here is how do you get the public key(s) to someone.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]

[UlyssesOfEpirus]

kirklarsen:

"And man in the middle can do harm, there is no reason that the man-in-the-middle has to forward your packets to their intended destination."

And where is he going to forward them if he doesn't know what shop I was browsing through my proxy server? And even if he knew, what would his fake shop reply to my stream of random-looking data that he has no key for? No, he has no chance. Only if he breaks into my proxy server. Or my pc.

"Change a single bit here, a single bit there..."

Then my non-standard CRC check will fail and he won't be able to imitate it because it will include special bytes from the random key. He might as well offer no connection at all, it would be the same for me.

Can someone confirm that I can continue an SSL secure session with my browser that started while at a secure place, to somewhere else less secure and it will not log me out because of the new ip?

[howardcat]

Ed:

In the example you cite, where both keys can be used to encrypt or

decrypt, I do not believe that would meet the definition of Public Key

cryptography.

Quoting from the horse's (Whitfield Diffie and Martin Hellman) mouth:

http://www.rsa.com/rsalabs/node.asp?id=2165

2.1.1 What is public-key cryptography?

"...each person gets a pair of keys, one called the public key and the

other called the private key. The public key is published, while the

private key is kept secret. The need for the sender and receiver to

share secret information is eliminated; all communications involve

only public keys, and no private key is ever transmitted or shared. In

this system, it is no longer necessary to trust the security of some

means of communications. The only requirement is that public keys be

associated with their users in a trusted (authenticated) manner (for

instance, in a trusted directory). Anyone can send a confidential

message by just using public information, but the message can only be

decrypted with a private key, which is in the sole possession of the

intended recipient."

You are quite correct, however, when it comes to the challenges of

PKI, and the difficulty of public key management.

In that regard, I will offer a shameless plug for my new startup,

Secret 1-2-3.

For anyone who may be interested in testing a new product which will

solve this age-old key distribution problem, may I invite you to sign

up for our beta?

http://www.secret123.com/

Please put a note that you know me from the VMWare communities, and I

will be happy to put you on my "short list" of people who care about

email privacy...

Best,

Howard

P.S. FULL DISCLOSURE: Having now completed my duties at Catbird.com, I

am in the process of launching my next startup, Secret 1-2-3. I am a

principal and founder of Secret 1-2-3, and will be re-joining these

communities in the near future as "Howard123".

[Texiwill]

Hello,

In the example you cite, where both keys can be used to encrypt or

decrypt, I do not believe that would meet the definition of Public Key

cryptography.

I agree. However, it does not mean people do not do this already.

Knowing how things work is half the battle.... It is all about the key exchange.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009

Virtualization Practice Analyst[/url]
Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|
[url=http://www.astroarch.com/wiki/index.php/Virtualization_Security_Round_Table_Podcast]Virtualization Security Round Table Podcast[/url]