An Overview of SHTTP

Adam Shostack, May 1995

A. Introduction to, and history of, S-HTTP

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, although implementation details are sketchy.

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.

I'll be discussing the message format, the negotiation of options, and the formatting of messages, as well as retry behavior, interaction with older servers, and implementation details. All of this is well covered in draft-rescorla-shttp-*, available wherever fine Internet drafts are stored.

B. The protocol

A Secure HTTP message is a request or status line, followed by other headers (which must be RFC-822 compliant), and some content. The content can be raw data, a Secure HTTP message, or an HTTP message. The request line is defined as


	Secure * Secure-HTTP/1.1 to which the response must be:
	Secure-HTTP/1.1 200 OK

These lines are defined to preclude an attacker from seeing the success or failure of a given request. Secure HTTP takes a generally paranoid attitude to all information, leaking as little as possible.

1. Headers

There are few headers that should go in the Secure HTTP header. There are other headers which go into an HTTP header, which is encapsulated within the S-HTTP message. Those headers are defined in S-HTTP, but are used as headers in the HTTP document, i.e., they cannot be used without being protected by an S-HTTP encapsulation.

Content-Privacy-Domain is for compatibility with PEM based secure HTTP. Options are RSA's PKCS-7 (Public Key Cryptography Standard 7, "Cryptographic Message Syntax Standard"), RFC-1421 style PEM, and PGP 2.6 format.

Content-Transfer-Encoding explains how the content of the message is encoded. 7, 8 bit are self explanatory, base-64 is as defined in RFC-1421.

Content-Type is a standard header, and should generally be application/http.

Prearranged-Key-Info is information about the keys used in the encapsulation of this message. Fields are for the type of cipher, a DEK (data exchange key) used to encrypt this message, and the identity of the key used to encrypt the DEK. MAC-Info is a message authentication code to ensure that a message has not been tampered with, without the expense of signatures.

These are the only Secure HTTP headers defined in the spec. However, there are also a number of new HTTP headers defined. Those are Security Scheme, encryption identity, DN-1485 Name class, Kerberos Name class, Certificate Info, Key Assign, and Nonces.

Security Scheme is a holds the protocol name and version. Encryption Identity names the entity for which a message is encrypted, say in the case of a server with multiple public keys. The name class options (DN-1485 and Kerberos) allow entities to say how they identify themselves, and who they are.

Certificate Info lines allow a sender to send a public key certificate in a message with other purposes, saving the trouble of a separate explicit certificate retrieval.

Key assign is the message used for actual key exchanges, and assignment of symbolic names to exchanged keys. Key exchange has many options, allowing keys to be encapsulated in various ways, given symbolic names, and have lifetimes assigned to them. Lifetimes can be 'this' meaning the key is good for this message, or 'reply' meaning the key can be used for a reply (possibly several replies) to this message.

Nonce(s) are session identifiers, used to indicate the freshness of a session, and preclude replay attacks. A message may include a number of nonces, from zero to several. The server will often generate them, and expect a client to respond with the same nonce. Nonces are often time based, but Secure HTTP suggests that a random value may be used. (Cryptographically strong random numbers are difficult to generate, however, it seems that the nonce need not be very strong.)

2. Negotiation

To offer flexibility in the cryptographic enhancements used, client and server negotiate about what enhancements each is willing to use, unwilling to use, or will require be used. Negotiations blocks have four parts, property, value, direction (always with respect to the negotiator), and strength (of preference). If agents are unable to discover a common set of algorithms, appropriate actions should be taken. Continuing to request a refused option is considered ineffectual and inappropriate.


	An example negotiation line would be:
	SHTTP-Key-Exchange-Algorithms: recv-required=RSA,Kerb-5

To mean that messages to this machine must use Kerberos 5 or RSA encryption to exchange keys.

