Ralf Hauser wrote: > We are trying to build a plugin to prevent phishing. See also > http://www.w3.org/2005/Security/usability-ws/papers/08-esecurity-browser-enhancements/ > > and https://bugzilla.mozilla.org/show_bug.cgi?id=322661 .
Ralf, first you asked for the handshake hash values, which differ for every handshake, and are not the same across multiple handshakes with the same session keys, never the same in any two handshakes. Then you asked for the master secret, or a hash thereof. This would be constant across multiple handshakes with the same SSL session. But SSL sessions are themselves rather short lived things. The two values you asked for (handshake hashes, session keys) have very different properties. So, let me ask again: what do you really need? If what you need is an identifier of an SSL session, the SSL session ID already exists, is as unique as the session key, is not secret, is available (that is, there is an accessor function for it) today. Will this do? If not, why not? > Probably, the approaches are best described in > http://www.esecurity.ch/OHB06b.pdf . >>>I see that I can get at the serverCert in >>>http://xulplanet.com/references/xpcomref/ifaces/nsISSLStatus.html >> >>Yes, unlike the other values requested above, the cert is public info, >>and is typically sent over the wire in the clear. > > So, if the 36 bytes are not available, hashing the session key plus the > server certificate most likely identify an SSL session pretty uniquely as a > fall-back as well - would you agree? The SSL session is uniquely identified by the 256-bit session ID. But given that new sessions (with new session keys and IDs) are established the first time you visit any SSL server after restarting your client program, just how do you think any value as unique as the session key is going to thwart phishing? _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
