>> (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

> 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]

Reply via email to