[114294] in cryptography@c2.net mail archive
Fixing SSL (was Re: Dutch Transport Card Broken)
daemon@ATHENA.MIT.EDU (Philipp =?utf-8?q?G=C3=BChring?=)
Wed Jan 30 11:49:43 2008
From: Philipp =?utf-8?q?G=C3=BChring?= <pg@futureware.at>
To: Cryptography <cryptography@metzdowd.com>
Date: Wed, 30 Jan 2008 11:25:04 +0100
In-Reply-To: <479FB105.6060406@echeque.com>
X-MDaemon-Deliver-To: cryptography@metzdowd.com
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 i=
s=20
secure doesn=C2=B4t work in a world of phishing and identity theft anymore.
We have the paradox situation that I have to tell people that they should u=
se=20
HTTPS with server-certificates and username+password inside the HTTPS=20
session, because that=C2=B4s more secure than client certificates ...
Does anyone have an idea how we can fix this flaw within SSL/TLS within a=20
reasonable timeframe, so that it can be implemented and shipped by the=20
vendors in this century?
(I don=C2=B4t think that starting from scratch and replacing SSL makes much=
sense,=20
since it=C2=B4s 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-agreem=
ent=20
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=
=C2=B4t=20
enough in reality. (1 out of 256 broken packets gets injected into your TCP=
=20
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=C2=B4t noti=
ced any=20
round trip problems there. (But feel free to send me a traffic capture file=
=20
that shows the problem)
I once implemented SSL over GSM data channel (without PPP and without TCP),=
=20
and discovered that SSL needs better integrity protection than raw GSM=20
delivers. (I am quite sure that=C2=B4s why people normally run PPP over GSM=
=20
channels ...)
SSH has the same problems. It also assumes an active attack in case of=20
integrity problems of the lower layer, and terminates the connection.
> Layering communications=20
> 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=C3=BChring
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
