Re: An attack on paypal
Sunder <[EMAIL PROTECTED]> writes: > The worst trouble I've had with https is that you have no way to use host > header names to differentiate between sites that require different SSL > certificates. > > i.e. www.foo.com www.bar.com www.baz.com can't all live on the same IP and > have individual ssl certs for https. :( This is because the cert is > exchanged before the http 1.1 layer can say "I want www.bar.com" > > So you need to waste IP's for this. Since the browser standards are > already in place, it's unlikely to be to find a workaround. i.e. be able > to switch to a different virtual host after you've established the ssl > session. :( This is being fixed. See draft-ietf-tls-extensions-06.txt -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
Re: Maybe It's Snake Oil All the Way Down
[EMAIL PROTECTED] (Peter Gutmann) writes: > Bodo Moeller <[EMAIL PROTECTED]> writes: > > >Using an explicit state machine helps to get code suitable for multiplexing > >within a single thread various connections using non-blocking I/O. > > Is there some specific advantage here, or is it an academic exercise? Some > quirk of supporting certain types of hardware like nCipher boxes that do async > crypto/scatter-gather? I've had to do this on environments where threads weren't a viable option. See, for instance, my paper from USENIX Security 2002. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
Re: Maybe It's Snake Oil All the Way Down
Derek Atkins <[EMAIL PROTECTED]> writes: > Eric Murray <[EMAIL PROTECTED]> writes: > > > Too often people see something like Peter's statement above and say > > "oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just > > do it in XML instead and then it'll work fine" which is simply not true. > > The formatting of the certificates is such a minor issue that it is lost > > in the noise of the real problems. And Peter publishes a fine tool > > for printing ASN.1, so the "human readable" argument is moot. > > Actually, the ASN.1 part is a major factor in the X.509 > interoperability problems. Different cert vendors include different > extensions, or different encodings. They put different information > into different parts of the certificate (or indeed the same > information into different parts). Does the FQDN for a server cert > belong in the DN or some extension? What about the email address for > a user cert? This isn't really true in the SSL case: To a first order, everyone ignores any extensions (except sometimes the constraints) and uses the CN for the DNS name of the server. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
