'''HTTPsec''' ("'''HTTP security'''") is an Authentication scheme for the web protocol HTTP. HTTPsec provides cryptographically strong security at the Application_layer. HTTPsec is a proposal by Secarta.
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).
== Example with explanation ==
(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'''
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 requester sends its identifier, RSA public key, and an ephemeral Diffie-Hellman public value, and a random nonce.
* The responder responds with its identifier, RSA public key, an ephemeral Diffie-Hellman public value, and a separate random nonce encrypted in the requester's' RSA public key. It also signs with its RSA private key all the protocol parameters so far exchanged.
The responder is authenticated in the initialization stage by the signature (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 subsequently continuation messages.
Example initialization request:
HEAD http://alice.example.com/foobar.txt HTTP/1.1
Authorization: httpsec/1.0 initialize
id=bob.example.com
dh=clW9y2X5Vy+5+Ncv5lAI3W9y2X5Vgfe4y+5+Ncv5l...
certificate=http://bob.example.com/my-cert
url=http://alice.example.com/foobar.txt
group=rfc3526#14
nonce=7iqgkzgfdIe0HN35r6met2579yxetyerty7MZW...
Example initialization response:
HTTP/1.1 401 Authorization Required
Expires: Thu, 11 Aug 2005 18:20:42 GMT
Cache-Control: no-transform
WWW-Authenticate: httpsec/1.0 initialize
id=alice.example.com
dh=+NcclW9y2I3W9X5Vy+5v5lAy4X56y+Ncrwrtv5lqe...
certificate=http://alice.example.com/my-cert
token=mCa5tx1vKBY
auth=vpCNmx7MZ7iqgkzIe0HWwfyrOMeqwg0TdbpwefI...
signature=2pX3SNgzWkV3w0W9y2X5V23hhy+5b8DQmo...
(For legibility, the example protocol headers are extended over multiple lines, as per [HTTP][4.2]. Additionally, the values of some initialization directives are lengthy and have therefore been abbreviated, indicated by a terminating ellipsis "...")
'''Continuation Transactions'''
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.
* The requester and responder send a sequence of arbitrary HTTP messages, quoting the token as a reference to the secret keys employed.
* The secret keys are inputs to message authentication codes and message body Encryption. As the keys are only known by the two legitimate peers, they are used by the message-receiving peer to validate the message-sending peer, and to decrypt the message body. Additionally, message uniqueness is enforced by an incrementing counter, which is one of various inputs to the message's MAC.
Example of a continuation request:
GET http://alice.example.com/foobar.txt HTTP/1.1
Authorization: httpsec/1.0 continue
token=mCa5tx1vKBY
url=http://alice.example.com/foobar.txt
count=1
mac=zhHPRbxqf3KSMQpjCnpDQmyBnoqiNDMQLjRtMjxUcM=
Example of a continuation response:
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 continue
count=2
mac=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.
'''Challenge Transactions'''
These transactions allow a responder to attempt to initiate HTTPsec.
* The requester asks for a resource, in a conventional HTTP request.
* The responder answers with a "401 Unauthorized" response, and states its support for HTTPsec.
Example of a challenge response:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: httpsec/1.0 challenge
id=alice.example.com
certificate=http://alice.example.com/my-cert
'''Algorithms'''
The algorithms employed by HTTPsec are RSA, OAEP, PSS, HMAC, SHA-256, and AES-256. The protocol does not allow algorithm negotiation.
== External links ==
* httpsec.com - HTTPsec specification
Category:HTTP
Category:Internet_protocols
Category:Cryptographic_protocols