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