> On 4/25/05, Bob Relyea <[EMAIL PROTECTED]> wrote: >> SSL 101 begins.... > > [excellent high-level overview of SSL handshaking snipped - may I > submit it for inclusion into the wiki?]
Wiki? what wiki? > [iang's quote snipped] > >> This 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). > > See, we're not really discussing SSL itself -- we're discussing an > attack versus the (CA|Internet) infrastructure: To be honest, I wasn't sure if we were talking about an attack on the protocol or on browsing as the app. If the timeout causes a restart in the protocol, then I think Bob probably has it right; the restart protocol should be sufficient to block any attack. If on the other hand the timeout of the Form post caused a new session to be opened completely, without regard to the old cached session (and shared master secret, etc) then it's an entirely new SSL context. Which would indicate the browser has opened itself up to an attack, perhaps. But, then I went on to ask how important this was; mostly from a risk point of view in that it would still be easier to conduct a full MITM with a dodgy cert than it would be to slice in and do a browser-timeout MITM. From the risks pov it would be embarrasing but not related to validated threats. Now, you are assuming a cert-based MITM. Sure, but we have to be clear that this is a different attack to the one that Tyler originally proposed. > Since the client isn't asked to authenticate by most eCommerce sites > or banks, if there's an attack against the infrastructure that directs > all traffic originally destined to Chase to another site, the server > can't really easily detect if it's talking to the original browser or > to a proxy. That means that the client has to be the one doing all > the authentication, and the only way it can do that is via the DNS > name and the certificate it gets. > > If the interloper can get a certificate that says he's Chase, from any > of the CAs that are embedded into the browser with the trust bit set, > he's gold. Yes, we know that can be done. See the GeoTrust white paper, the Shmoo exploit, etc etc. [good description about easy attack snipped] > Remember what Bruce Schneier said? "Using strong cryptography inside > an insecure process is like putting a high-grade lock on door and > leaving the window open." [paraphrased, I don't remember the exact > quote] Most attacks aren't going to be against the cryptography > (though there have been notable exceptions), since it's expensive to > attack the SSL itself. Instead, attack the infrastructure around it > -- hack the server, or get a cert from a trusted CA that lets you do > what you want because of client behavior, or social-engineer your way > into getting the information that's of value to you. You'd probably enjoy #8 on this page http://www.financialcryptography.com/mt/archives/000147.html > The Firefox UI has at least one UI improvement (next to the lock icon, > it shows the authenticated site name) to the standard process that > existed before -- but it's not enough. The CA infrastructure that is > currently in place is broken beyond repair, and now we're trying to > find ways of non-invasively modifying the user experience so that the > user herself can see the details of who she's sending information > to... before she sends it. iang _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
