[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 <[email protected]>
"Never say anything online that you wouldn't want to see on the
front page of The New York Times." - alt.2600.moderated Posting