Philipp Gühring wrote:
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 ...)
If I recall correctly, SSL was designed chronologically after ISO OSI
Network-Layer Security Protocol (yes, the official WAN was actually X.25
at one point) or Transport Layer Security Protocol, both in their
connection-oriented flavor, which used ideas originating from DecNET
designs (researcher names Tardo, Alagappan; I once had a patent number
in this thread of protocol engineering, but I lost it). Anyway, the key
point in these visionary ideas is that the D-H exchange occurs *before*
the exchange of security certificates. This provided the traffic-flow
confidentiality that becomes desirable to protect privacy these days.
So, you got your fix with OSI NLSP or TLSP, you just have to overcome
the *power of the installed base*!
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada H2M 2A1
Tel.: (514)385-5691
Fax: (514)385-5900
web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
