>> (as if anyone uses client certificates anyway)? >> > > Guess why so few people are using it ... > If it were secure, more people would be able to use it. > > People don't use it because the workload of getting signed up is vastly beyond their skillset, and the user experience using the things is pretty bad too. > And there are hundreds of internal systems I heard of that are using client > certificates in reality every day. > There's always a few people using a technology. It's certainly a nonplayer out there. Probably more servers out there authing with Digest, honestly. > Validated email addresses for spamming. Spear-phishing perhaps, ... > > > There are CA´s on this planet that put things like social security numbers > into certificates. > > Who? Seriously, that's pretty significant, I'd like to know who does this. > Where does the SSL specification say that certificates shouldn´t contain > sensitive information? I am missing that detail in the security consideration > section of the RFC. > The word "public" in Public Key isn't exactly subtle.
> Do we have any more ideas how we can get this flaw fixed before it starts > hurting too much? > Make it really easy to use some future version of SSL client certs, and quietly add the property you seek. Ease of use drives technology adoption; making the tech actually work is astonishingly secondary. Heh, you asked :) > We have an issue here. And the issue isn´t going to go away, until we > deprecate SSL/TLS, or it gets solved. > To be clear, we'd *have* an issue, if any serious number of people used SSL client certs. I think you have a point that if SSL client certs become very popular going forward, then every website you go to will quietly grab your identity through their ad banners. > * We fix SSL > Does anyone have a solution for SSL/TLS available that we could propose on > the > TLS list? > If not: Can anyone with enough protocol design experience please develop it? > What solution could there be? You're actually going to SSL to the banner ad network, and you're going to give them your client cert. > * We deprecate SSL for client certificate authentication. > We write in the RFC that people MUST NOT use SSL for client authentication. > (Perhaps we get away by pretending that client certificates accidently > slipped > into the specification.) > People by in large do not use SSL client cert authentication. This is problematic, as there's some very nice cryptographic aspects of the system. > * We switch from TLS to hmmm ... perhaps SSH, which has fixed the problem > already. > Hmm, there we would have to write all the glue RFCs like "HTTP over SSH" > again ... > I used to code for SSH. SSL is an entire top-to-bottom stack, replete with a deep PKI infrastructure. SSH? Tunneling transport, barely even librarized. > Try to send a DVD iso image (4GB) over a SSL or SSH encrypted link with bit > errors every 10000 bits with a client software like scp that cannot resume > downloads. I gave up after 5 tries that all broke down in average after 1 GB. > (In that case it was a hardware (bad cable) initiated denial of service > attack ;-) > The problem here isn't checksums. SSH is notoriously buggy when packets are dropped. I think there are certain windows in which OpenSSH assumes it will get a response. If it doesn't, it just dies. So, outages more than a few hundred milliseconds have a small percentage chance of causing the session to permanently stall. "Corrupted MAC on input" -- this is a decent sign of corruption at the app layer. Did you really try this with OpenSSL? I've had much better luck there. > If the link layer gives you 1/256, and the TCP layer gives you 1/65536, and > the SSL layer demands 0/16777216, then end up with 1/16777216 too much. > > Actually, 256*65536 = 1677216 :) In actuality, you have both IP and TCP checksums. So you get 8 bits from link, 16 bits from IP, and 16 bits from TCP. A random corrupt packet has about 2^40 odds of getting through. Of course, one real problem is that the checksum algorithms don't exactly distribute noise randomly, and noise is not random. Still, corruption doesn't start being a problem until you get some pretty serious amounts of transfer. (Interestingly, I've been looking at IPsec lately, not for encryption, but for better checksumming.) > Best regards, > Philipp Gühring > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]