Fixing SSL (was Re: Dutch Transport Card Broken)

[Dan Kaminsky]

>> (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 majordomo at metzdowd.com
>   

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com