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.
Secure * Secure-HTTP/1.1 to which the response must be: Secure-HTTP/1.1 200 OKThese 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.
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.)
An example negotiation line would be: SHTTP-Key-Exchange-Algorithms: recv-required=RSA,Kerb-5To 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) ) 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  RC2-CBC RSA's RC2 in CBC mode RC4 RSA's RC4 CDMF-CBC IBM's CDMF (weakened key DES)  in CBC modeFor 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 ) 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 modeA 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.
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:
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.
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.
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.