flat assembler
Message board for the users of flat assembler.

Index > Heap > Prevent MITM attacks?

Author
Thread Post new topic Reply to topic
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
Is there any way to do so? Everything I have read simply boils down to "exchange a key/password/whatever before there is a MITM" or "get a ket/password/whatever from somebody else (e.g. a trusted authority) and hope that there is no MITM between it and you". I can't find any ways that work when there is a MITM from the beginning. Is it fundamentally impossible? Or am I just looking in the wrong places?

_________________
Post 04 Jan 2010, 15:27
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Afaik, it's not possible (at least without quantum crypto, but test implementations of that have been broken anyway) to 100% avoid MITM attacks when talking to a complete stranger - you need an "external" piece of information, like a certificate authority.

I'd very much like to be proven wrong, though Smile
Post 04 Jan 2010, 15:45
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
When talking to a complete stranger you are no able to distinguish him from the MITM, thus the MITM is able to play role of him for you and role of you for him - therefore as long as he knows the protocols and algorithms you use (and when talking to complete stranger, you obviously have to use some standardized ways to communicate), it is impossible to prevent this kind of attack, no matter how insane cryptographic methods you'd choose.
Post 04 Jan 2010, 16:13
View user's profile Send private message Visit poster's website Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
Though as mentioned, using the IRL protocol often works best.
Post 04 Jan 2010, 21:45
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
Software level MITM attacks can be mitigated by redundancy. I'm referring to cache poisoning, if you're checking multiple trusted sources instead of just one then those multiple sources would all need to be compromised.

Hardware level MITM is like a wire-tap (someone with a splitter/vampire clip latched onto your phone/cable line) and there's no beating it without a separate key exchange.

--------------
But on the subject of exchanging keys beforehand, with the prevalence of cell-phones and "texting" you could set something up that would be fairly secure and minimal overhead for your users.

