SHTTP:The Secure HyperText Transfer Protocol
Xiaodong Fu
1.Requirements for HyperText Transfer Protocol
Security
1.1General Requirements
Confidentiality
It must provide confidentiality of the
HTTP transaction, via encryption of the HTTP messages.this is particularly
critical
in the common case of form data or other user input being passed
in the URL.
Service Authentication
-
It must support the authentication of the HTTP server to the client.
-
It should support the authentication of gatewayed services to the client.
-
It should support the authentication of the origin HTTP server or gatewayed
services regardless of intermediary proxy or caching servers.
-
To allow user privacy, It must support service authentication without
user authentication.
Because the identity of the object being requested
is potentially sensitive, service authentication should occur before any
part of the request, including the URI of the requested object, is passed.
In cases where the authentication process depends on the URI (or other
header data) of the request, such as gatewayed services, the minimum
necessary information to identify the entity to be authenticated should
be passed.
User Authentication
-
It must support the authentication of the user to the server.
-
It should support the authentication of the client to gatewayed services.
-
It should support the authentication of the client to the origin HTTP
server regardless of intermediary proxy servers.
Integrity
HTTPSec must provide assurance of the integrity
of the HTTP
transaction, including the HTTP headers
and data objects of both
client requests and server responses
1.2 A number of secondary requirements:
-
Ease of integration with other features of HTTP.
-
Support of multiple mechanisms for the above services.
main Index.
2. Overview and history of SHTTP.
-
S-HTTP was designed by E. Rescorla and A. Schiffman of EIT to secure HTTP
connections. S-HTTP provides a wide variety of mechanisms to provide for
confidentiality, authentication, and integrity. Separation of policy from
mechanism was an explicit goal. The system is not tied to any particular
cryptographic system, key infrastructure, or cryptographic format.
The internet draft is fairly clear in its presentation of the protocol.
-
S-HTTP is a superset of HTTP, which allows messages to be encapsulated
in various ways. Encapsulations can include encryption, signing, or MAC
based authentication. This encapsulation can be recursive, and a message
can have several security transformations applied to it.
-
S-HTTP also includes header definitions to provide key transfer, certificate
transfer, and similar administrative functions. S-HTTP appears to be extremely
flexible in what it will allow the programmer to do. S- HTTP also offers
the potential for substantial user involvement in, and oversight of, the
authentication & encryption activities.
-
S-HTTP does not rely on a particular key certification scheme. It includes
support for RSA, in-band, out-of-band and kerberos key exchange. Key certifications
can be provided in a message, or obtained elsewhere. Like SSL, client public
keys are not required.
main Index.
4.Comments on SHTTP.
-
The default operational mode of S-HTTP is substantially more resistant
to attack than that of SSL. It resists clear text
cryptanalysis, Man In The Middle, and replay attacks. It is more robust
than SSL, because option renegotiation and retries are permitted.
-
The use of in band key exchange is potentially
very problematic; the authors don't spend enough time ensuring
keys are transferred properly. An improper transfer would be a scheme that
sends Key B as Ea(B). That is to say, key B which replaces key A can not
be sent using key A to encrypt it. If an attacker has broken key A, then
he will have key B, and the change of key is a waste of time (with respect
to that attacker.) Exactly this mistake was made often by the Japanese
in World War Two. (Kahn) Expecting programmers to learn from this mistakes
of others (especially 50 year old mistakes) is a poor bet.
main Index.