The modes available are (recv||orig)-(optional||required||refused). The keywords 'recv' and 'orig' indicate receive or originate, respectively. Variable key length ciphers are referred to as cipher[length], or cipher[L1-L2], where length of key is length, or in the case of L1-L2, is between L1 and L2, inclusive. Cipher without a length notation shall indicate a willingness to accept any defined key length for a cipher.

	Headers in the negotiation can be:

	SHTTP-Privacy-Domains:
	SHTTP-Certificate-Types:
	SHTTP-Key-Exchange-Algorithms:
	SHTTP-Signature-Algorithms:
	SHTTP-Message-Digest-Algorithms:
	SHTTP-Symmetric-Content-Algorithms:
	SHTTP-Symmetric-Header-Algorithms:
	SHTTP-Privacy-Enhancements:
	Your-Key-Pattern:

SHTTP-Privacy-Domains can be PEM, PKCS-7, or PGP.

SHTTP-Certificate-Types: can be extended form PKCS-6, or X.509. This is strongly related to, but not dependent on, SHHTP-Privacy- Domains.

SHTTP-Key-Exchange-Algorithms: can be Outband, Inband, RSA, or Krb-kv (for Kerberos-version). Outband refers to any external, or prearranged key. For the situation of only a server having a key, and not expecting the client to have any key, the message is: SHTTP-Key-Exchange-Algorithms:orig-optional=Inband, RSA; recv-required=RSA

SHTTP-Message-Digest-Algorithms: Can be 'RSA-MD2,' 'RSA-MD5,' or 'NIST-SHS.'

SHTTP-Symmetric-Content-Algorithms: Can be any of 
DES-CBC		DES in Cipher Block Chaining (CBC) mode (FIPS 81) [11])
DES-EDE-CBC	2 Key 3DES using Encrypt-Decrypt-Encrypt in CBC mode
DES-EDE3-CBC	3 Key 3DES using Encrypt-Decrypt-Encrypt in CBC mode
DESX-CBC		RSA's DESX in CBC mode
IDEA-CFB		IDEA in Cipher Feedback Mode [12]
RC2-CBC		RSA's RC2 in CBC mode
RC4			RSA's RC4
CDMF-CBC		IBM's CDMF (weakened key DES) [20] in CBC mode

For a good overview of all these ciphers, except RC4, DESX and CDMF, see (Schneier, 1994). RC4 was a secret algorithm until it was posted to Cypherpunks in October 1994, where some discussion took place (see Cypherpunks Archive). DESX is a slightly strengthened version of DES. CDMF is a DES-like cipher with a 40 bit real keyspace.

	SHTTP-Symmetric-Header-Algorithms: Can be any of
DES-ECB		DES in Electronic Codebook (ECB) mode (FIPS 81 [11])
DES-EDE-ECB	2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode
DES-EDE3-ECB	3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB 
mode
DESX-ECB	RSA's DESX in ECB mode
IDEA-ECB	IDEA
RC2-ECB		RSA's RC2 in ECB mode
CDMF-ECB	IBM's CDMF in ECB mode

A discussion cipher modes is beyond the scope of this paper, but can be found in (FIPS 81) or (Schneier, 1994, chapter 8). Again, CDMF and DESX are questionable algorithms, but the authors chose to allow flexibility. (Matt Blaze & Carl Ellison both provided useful overviews of CMDF & DESX here about 3 weeks back. Thanks again!)

SHTTP-Privacy-Enhancements: Can be any or all of 'sign,' 'encrypt,' or 'auth.' Auth differs from sign in that auth provides a keyed hash of the message in a MAC, while sign provides a digital signature.

Your-Key-Pattern: is a way to tell the other party what keys to use within the options negotiated. There are many options & possibilities. For a complete list refer to the Rescorla draft, which concludes this section with:

For example, to request that the other agent sign with a key certified by the RSA Persona CA (which uses name subordination) one could use the expression below. Note the use of RFC-1485 quoting to protect the comma (an RFC-1485 field separator) and the ed-style quoting to protect the dot (an ed metacharacter).

	  Your-Key-Pattern: DN-1485,
     /OU=Persona Certificate, O="RSA Data Security, Inc\."/

Secure HTTP defines defaults for all these values. Those defaults may be negotiated upwards or downwards, and are: To use PKCS-7 or PEM to encode messages; to exchange keys, and sign messages using RSA. MD5 is used as the message digest, and (single) DES, in various modes, is used as the bulk cipher.

3. Message Format Options

