[2868] in WWW Security List Archive
Re: Secure-HTTP vs SSL
daemon@ATHENA.MIT.EDU (Elgin Lee)
Sat Aug 31 20:20:44 1996
From: "Elgin Lee" <ehl@terisa.com>
To: Dave Wreski <tel1dvw@is.ups.com>
Date: Sat, 31 Aug 1996 15:06:35 -0800
CC: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
> Date: Fri, 30 Aug 1996 03:47:38 -0400 (EDT)
> From: Dave Wreski <tel1dvw@is.ups.com>
> To: www-security@ns2.rutgers.edu
> Subject: Secure-HTTP vs SSL
>
> Could someone explain to me what he difference between these two
> protocols(?) are?
SSL is a transport-layer protocol that provides channel-level security,
whereas S-HTTP is an application-layer protocol that provides
document-level security.
Because SSL operates at the transport layer, it deals with secure
data rather than secure documents. Data on the wire is protected,
but it loses all security attributes once it leaves the secure
channel. As a result, SSL doesn't support non-repudiation--the
ability to demonstrate to a third party that a given document was
given to you signed by the serving party.
Because S-HTTP is an application-layer protocol, it can support
non-repudiation and other document security attributes. Being at the
application layer also enables it to be more flexible at handling
document-level security.
The Visa/MasterCard-sponsored SET protocol is another example of an
application-layer protocol. Again, being at the application layer
enables it to tailor its cryptographic operations (DES here,
cleartext there, stronger RSA for credit card numbers, and CDMF for
other spots) to provide precisely the mix of cryptography required
for the purpose at hand.
Because SSL is a transport-layer protocol, you can layer other
protocols on top--such as telnet, if you want a secure telnet
connection. That's not possible with S-HTTP, because S-HTTP is
designed to handle documents/messages.
You could also layer a secure-document protocol on top of SSL, but
that's what S-HTTP is! S-HTTP could conceivably be run on top of
SSL, although that's probably sub-optimal because it incurs
unnecessary overhead due to redundant encryption.
Elgin
