Hi, > SSL key distribution and management is horribly broken, > with the result that everyone winds up using plaintext > when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) > SSL is layered on top of TCP, and then one layers one's > actual protocol on top of SSL, with the result that a > transaction involves a painfully large number of round > trips. SSL already looks quite round-trip optimized to me (at least the key-agreement part) > We really do need to reinvent and replace SSL/TCP, > though doing it right is a hard problem that takes more > than morning coffee. TCP could need some stronger integrity protection. 8 Bits of checksum isn´t enough in reality. (1 out of 256 broken packets gets injected into your TCP stream) Does IPv6 have a stronger TCP? > As discussed earlier on this list, layering induces > excessive round trips. The SSL implementations I analyzed behaved quite nicely, I didn´t noticed any round trip problems there. (But feel free to send me a traffic capture file that shows the problem) I once implemented SSL over GSM data channel (without PPP and without TCP), and discovered that SSL needs better integrity protection than raw GSM delivers. (I am quite sure that´s why people normally run PPP over GSM channels ...) SSH has the same problems. It also assumes an active attack in case of integrity problems of the lower layer, and terminates the connection. > Layering communications > protocols is analogous to having a high level > interpreter written in a low level language. What we > need instead of layering is a protocol compiler, > analogous to the Microsoft IDL compiler. The Microsoft > IDL compiler automatically generates a C++ interface > that correctly handles run time version negotiation, > which hand generated interfaces always screw up, with > the result that hand generated interfaces result in > forward and backward incompatibility, resulting in the > infamous Microsoft DLL hell. Similarly we want a > compiler that automatically generates secure message > exchange and reliable transactions from unreliable > packets. (And of course, run time version negotiation) Sounds like an interesting idea to me. Best regards, Philipp Gühring --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
