From: "I~nigo Gonzalez" <nexus@adv.es>
Date: Tue, 10 Sep 1996 11:28:32 +0800
To: best-of-security@suburbia.net
Subject: Can you trust your ISP ??
Message-ID: <3234A158.3492@adv.es>
MIME-Version: 1.0
Content-Type: text/plain


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