[65060] in Cypherpunks
Can you trust your ISP ??
daemon@ATHENA.MIT.EDU (Iqigo Gonzalez)
Mon Sep 9 19:47:21 1996
From: Iqigo Gonzalez <nexus@adv.es>
Date: Tue, 10 Sep 1996 00:59:36 +0200
To: best-of-security@suburbia.net
Cc: cypherpunks@toad.com
Hello,=20
I'm thinking about how can I get rid off this kind of attack *before* =
it=20
happens. Can you please send me your comments about this? I don't know so=
=20
much about the how SSL works, but I think this is something that can=20
happen...
SCENARIO
--------
1) Suppose We have a host with https protocol enabled, and someone=20
outside wish to access the information we have on the server via https;=20
but (for some reason wich we don't know), the connection has to be made=20
through the Gateway named X (see plain diagram below):
=20
Outside <-------------> Gateway X <---------------> Our Server
2) I think that when a Secure Socket Layer connection begin this is what =
it=20
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=20
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=20
matter... yet).
c) Now both parts have their response public keys, ciphered
transaction begins.=20
All seems to be fine, but...
3) Suppose that We don't trust on what's going on through the line, and=20
that IN FACT, someone in Gateway X is disturbing our communications like=20
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=20
certified (Verisign and others) public key with a short expiration date.
Of course this approach has a little problem: *how* can I verify that=20
once expired "Our Server's" public key is really "Our Server's" key... a=20
Certification Authority is something worth of spoofing... ;-) Maybe the=20
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 avoi=
d=20
too much trouble is to limit transactions to just *atomic* transactions=20
(checking account and getting some money are two different transactions).=
=20
This can still be spoofed if "Gateway X" makes its own transaction with=20
faked Outside's keys. Of course, We must limit the tansactions we accept =
in=20
"Our Server". Notice that a password and challenges are useless in this=20
kind of situations.
=BFAny other way? maybe we can get somethig a bit safer if we found somet=
hing=20
fixed, inmutable and rely on it (acting like some kind of virtual=20
communication channel between Outside and Our Server:
Untrusted
Outside <-------------> Gateway X <---------------> Our Server
^ ^
| |
\-------- Virtual secure communication channel -------/
=20
If every message "Outside" send to "Our Server" must have a response, the=
n=20
we could make "Our Server" send responses with some good (well tought)=20
cryptographic technique wich will refer somehow to "Outside's" message=20
fingerprint.
I mean, every message from the Outside must have a message signature (i.e=
=20
message must pass through MD5); and its response must have a valid=20
"Response to: <query's MD5 signature>" and (of course) that response must=
=20
be signed somehow. I still don't know how to do it well; but I will tell=20
you how as soon as I will know.
Thank you for wasting your time reading this.
--
I=F1igo Gonz=E1lez - 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
