[333] in WWW Security List Archive
Re: SSL
daemon@ATHENA.MIT.EDU (Mr Concept Archive)
Mon Jan 23 08:56:34 1995
To: www-security@ns2.rutgers.edu
cc: archive@dxal18.cern.ch, JohnHemming@mkn.co.uk
In-reply-to: Your message of "Sun, 22 Jan 1995 23:48:53 +0900."
<199501221845.NAA18003@ns1.rutgers.edu>
Date: Mon, 23 Jan 1995 19:34:48 +0900
From: Mr Concept Archive <archive@dxal18.cern.ch>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
>I would appreciate it if anyone can indicate what the specific flaws are in SSL
I thought it was clear from my original mail that the problem was in the
original spec, not the modified one.
The main design difference between SSL and S-HTTP/SHEN is that SSL operates at
the network layer (TCP/IP) and SHTTP/SHEN operates at the Application layer.
This means that SSL may be used to secure NNTP, FTP etc in addition to HTTP.
Working at the application layer allows a more flexible arrangement though, the
security enhancements can directly reference the HTTP operations.
In practice SSL is quite adequate for use as a means of enforcing payment for
pages from a server or to provide a secure login type of security. S-HTTP and
particularly the Shen trust model aim to provide an integrated e-commerce
solution that is workable in the very large scale.
In other words SSL and S-HTTP are very different designs with very different
purposes.
Politically SSL conflicts with existing IETF proposals to secure the TCP/IP
layer. Although the IETF does not have any divine right to set standards they
are very influential with the vendors.
I am mid way through implementing S-HTTP in the CERN library. The main
difference between my current plans and S-HTTP is that I want to see if the
security negotiation mechanism of S-HTTP may be generalised to the whole of
HTTP. If security requires multiple round trips to work then why not take
advantage of the extra trips to improve the existing negotiation mechanism.
Specifically, it is rather unsatisfactory to send 1K of accept headers per
transaction! The structural properties are unchanged however.
Phill Hallam-Baker
