HTTPsec operates within the framework of the HTTP authentication headers. It uses RSA public keys for mutual authentication, and ephemeral Diffie-Hellman key exchange to ensure forward secrecy. The protocol provides mutual authentication and message origin authentication, via protection applied to (1) the integrity of URL, Method, and core HTTP headers, (2) the integrity of the message body, (3) message sequence, and (4) message replays. It optionally provides message body encryption. It does not provide header confidentiality (as messages would no longer be HTTP if their header fields were encrypted) or integrity protection applied to secondary headers (which may be legitimately altered by proxies).
(Many details are omitted - refer to the full specifications for a complete explanation.)
The terms "requester" and "responder" are used in place of "client" and "server" for the two peers in the transaction. This is to acknowledge that the peers that are being authenticated do not necessarily map one-to-one to client or server devices. For example, a server may host multiple endpoints that are distinctly identified.
There are three possible types of transaction: Initialisation, Continuation, and Challenge.
Initialization transactions occur when a requester wishes to initiate a new shared-secret agreement. They are for protocol purposes only and are thus not used to carry message payloads.
The responder is authenticated in the initialization stage, by the validating the signature against the public key presented by its certificate (authentication freshness is ensured by the requester's nonce). The requester is subsequently authenticated in the continuation stage by the use of HMAC message authentication codes (authentication freshness is ensured by the requester's ability to decrypt the responders's nonce).
The Diffie-Hellman values are used to generate an ephemeral shared secret. From this temporary secret keys are derived identically by both peers. In the initialise response, a token is also returned to reference these secret keys in subsequent continuation messages.
Example initialization request:
HEAD http://alice.example.com/foobar.txt HTTP/1.1 Authorization: httpsec/1.0 initializeExample initialization response:id=bob.example.comdh=clW9y2X5Vy+5+Ncv5lAI3W9y2X5Vgfe4y+5+Ncv5l...certificate=http://bob.example.com/my-certurl=http://alice.example.com/foobar.txtgroup=rfc3526#14nonce=7iqgkzgfdIe0HN35r6met2579yxetyerty7MZW...
HTTP/1.1 401 Authorization Required Expires: Thu, 11 Aug 2005 18:20:42 GMT Cache-Control: no-transform WWW-Authenticate: httpsec/1.0 initializeid=alice.example.comdh=+NcclW9y2I3W9X5Vy+5v5lAy4X56y+Ncrwrtv5lqe...certificate=http://alice.example.com/my-certtoken=mCa5tx1vKBYauth=vpCNmx7MZ7iqgkzIe0HWwfyrOMeqwg0TdbpwefI...signature=2pX3SNgzWkV3w0W9y2X5V23hhy+5b8DQmo...
(For legibility, the example protocol headers are extended over multiple lines, as per [4.2]. Additionally, the values of some initialization directives are lengthy and have therefore been abbreviated, indicated by a terminating ellipsis "...")
These transactions benefit from security protections that derive from a shared-secret agreement. They are in all other respects conventional HTTP messages. Continuation transactions can be employed if the requester has at a previous point initialised a shared-secret agreement.
Example of a continuation request:
GET http://alice.example.com/foobar.txt HTTP/1.1 Authorization: httpsec/1.0 continueExample of a continuation response:token=mCa5tx1vKBYurl=http://alice.example.com/foobar.txtcount=1mac=zhHPRbxqf3KSMQpjCnpDQmyBnoqiNDMQLjRtMjxUcM=
HTTP/1.1 200 OK Date: Thu, 11 Aug 2005 18:20:48 GMT Expires: Thu, 11 Aug 2005 18:20:48 GMT Content-Type: text/plain;charset=ISO-8859-1 Content-Length: 1234 Cache-Control: no-transform Content-Encoding: x-httpsec/1.0-cipher WWW-Authenticate: httpsec/1.0 continuecount=2mac=VplDHX3SNgzWkLKgZkjZ+I5wvImOHAMptVSc/Abttps=digest=V3w0W9y2X5Vy+5+Ncv5lAI3rb8qMlGzrOh9zjHXRHbk=
<entity-body ciphertext bytes>
Note that whilst the sample Continuation request is has a GET method and therefore no body, it could equally be a POST, PUT, etc with a message body and have the same message body protection as shown in the example Continuation response.
These transactions allow a responder to attempt to initiate HTTPsec.
Example of a challenge response:
HTTP/1.1 401 Unauthorized WWW-Authenticate: httpsec/1.0 challengeid=alice.example.comcertificate=http://alice.example.com/my-cert