[334] in WWW Security List Archive
Re: SSL
daemon@ATHENA.MIT.EDU (wmperry@spry.com)
Mon Jan 23 12:16:46 1995
From: wmperry@spry.com
Date: Mon, 23 Jan 95 05:31 PST
To: www-security@ns2.rutgers.edu
In-Reply-To: <95Jan23.193458gmt+9(?illegal end of message identification?) :00.
63619@dxal18.cern.ch>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Concept Archive writes:
>
> > 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.
Phillip,
Having used the terisa toolkit to implement S-HTTP in the cern 3.0 code
recently, I was wondering what toolkit you were using? Do you have access
to TIPEM, or just RSAREF/IDEA/something similar?
And are you using the 1.0 or 1.1 SHTTP spec? We are supposed to be
getting the 1.1 code from terisa today, and alan said that 1.1 does not
talk to 1.0, and vice versa.
Also, did you implement some of the server-side include stuff? It makes
administration of the web pages much simpler (using the Terisa way of
saying <!--#dn name="some name" -->, etc).
Thanks for any info,
Bill P.
