Ian Grigg wrote:
But in your proposal, it would act just like http. You get a warning when you try to post to http (rather than https). The scenario you describe is the same as if your web page posted to a normal http:// site, The user will have a lock icon, but the post will be insecure. Firefox warns in this case (well Firefox warns in any case where the post is insecure).I was thinking through possible attack scenarios against this proposed UI and came up with a dangerous one:
You are filling out a form in a page served by a site certified by
Verisign. You hit the submit button. Your HTTPS connection has timed
out, so the browser initiates a new HTTPS connection. This time, the
phisher intercepts the connection attempt and responds with a
self-signed certificate. The browser does not warn, but the lock icons
disappear. It is unfortunately too late though, the form POST has
already been sent.
SSL doesn't work that way. If the phisher responds with any old cert, the connection won't be establish (unless the phisher also happens to have the privatekey associated with that cert).
Or, perhaps more interestingly, the phisher
intercepts and responds with any old cert
signed by any old CA. So the lock stays on.
Presumably the status bar domain name would
change so the cert would prefer to be consistent
there, hence your suggestion of a self-signed
cert (and sacrifice of the lock). This could
be improved with a look-alike cert from a root
CA.
The check on the site's cryptographic identity really has to happen at
connection time, before any data is sent. If the provided
cryptographic identity cannot be immediately correlated to the pending
request, a warning really must be issued.
Does the restart take no account of the prior
connection? If so, I'd suspect it would be
easy to knock out an existing connection, and
force a restart.
SSL 101 begins....
SSL has 2 modes: restart and full handshake.
Full handshakes.
When a client makes a connection to a server for the first time, it does a full handshake. In that full handshake, a key exchange is performed, the server's identity is verified, and optionally the client's identity is verified (not common in the commercial environment today). I'll leave the details of all of this to SSL 102, because it varies depending on the algorithms in use (DH verse RSA). Full handshakes are the only point in which certificates are exchanged. As part of the protocol each side does something to prove posession of the privatekey held in the certificate. If someone passes a certificate for which they do not have posession of the privatekey, SSL will fail somewhere in the handshake and a connection will not be established. When a full handshake is complete, Both sides with have posession of a 48 bit key called the master secret (again how this is accomplished I will leave to SSL 102). This secret is mixed with a random number from the client and a random number from the server to generate 2 session keys and 2 macing keys -- one session key is used by the client to encrypted data (and the server to decrypt it), the other is used by the server to encrypted data (and the client decrypt it). The 2 macing keys are used for data integrity (one the client uses to sign the other the server uses to sign). As part of the handshake, the server assigns a session id and sends it to the client.
restart handshakes:
Once a client and server have established a connection to one another, additional connection can be made using the common master secret each of them share. When the client goes to make a connection to a server it has previously connected before, the client can reuse the master secret. The client send a new random number and the session id the server assigned. The server looks up the master secret for that client by the session id. If it finds it it generates it's random number and sends it to the client. Again new encryption and macing keys are generated from the master secret and the new random numbers. If the server can't find the master secret (or the server has decided that the master secret should be expired), it can force a full handshake. (note the client can always force a full handshake by simply not
integrity:
before any SSL session is completely established, each side sends a mac of the hash of all the handshake messages it sent. This tells the other side that 1) it's peer agrees with the data it believed to be sent, and 2) the peer has possession of the correct master secret. On active attacker in the middle will be discovered if they try to interfere with this protocol.
Conclusions:
1) A MITM attack on SSL involves either attacking the authentication scheme (why, yes, I'm amazon.com), or attacking the master secret (see bleckenbauker for some active attacks which required some changes to many SSL implementations of the protocol). The former lets you fake one side (You could make the client think you were amazon, I'm not sure you could sit in a middle of a client auth session, though. I'd have to look at the protocol more closely -- I'm not so sure SSL protects against this case. I'll have to go back and think about this.... In practice, however, it doesn't matter since most sites do not use client auth, spoofing the server is sufficient). The latter allows you to fake both sides, tap both sides, and do so until one or the other changes the session key. Accomplishing either is a full attack on SSL (not just MITM).
end SSL 101....
I'm not quite sure of what the import of thisThis attack requires either breaking a private key from a valid signed certificate, or somehow learning the master secret between a client and server -- both of which SSL is (believed to be) strong against. If you can do either of these, then you have a viable attack on SSL itself, and even encrypted-"only" channels are completely vunerable (ones which you wouldn't verify the certificate).
attack means. It seems to be a relatively
straightforward MITM. In which case, if a
phisher has gone to the trouble of running an
MITM we would have to ask whether he'd bother
to get a CA-signed cert to do it, in which
case he more or less becomes a chinese proxy,
and he could just as easily attack the first
connection. (It's more difficult to untraceably
"own" an intermediate router than to get a cert.)
iang
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
