Can you trust your ISP ??

Hello, 
   I'm thinking about how can I get rid off this kind of attack *before* it 
happens. Can you please send me your comments about this? I don't know so 
much about the how SSL works, but I think this is something that can 
happen...

SCENARIO
--------

1) Suppose We have a host with https protocol enabled, and someone 
outside wish to access the information we have on the server via https; 
but (for some reason wich we don't know), the connection has to be made 
through the Gateway named X (see plain diagram below):
                                 
     Outside <-------------> Gateway X <---------------> Our Server

2) I think that when a Secure Socket Layer connection begin this is what it 
happens:

  a) Outside generates a private/public key pair and he send us
     his public key, wich has to go through Gateway X, who send 
     it to Our Server.

  b) Our Server generates his own private/public key pair and send
     his public key (whether it's sent ciphered or not doesn't 
     matter... yet).

  c) Now both parts have their response public keys, ciphered
     transaction begins. 

All seems to be fine, but...

3) Suppose that We don't trust on what's going on through the line, and 
that IN FACT, someone in Gateway X is disturbing our communications like 
this:

  a) When Outside's public key comes to the gateway, Gateway X generates
     a public/private key pair (wich we will call spoofed keys),
     and it send a spoofed IP header marked as from "Outside" in order
     to act as "Outside" for "Our Server".

  b) Once "Our server" send his public key, "Gateway X" intercept the
     packet, decrypts it if necessary (because it has the private key
     needed to decrypt it), and it send "Outside" the public spoofed
     key (remember what it did on stpe a?).

  c) Now transaction takes place through "Gateway X", wich can read
     modify, and fake any data because it has now the ability to act
     as the other side to both "Outside" and "Our Server"...

Avoid the problem:

   - The *only* think I can figure out to avoid the menace is to have a 
certified (Verisign and others) public key with a short expiration date.

  Of course this approach has a little problem: *how* can I verify that 
once expired "Our Server's" public key is really "Our Server's" key... a 
Certification Authority is something worth of spoofing... ;-) Maybe the 
best thing could be becoming my own certification authority... but how!?

  If for *some* reason the above cannot be done, the a simple way to avoid 
too much trouble is to limit transactions to just *atomic* transactions 
(checking account and getting some money are two different transactions). 
This can still be spoofed if "Gateway X" makes its own transaction with 
faked Outside's keys. Of course, We must limit the tansactions we accept in 
"Our Server". Notice that a password and challenges are useless in this 
kind of situations.

¿Any other way? maybe we can get somethig a bit safer if we found something 
fixed, inmutable and rely on it (acting like some kind of virtual 
communication channel between Outside and Our Server:

                             Untrusted
     Outside <-------------> Gateway X <---------------> Our Server
        ^                                                     ^
        |                                                     |
        \-------- Virtual secure communication channel -------/

       
If every message "Outside" send to "Our Server" must have a response, then 
we could make "Our Server" send responses with some good (well tought) 
cryptographic technique wich will refer somehow to "Outside's" message 
fingerprint.

I mean, every message from the Outside must have a message signature (i.e 
message must pass through MD5); and its response must have a valid 
"Response to: <query's MD5 signature>" and (of course) that response must 
be signed somehow. I still don't know how to do it well; but I will tell 
you how as soon as I will know.

Thank you for wasting your time reading this.
--
  Iñigo González - ADV Internet Technical Advisor <nexus@adv.es>
  "Never say anything online that you wouldn't want to see on the
  front page of The New York Times." - alt.2600.moderated Posting

I~nigo Gonzalez writes:
> 
> Hello, 
>    I'm thinking about how can I get rid off this kind of attack *before* it 
> happens. Can you please send me your comments about this? I don't know so 
> much about the how SSL works, but I think this is something that can 
> happen...

[classic Man-in-the-Middle attack]


What you described is the Man In The Middle attack, often
abbreviated on these lists as MITM.  The fact that there's
an abbreviation for it should indicate to you how often
it is discussed.  However it's also one of the first
problems (besides the basic encryption) that protocol
designers think of.

It's been taken care of in SSL3- the server's certificate
must be signed by a CA that the client trusts.  Unless
the digital signature can be spoofed, and it probably
can't be, the client can be certain that the server certificate it got
is really from the server that it claims to be from.

Assuming that RSA still can't be broken, the client can be sure
that the pre-master-key material that it sends to the server
(and which is the basis for the symmetric crypto session keys)
will not be compromised.


If you grab a copy of the SSL3 spec (from netscape's web site)
and read the appendicies there's more good stuff about possible
attacks and what's been done to counter them.




-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
Principal, LNE Consulting: SSL, crypto applications, Internet security.
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF