HTTP
Click on the red underlined text to get to the source
... clients and servers
is the HyperText Transfer Protocol (HTTP) [RFC-2616]. The ease of
use of the Web has prompted its widespread employment as a
...
... authenticate
each other and exchange sensitive information confidentially. The
original HTTP specification had only modest support for the
cryptographic mechanisms appropriate for such transactions ...
... transactions.
Secure HTTP (S-HTTP) provides secure communication mechanisms between
an HTTP client ...
...
Secure HTTP (S-HTTP) provides secure communication mechanisms between
an HTTP client-server pair in order to enable spontaneous commercial
...
... HTTP (S-HTTP) provides secure communication mechanisms between
an HTTP client-server pair in order to enable spontaneous commercial
transactions for a wide range ...
...
Secure HTTP is a secure message-oriented communications protocol
designed for use in conjunction with HTTP ...
... HTTP is a secure message-oriented communications protocol
designed for use in conjunction with HTTP. It is designed to coexist
with HTTP's messaging model and to be easily integrated with HTTP ...
... conjunction with HTTP. It is designed to coexist
with HTTP's messaging model and to be easily integrated with HTTP
applications.
...
... HTTP. It is designed to coexist
with HTTP's messaging model and to be easily integrated with HTTP
applications.
...
... Secure HTTP provides a variety of security mechanisms to HTTP clients
and servers, providing the security service options appropriate to
...
... preserving the transaction model and implementation characteristics
of HTTP.
Several cryptographic ...
... cryptographic message format standards may be incorporated
into S-HTTP clients and servers, particularly, but in principle not
limited to, [CMS] and [MOSS ...
... limited to, [CMS] and [MOSS]. S-HTTP supports interoperation among a
variety of implementations, and is compatible with HTTP. S-HTTP ...
... MOSS]. S-HTTP supports interoperation among a
variety of implementations, and is compatible with HTTP. S-HTTP
aware clients ...
... HTTP supports interoperation among a
variety of implementations, and is compatible with HTTP. S-HTTP
aware clients can communicate with S-HTTP ...
... HTTP
aware clients can communicate with S-HTTP oblivious servers and
vice-versa, although such transactions obviously would not use S-HTTP ...
... HTTP oblivious servers and
vice-versa, although such transactions obviously would not use S-HTTP
security features.
...
... transactions can occur without requiring individual users to have
an established public key. While S-HTTP is able to take advantage
of ubiquitous certification infrastructures, its deployment ...
... end-to-end secure transactions, in contrast with the
original HTTP authorization mechanisms which require the client to
...
... be used to support encryption of fill-out forms, for example. With
S-HTTP, no sensitive data need ever be sent over the network in the
clear.
...
... clear.
S-HTTP provides full flexibility of cryptographic algorithms, modes
and parameters. Option negotiation ...
... certificate").
S-HTTP attempts to avoid presuming a particular trust model, although
its designers admit to a conscious effort to facilitate
...
... public key certificates.
S-HTTP differs from Digest-Authentication, described in [RFC-2617] in
...
...
This document describes S-HTTP/1.4. It differs from the previous
memo in that it differs from the previous memo in its support of
the Cryptographic Message Syntax ...
...
The creation of an S-HTTP message can be thought of as a a function
with three inputs:
...
... with three inputs:
1. The cleartext message. This is either an HTTP message
or some other data object. Note that since the cleartext message
...
... is carried transparently, headers and all, any version of HTTP
can be carried within an S-HTTP wrapper ...
... sender applies the enhancements to the message
clear-text to create the S-HTTP message.
The processing steps required to transform the cleartext message into
...
...
The processing steps required to transform the cleartext message into
the S-HTTP message are described in Sections 2 and 3. The processing
steps required to merge the sender's and receiver ...
...
The recovery of an S-HTTP message can be thought of as a function of
four distinct inputs:
...
... sections 4 and 5 for details on how to do this.)
In order to recover an S-HTTP message, the receiver needs to read the
headers ...
... (input 4 above) and that the receiver requested (input 2 above) as
well as the current preferences to see if the S-HTTP message was
appropriately transformed. This process may require interaction with
the user to verify that the enhancements are acceptable to the user.
...
...
In support of bulk encryption, S-HTTP defines two key transfer
mechanisms, one using public-key enveloped key exchange ...
... both parties to insure the freshness of transmissions. Additionally,
the integrity protection provided to HTTP headers permits
implementations to consider the Date: header allowable in HTTP
messages ...
... HTTP headers permits
implementations to consider the Date: header allowable in HTTP
messages as a freshness indicator, where appropriate (although this
requires implementations to make allowances for maximum clock skew
between parties, which we choose not to specify).
...
... application
requirements, variability of user sophistication, and disparate
implementation constraints, Secure HTTP deliberately caters to a
variety of implementation options. See Section 8 for implementation
recommendations and requirements ...
...
Syntactically, Secure HTTP messages are the same as HTTP, consisting
of a request or status line followed by headers ...
...
Syntactically, Secure HTTP messages are the same as HTTP, consisting
of a request or status line followed by headers and a body. However,
...
...
This document uses the augmented BNF from HTTP [RFC-2616]. You should
refer to that document for a description of the syntax.
...
...
In order to differentiate S-HTTP messages from HTTP messages and
allow for special processing, the request line should use the special
...
...
In order to differentiate S-HTTP messages from HTTP messages and
allow for special processing, the request line should use the special
Secure" method ...
... allow for special processing, the request line should use the special
Secure" method and use the protocol designator "Secure-HTTP/1.4".
Consequently, Secure-HTTP and HTTP ...
... method and use the protocol designator "Secure-HTTP/1.4".
Consequently, Secure-HTTP and HTTP processing can be intermixed on
the same TCP port ...
... HTTP/1.4".
Consequently, Secure-HTTP and HTTP processing can be intermixed on
the same TCP port, e.g. port ...
...
S-HTTP responses should use the protocol designator "Secure-
HTTP/1.4". For example:
...
... S-HTTP responses should use the protocol designator "Secure-
HTTP/1.4". For example:
Secure-HTTP ...
... HTTP/1.4". For example:
Secure-HTTP/1.4 200 OK
Note that the status in the Secure HTTP response ...
... HTTP/1.4 200 OK
Note that the status in the Secure HTTP response line does not
indicate anything about the success or failure of the unwrapped HTTP
request. Servers should always use 200 OK provided that the Secure
...
... Note that the status in the Secure HTTP response line does not
indicate anything about the success or failure of the unwrapped HTTP
request. Servers should always use 200 OK provided that the Secure
HTTP processing is successful. This prevents analysis of success or
...
... indicate anything about the success or failure of the unwrapped HTTP
request. Servers should always use 200 OK provided that the Secure
HTTP processing is successful. This prevents analysis of success or
failure for any request, which the correct recipient can determine
from the encapsulated ...
... Secure HTTP Header Lines ...
... header lines described in this section go in the header of a
Secure HTTP message. All except 'Content-Type' and 'Content-Privacy-
...
...
This document refers to the header block following the S-HTTP
request/response line and preceding the successive CRLFs collectively
as "S-HTTP headers".
...
... header block following the S-HTTP
request/response line and preceding the successive CRLFs collectively
as "S-HTTP headers".
...
... privacy enhancements have been removed) would be an HTTP message. In
this case, there shall be a Content-Type line reading:
...
... 2616draft.
If the inner message is an S-HTTP message, then the content type
shall be 'application/s-http'. (See Appendix for the definition of
...
... headers'). But in any case, final headers should themselves always be
S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers ...
... S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are
never passed unenhanced.
...
... S-HTTP encapsulation of non-HTTP data is a useful mechanism for
passing pre-enhanced data (especially presigned data) without
requiring that the HTTP headers ...
... HTTP data is a useful mechanism for
passing pre-enhanced data (especially presigned data) without
requiring that the HTTP headers themselves be pre-enhanced.
...
... in the content type line corresponding to that inner content, and for
HTTP messages shall be 'message/http'.
...
... MAC should be computed over the
encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that
MACs ...
... encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that
MACs should be computed using the following algorithm ...
... Note that this header line can be used to provide a more advanced
equivalent of the original HTTP Basic authentication mode in that the
user can be asked to provide a username ...
... privacy enhancements have been removed,
the resulting (possibly protected) contents will be a normal HTTP
request. Alternately, the content may be another Secure-HTTP message,
in which case privacy ...
... removed,
the resulting (possibly protected) contents will be a normal HTTP
request. Alternately, the content may be another Secure-HTTP message,
in which case privacy enhancements should be unwrapped until clear
...
... removed, the final de-enhanced content should be a valid HTTP request
(or response) unless otherwise specified by the Content-Type line.
...
... encryption. Any message may be either signed, encrypted, both, or
neither. Note that the 'auth' protection mode of S-HTTP is provided
independently of CMS coding via the MAC ...
... content type that matches the Content-Type line in the S-HTTP
headers. Encrypted messages should use multipart/encrypted. Signed
messages ...
... Permitted HTTP headers ...
... RFC-2616] headers should appear in the inner
content (i.e. the message/http) of an S-HTTP message but should not
appear in the S-HTTP message wrapper ...
... content (i.e. the message/http) of an S-HTTP message but should not
appear in the S-HTTP message wrapper for security reasons. However,
...
... to the encapsulated data. These headers may appear in the S-HTTP
headers as well.
Please note that although brief descriptions of the general purposes
...
... among multiple potential security contexts within which this message
could be interpreted. Note that the unwrapped HTTP message will have
it's own Host field (assuming it's an HTTP/1.1 ...
... HTTP message will have
it's own Host field (assuming it's an HTTP/1.1 message). If these
fields do not match, the server should respond with a 400 status
code.
...
... The Connection field has precisely the same semantics in S-HTTP
headers as it does in HTTP headers. This permits persistent
connections ...
... Connection field has precisely the same semantics in S-HTTP
headers as it does in HTTP headers. This permits persistent
connections to be used with S-HTTP ...
...
As described in Section 1.3.2, every S-HTTP request is (at least
conceptually) preconditioned by the negotiation options provided by
...
... We define new headers (to be used in the encapsulated HTTP header,
not in the S-HTTP header) to permit negotiation ...
... All RFC1779hist(-> 3494 | 2253(-> 4514prop | 4510prop)) values should use ',' as a separator rather than ';',
since ';' is used as a statement separator in S-HTTP.
Pattern-data is a modified RFC1779hist(-> 3494 | 2253(-> 4514prop | 4510prop)) ...
... computations. The key information is carried in this header line must
be in the inner secured HTTP request, therefore use in unencrypted
messages is not permitted.
...
... anchor, it
is possible to combine a number of headers on a single S-HTTP
Cryptopts header line. The names of the anchors ...
... tag) | ""
cryptopt-list = cryptopt *(";" cryptopt)
cryptopt = <S-HTTP cryptopt lines described below>
tag = <value used in HTML ...
... orig-required=cms; recv-optional=cms,MOSS
If a message contains both S-HTTP negotiation headers and headers ...
... these global options apply, even if some of the options headers do
not appear in the bound options. Rather, the S-HTTP defaults found in
Section 3.2.4.11 apply.
...
... permits other agents to detect that they are communicating with an
S-HTTP compliant agent and generate the appropriate cryptographic
...
...
For implementations compliant with this specification, the value must
be 'S-HTTP/1.4'.
...
... the client may possibly achieve satisfaction through another request.
HTTP already has this concept with the 3XX redirection codes.
In the case of S-HTTP ...
... HTTP already has this concept with the 3XX redirection codes.
In the case of S-HTTP, it is conceivable (and indeed likely) that the
server expects the client to retry his request using another set of
...
... should be carried in the header of the encapsulated HTTP message,
precisely as client options are carried.
...
...
The HTTP errors 'Unauthorized 401', 'PaymentRequired 402' represent
failures of HTTP style authentication ...
... The HTTP errors 'Unauthorized 401', 'PaymentRequired 402' represent
failures of HTTP style authentication and payment schemes. While S-
...
... authentication and payment schemes. While S-
HTTP has no explicit support for these mechanisms, they can be
performed under S-HTTP while taking advantage of the privacy ...
... HTTP has no explicit support for these mechanisms, they can be
performed under S-HTTP while taking advantage of the privacy services
...
... privacy services
offered by S-HTTP. (There are other errors for S-HTTP specific
authentication ...
... services
offered by S-HTTP. (There are other errors for S-HTTP specific
authentication errors.)
...
... cryptographic enhancements is worth
attempting. This header shall also be used in the case where an HTTP
request has been made but an S-HTTP request should have been made.
Obviously, this serves no useful purpose other than signalling an
...
... attempting. This header shall also be used in the case where an HTTP
request has been made but an S-HTTP request should have been made.
Obviously, this serves no useful purpose other than signalling an
error if the original request should have been encrypted ...
... SecurityRetries for S-HTTP Requests ...
... SecurityRetries for HTTP Requests ...
...
If the 420 code is returned in response to an HTTP request, it
indicates that the request should be retried using S-HTTP and the
...
... If the 420 code is returned in response to an HTTP request, it
indicates that the request should be retried using S-HTTP and the
cryptographic options indicated in the response header ...
...
This error code indicates that something about the S-HTTP request was
bad. The error code is to be followed by an appropriate explanation,
...
... proxy has placed the If-Modified-Since header
in the S-HTTP headers of its request. This response indicates that
the following S-HTTP message contains sufficient keying material ...
... in the S-HTTP headers of its request. This response indicates that
the following S-HTTP message contains sufficient keying material for
the proxy ...
... proxy to forward the cached document for the new requestor.
In general, this takes the form of an S-HTTP message where the actual
enhanced content is missing, but all the headers and keying material ...
... These headers are again internal to HTTP, but may contain S-HTTP
negotiation options of significance to S-HTTP ...
... HTTP
negotiation options of significance to S-HTTP. The request should be
redirected in the sense of HTTP, with appropriate cryptographic ...
... negotiation options of significance to S-HTTP. The request should be
redirected in the sense of HTTP, with appropriate cryptographic
precautions being observed.
...
... URL implies that the target server is
S-HTTP capable, and that a dereference of this URL should undergo S-
HTTP ...
... HTTP capable, and that a dereference of this URL should undergo S-
HTTP processing.
Note that S-HTTP ...
... HTTP processing.
Note that S-HTTP oblivious agents should not be willing to
dereference a URL ...
...
Failure to authenticate or decrypt an S-HTTP message should be
presented differently from a failure to retrieve the document.
Compliant clients ...
... Clients shall provide a method for determining that HTTP requests are
to be signed and for determining which (assuming there are many)
certificate ...
...
While S-HTTP has always supported preenhanced documents, in previous
versions it was never made clear how to actually implement them.
...
... This section describes two methods for doing so: preenhancing the
HTTP request/response and preenhancing the underlying data.
...
...
It is also possible using S-HTTP to sign the underlying data and send
it as an S-HTTP messsage. In order to do this, one would take the
...
... It is also possible using S-HTTP to sign the underlying data and send
it as an S-HTTP messsage. In order to do this, one would take the
signed document (a CMS ...
... signed document (a CMS or MOSS message) and attach both S-HTTP
headers (e.g. the S-HTTP request/response line, the Content-Privacy-
...
... signed document (a CMS or MOSS message) and attach both S-HTTP
headers (e.g. the S-HTTP request/response line, the Content-Privacy-
Domain ...
... Privacy-
Domain) and the necessary HTTP headers (including a Content-Type that
reflects the inner content).
...
... reflects the inner content).
SECURE * Secure-HTTP/1.4
Content-Type: text/html
...
... As required by Section 7.3, the result above needs to be itself
encapsulated to protect the HTTP headers. the obvious case [and the
one illustrated here] is when confidentiality is required, but the
...
... auth enhancement or even the null transform might be applied instead.
That is, the message shown above can be used as the inner content of
a new S-HTTP message, like so:
SECURE * Secure-HTTP ...
...
To unfold this, the receiver would decode the outer S-HTTP message,
reenter the (S-)HTTP parsing loop to process the new message, see
...
... receiver would decode the outer S-HTTP message,
reenter the (S-)HTTP parsing loop to process the new message, see
that that too was S-HTTP, decode that, and recover the inner content.
...
... reenter the (S-)HTTP parsing loop to process the new message, see
that that too was S-HTTP, decode that, and recover the inner content.
Note that this approach can also be used to provide freshness of
...
...
The use of S-HTTP presents implementation issues to the use of HTTP
proxies. While simply having the proxy ...
... proxies. While simply having the proxy blindly forward responses is
straightforward, it would be preferable if S-HTTP aware proxies were
still able to cache ...
... still able to cache responses in at least some circumstances. In
addition, S-HTTP services should be usable to protect client-proxy ...
... When an S-HTTP aware proxy receives a request (HTTP or S-HTTP) that
(by whatever access control ...
... HTTP aware proxy receives a request (HTTP or S-HTTP) that
(by whatever access control rules it uses) it requires to be S-HTTP ...
... HTTP) that
(by whatever access control rules it uses) it requires to be S-HTTP
authenticated (and if it isn't already so), it should return the 422
response ...
...
We present below a summary of the main syntactic features of S-
HTTP/1.4, excluding message encapsulation proper.
...
...
Secure * Secure-HTTP/1.4
...
...
Secure-HTTP/1.4 200 OK
SecurityRetry 420
BogusHeader 421 <reason>
...
...
We provide here a contrived example of a series of S-HTTP requests
and replies. Rows of equal signs are used to set off the narrative
from sample message traces ...
... bodies of the requests have been base64 encoded. To regenerate actual
S-HTTP messages, it is necessary to remove the base64 encoding from
...
...
Alice, using an S-HTTP-capable client, begins by making an HTTP
request which yields the following response page:
...
... Alice, using an S-HTTP-capable client, begins by making an HTTP
request which yields the following response page:
============================================================
...
...
============================================================
200 OK HTTP/1.0
Server-Name: Navaho-0.1.3.3alpha
Certificate ...
... ============================================================
An appropriate HTTP request to dereference this URL would be:
...
...
============================================================
GET /secret HTTP/1.0
Security-Scheme: S-HTTP ...
...
The added Key-Assign line that would not have been in an ordinary
HTTP request permits Bob (the server) to encrypt his reply to Alice,
even though Alice does not have a public key ...
... public key, since they would share
a key after the request is received by Bob. This request has the
following S-HTTP encapsulation:
...
...
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
...
... ready to serve it back to Alice.
An appropriate HTTP server response would be:
============================================================
...
...
============================================================
HTTP/1.0 200 OK
Security-Scheme: S-HTTP ...
... ============================================================
This HTTP response, encapsulated as an S-HTTP message becomes:
...
... This HTTP response, encapsulated as an S-HTTP message becomes:
============================================================
...
...
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
...
... link on the HTML page that was just returned, which Alice
dereferences, creating the HTTP message:
============================================================
...
...
============================================================
GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
...
... GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
...
...
Which, when encapsulated as an S-HTTP message, becomes:
============================================================
...
...
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
MAC ...
... CMS is only one of two encapsulation formats supported by S-HTTP, but
it is to be preferred since it permits the least restricted set of
negotiable options, and permits binary encoding ...
...
In addition to defining the S-HTTP/1.4 protocol, this document serves
as the specification for the Internet media type ...
...
version: The S-HTTP version number of the enclosed message
(e.g. "1.4"). If not present, the version ...
... Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2616draft, June 1999. ...
... Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617draft, June 1999. ...