The format of the body of a message is indicated by the Content-Privacy-Domain SHTTP header line. There are several acceptable Content-Privacy-Domains, which are PEM, PGP, and PKCS- 7. Under PKCS-7, the most interesting option is a self signed signature certificate in a message body. This is permitted, and no assertions are made to its reliability. This allows implementors a great deal of flexibility. Other PKCS-7 options include encryption (with a public key, or some prearranged set). Using a domain of PEM or PGP, the messages are encoded with 'straight' PGP or PEM . With some minor header changes, the original HTTP access authorization protocols can be made compatible with the PEM format.

4. Error Conditions and Retry Behavior

Not all errors in Secure HTTP result in connections being closed. Some will require a new attempt, with different options. The 3XX set of redirection codes provides the building blocks on which to perform redirection. Clients must interpret server messages to decide on the appropriateness of a retry. The client should possibly communicate with the user to determine what the appropriate action is.

There are a number of specific sets of actions which responses might suggest. The HTTP responses "Unauthorized 401" could be a failure of authentication, while "PaymentRequired 402" has obvious meanings. The behaviors in these cases are not specified by Secure HTTP, but the actions leading to them might be performed in a privacy enhanced session.

A "SecurityRetry 420" message indicates that the cryptographic options in use are insufficient, and suggests that an option re- negotiation might be in order. If the message was sent under S- HTTP, the response will indicate what options are desired (or demanded). This can force a new public key negotiation, or offer a new nonce for freshness. If the 420 message is received under HTTP, it indicates that an S-HTTP message should be sent. The parameters desired are included in the response.

There are limits placed on automatic retries, because of attacks possible with HTTP. The client is only allowed if the server requesting the retry already has the information. Some acceptable times to retry include:

The retry response was returned encrypted under an inband key freshly generated for the original request.
The retry response was signed by the intended recipient of the original request.
The original request used an outband key and the response is encrypted under that key.

The authors, appropriately, urge caution in choosing when to automatically respond to a re-encryption request. They also prohibit automatic re-trying a signature, and allow for automatic retrying of a MAC authentication failure.

5.Older servers

There are several issues that can occur when a client and server do not both support S-HTTP, or when they support different versions of the protocol. If the client doesn't send a message with the appropriate security enhancements, the server should respond with a "Unauthorized 401" message. In addition, the protocol defines a new URL protocol designator, 'shttp.' Since a client won't know how to dereference this URL, they will not come in contact with this problem.

6. Other details

S-HTTP uses a protocol specifier of "SHHTP." It supported by Secure Mosaic, from EIT. No reference version is available today.

C. The threats

Threats to S-HTTP are similar to those against SSL. However, the more general nature of S-HTTP make it difficult to assess exactly what is possible.

In the case of a hacker, or looker, the attack on a CA may be more difficult, due to the existence of multiple CAs. A key could theoretically be verified by several CAs, making an attack infeasible.

Insiders have similar options, but an expanded ability to wreak havoc within an HTML document.

D. The protections offered

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.

In addition, the cost of clear text cryptanalysis of DES is substantially higher than that of RC4-40. (Recall that DES is the default cipher for S-HTTP, and RC4-40 is the default cipher for SSL.) To break an RC4-40 key in about month costs about $125. To break a DES key in one month costs about $10,000 (extrapolated from Wiener, 1994)

A 56 bit DES key costs one million dollars to break in 7 hours. (Wiener, 1994) This cost scales up and down in a linear fashion. (I.E., a 1/2 million dollar machine will take 14 hours). A month has 720 hours (24 hours x 30 days), which is 102 periods of 7 hours. The cost of breaking DES in roughly one month is thus about $10 000, as opposed to $125 for 40 bit RC4.

E. Weaknesses

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.

S-HTTP, in being flexible, may offer a programmer enough rope to hang themselves. Admittedly, it does not offer very many broken options, but it doesn't seem to have anything like SSL's "Encrypt everything and don't sweat it" attitude. A programmer, especially one not familiar with issues of security and cryptography, could think "Using S-HTTP will protect me" and totally fail to provide any cryptographic protections for his information. The likelihood of this happening may be open to question, but the problem is worth considering.