(For the below example I'll use "web browser" to denote any connectivity software like SSH, FTP clients etc)

1 Server: Advertise a Text Messaging phone number and a download link for your new fancy symmetric key enhancement add-on web browser plug-in
2 Client: Text a random password (Client's PW) to Server, also input this password into your fancy web browser plug-in.
3 Server: Automated receive Client's Text, create new row in a database table with row ID | Client's PW | Server's PW (uniquely generated) and possibly your cell# and timestamp to remember your Client PW and tell you to send a new one of an expiration period, reply to Client's Text with table's row ID.
4 Client: Input the ID from the Server's reply Text into your web browser, this will take you to the symmetrically encrypted log in page.

If the Server and Client make their replies and requests unique (use random padding) a MITM will not be able to derive either key without using brute-force.

If browsers implemented this symmetric only option with SSL all that would be left if for Server's to setup the automated system which would probably be out sourced to Certificate Authority type companies.

Eventually your computer will be able to perform Steps 2 and 4 automatically by controlling your cell phone by wireless.

I should probably get a Business Process patent for this.
Post 05 Jan 2010, 00:41
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
r22 wrote:
Software level MITM attacks can be mitigated by redundancy. I'm referring to cache poisoning, if you're checking multiple trusted sources instead of just one then those multiple sources would all need to be compromised.
IMHO only one source needs to be poisoned in order to cause a DOS effect - how else would you determine which information is correct? If one source is poisoned, how do you know that it's not the majority of sources that are poisoned, with a single good source left?

There might be some value to your SMS idea, but if somebody has the capability to MITM on your SSL... don't you think they can snoop your cellphone data as well? (I have no idea whatsoever how well that stuff is protected).

_________________
Image - carpe noctem
Post 05 Jan 2010, 00:48
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
DustWolf wrote:
Though as mentioned, using the IRL protocol often works best.
I don't get it.. if you've already interacted with them IRL and exchanged keys, isn't that is just another example of doing it before there is a MITM?
And if you haven't, couldn't the MITM trick both of you into meeting him IRL instead of eachother?

r22 wrote:
Software level MITM attacks can be mitigated by redundancy. I'm referring to cache poisoning, if you're checking multiple trusted sources instead of just one then those multiple sources would all need to be compromised.

Hardware level MITM is like a wire-tap (someone with a splitter/vampire clip latched onto your phone/cable line) and there's no beating it without a separate key exchange.

--------------
But on the subject of exchanging keys beforehand, with the prevalence of cell-phones and "texting" you could set something up that would be fairly secure and minimal overhead for your users.

(For the below example I'll use "web browser" to denote any connectivity software like SSH, FTP clients etc)

1 Server: Advertise a Text Messaging phone number and a download link for your new fancy symmetric key enhancement add-on web browser plug-in
2 Client: Text a random password (Client's PW) to Server, also input this password into your fancy web browser plug-in.
3 Server: Automated receive Client's Text, create new row in a database table with row ID | Client's PW | Server's PW (uniquely generated) and possibly your cell# and timestamp to remember your Client PW and tell you to send a new one of an expiration period, reply to Client's Text with table's row ID.
4 Client: Input the ID from the Server's reply Text into your web browser, this will take you to the symmetrically encrypted log in page.

If the Server and Client make their replies and requests unique (use random padding) a MITM will not be able to derive either key without using brute-force.

If browsers implemented this symmetric only option with SSL all that would be left if for Server's to setup the automated system which would probably be out sourced to Certificate Authority type companies.

Eventually your computer will be able to perform Steps 2 and 4 automatically by controlling your cell phone by wireless.

I should probably get a Business Process patent for this.
I don't get it. If there is a MITM between you and the advertisement (so that you get a link to the MITM's download page instead) or between you and the server (so that he intercepts your key and sends the server his own), how does this work?

_________________
Post 05 Jan 2010, 03:24
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
@fodder - at least knowing your being hacked is half the battle. Having just 1 trusted source poisoned would put up the red flags, but it would be a sort of DOS until damage control is completed. I made sure to use the word mitigate instead of eliminate or circumvent, because of its looser meaning.

Cell phones use GSM encryption, a proprietary encryption that until recently has enjoyed security by obscurity/black box.
Post 05 Jan 2010, 03:30
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
r22 wrote:
@fodder - at least knowing your being hacked is half the battle. Having just 1 trusted source poisoned would put up the red flags, but it would be a sort of DOS until damage control is completed. I made sure to use the word mitigate instead of eliminate or circumvent, because of its looser meaning.
Good to see the clarification - I agree Smile

r22 wrote:
Cell phones use GSM encryption, a proprietary encryption that until recently has enjoyed security by obscurity/black box.
Googling for "GSM wiretap" doesn't give me a lot of confidence in it's security Smile, but I'm too tired to read any of it. Probably requires a bit more sophistication than "just" MITM'ing internet connection, but still.

Azu also has a point about MITM'ing the SMS server? And it'd be messy to implement in practice Smile

_________________
Image - carpe noctem
Post 05 Jan 2010, 03:38
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
f0dder wrote:
Probably requires a bit more sophistication than "just" MITM'ing internet connection, but still.
It doesn't requiring any MITM. GSM is fundamentally flawed and can be cracked on a conventional computer without intercepting the encryption key. It is worse than RSA, which at least requires hardware not yet available to crack it.

_________________
Post 05 Jan 2010, 03:42
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica
Well, one doesn't need to know the algorithm to crack the system, GSM tried to keep it secret, but was broken within years. (iirc an linear equivalent was found, longer that the original but fully equivalent to what they used).
I agree with earlier posters, if there's a (wo)man in the middle (our dear Eve Wink) from the start you're out of luck. Even if we take the only theoretically safe encryption scheme, the one-time pad. If there's someone intercepting the OTP set before it's used it's broken, and that's the only way to break a OTP (note: OTP provides zero-knowledge, meaning you know just as little about the clear text before you see the chipertext as you do after, even if you manage to, by chance, choose the correct key you have no way of knowing you broke it).
eg. "ABC" can be "GOD" with the key A=G,B=O,C=D or "DIE" with the key A=D,B=I,C=E - there's no way to know which (if at all either) is the correct clear text for ABC without having the key used to generate it. However if the key is reused (=incorrect use of OTP) it may be possible to decide, most ciphers have pseudo-random generators (LFSR, wikipedia is a bit lengthy, but in short it's a state machine with p^n-1 states with the numbers 1 to p^(n-1) in some "pseudo-random" order with each value occurring once, note p is prime and 0 is not included!), which will inevitably repeat at least after p^n-1 steps (where p is a prime, usually 2 for computers and n is the length of the generator).


So to give a simple answer to your question "Is it fundamentally impossible?": Yes, if you had a secure channel to start with you wouldn't have this problem of getting a secure channel in the first place. Wink

So what can you do? Well, make the cost (in some metric you value, say time) of breaking the cipher so high it's so unlikely anyone has the resources to crack it and the risk of someone by chance breaking it is so small it's practically impossible to break before the usefulness of the data has expired (changing keys before it's 'breakable' is a good way). In short, you'll always be vulnerable, you must take a chance of a MITM during "first contact" (btw, there's been real world examples of MITM, some hostages were free'd from a guerrilla in south/mid-america thanks to a clever MITM by law enforcers).

RSA is secure since it allows for key-expansion (larger primes => longer computation time, for both enc- and decryption). DES for instance is not, since has a limited key length. (3-DES is a hack to also allow for compability with old hardware DES imlpementations, but in that use it's as insecure as DES, DES tried to be fast in HW slow in SW, another of the failed attempts at finding the chiper-holy-grail). The only way for a chiper to remain secure is to allow it to expand - ideally exponentially hardening chiperanalysis by lineraly expanding the key length.
Post 05 Jan 2010, 13:36
View user's profile Send private message Visit poster's website Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
@azu - The "advertisement for the ~ browser plug-in would become unnecessary if the protocol was implemented by the major players as a standard secure connection option. I think I mentioned it at the bottom of my long post; the advertisement of the security plug-in is a fundamentally flawed premise for MITM. But you could go so far as to say theirs a MITM when the browser vender is uploading a new version to their download server etc etc.

Writing something off as "impossible" to secure is a glib interpretation. Security is not black and white. Every encryption algorithm is vulnerable to brute force, but we don't say the algorithm is insecure/fail. Security is decreasing the probability of compromise to a reasonable level, not the "prevention" of said compromise.

I hope quantum computing advances quickly, something new in the mainstream of computation would be nice.
Post 05 Jan 2010, 14:22
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
Azu wrote:
I don't get it.. if you've already interacted with them IRL and exchanged keys, isn't that is just another example of doing it before there is a MITM?
And if you haven't, couldn't the MITM trick both of you into meeting him IRL instead of eachother?


Is the presence of any information beforehand to be regarded as a "before there is a MITM" scenario? For example one typically doesn't wear a digital signature plastered to one's face when going out to meet new friends, yet it is hard to hide one's face while doing so. For another example, when linking up to a webserver providing a supposedly trustworthy download, it need not be implied what it's key fingerprint is before going there for the first time, yet we do know it must be a webserver beforehand.

In other words, the point that people can usually tell when something is not what it should be in a IRL meeting is not completely irrelevant.

EDIT: Thinking about my own arguments again provides some interesting arguments for the "it's not the same unless it's not IRL" people. Identity forgery is just as possible IRL as online and follows many of the same rules.

LP,
Jure
Post 05 Jan 2010, 21:20
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
Hi,

Found this while looking into something at work today:
http://msdn.microsoft.com/en-us/library/dd767318.aspx
(Support is supplied with an update that is currently available.)

I thought it may be relevant. Smile

I also thought it funny how MS considers the situation where your Windows client program (browser or otherwise) automatically sends your logon credentials to an unidentified computer on your LAN whenever trying to access it, a MITM attack. Just where is the "middle" in such a scenario, exactly?

LP,
Jure
Post 05 Jan 2010, 21:29
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.