99designs / http-signatures-php Goto Github PK

Currently, many error conditions are thrown as Exception.
Instead they should be made more specific, all inheriting from a central library-specific base exception.
See https://github.com/99designs/http-signatures-ruby for reference.

Hi, I'm @msporny, primary author of the HTTP Signatures specification at IETF for many years now. You've implemented some variation of that specification.

I need your help to move that specification towards a global standard at IETF. Hearing from implementers, such as you, is a big part of determining if the work toward a global standard should proceed. The IETF HTTP Working Group is determining whether the work should proceed right now. This is very good news, because the European Banking API community, W3C DID Working Group, W3C Credentials Community Group and other standards setting organizations depend on implementations standardizing on a way to do HTTP Signatures.

The deadline for noting your support is Jan 31st 2020 (in ~10 days).

Here's where you can make a difference...

Here is the IETF HTTP WG Call for Adoption:

https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html

To note your support of the specification:

1. Go here and click "subscribe to this list": https://lists.w3.org/Archives/Public/ietf-http-wg/
2. Verify your subscription by checking your email and clicking on the link that is mailed to you.
3. Go here and click "respond to this message": https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html
4. Write an email stating:
   4.1 That you support the adoption of the draft.
   4.2 Why you support the adoption of the draft.
   4.3 How you plan to make use the specification, either directly, or indirectly (via someone else's software).
5. Set up an email filter to put all mail sent to [email protected] into its own folder. The mailing list averages ~350 emails/month. You can also leave the mailing list immediately after sending the email above if that amount of email traffic is unacceptable to you.

For an example of the type of email you could write, see this:

https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0018.html

Thanks a ton for supporting the specification through your implementation. I hope you consider helping us take the specification across the goal line by voicing your support in the IETF HTTP Working Group!

Need to enhance the Digest creation/validation functions to account for multiple digests in a single header. Will work on an implementation and submit PR shortly.

See #28 for what prompted this.

We're currently using a double HMAC approach for signature comparison, as that was the only way for us to securely compare HMAC signatures without making it a breaking change, as the hash_equals function we need isn't available until PHP 5.7, and we support PHP 5.5+

When we roll out our next major version we should increase the minimum PHP version to 5.7 or higher, and swap to using hash_equals.

These two headers have different meanings and intentions, and it may not be safe to simply issue both for all requests.
PR #36 implements separate sign and authorize methods to generate these headers individually.

Specification allows messages to omit the "headers" signature parameter, requiring signers and validators to use the implicit value date instead. Presently this library cannot handle this.

Implemented in PR #42

The Signing HTTP Messages draft standard illustrates how to include other headers, specifically including the Digest header in the signature string. Very many sites using HTTP Signatures now incorporates this technique as standard (a good thing).

#38 adds the public function signWithDigest($message) that calls private function addDigest($message) to:

• automatically compute a base64-formatted hash for the message body so the user doesn't need to do more crypto stuff 😄
• add the Digest header to the request with the hash of the body (replacing an existing header if necessary) and send it off to the sign($message) function
• include the digest header in the HeaderList string of the Signature/Authorize header
• call the standard sign($message) once digest operations are done and return the message with a correct digest header

It looks like this library currently only supports HMAC signing. It would be great if it also supported RSA signing with a private key!

Issue

Recently, we used this library in Projects for signing requests to external apis within the contests stack. It was slightly confusing to begin with, as currently this library is designed to use Symfony's HttpFoundation\Request class for both signing and verifying messages.

The Symfony Request class is supposed to be used as a representation of the request that is coming into your Symfony/Silex/etc stack, rather than being a request sent to another stack.

This doesn't fit very well for the use case of making requests between services, as this is generally done using Guzzle, which has its own class for representing the request it will send.

Current Solution

To get around this issue, I manually created and signed a Symfony Request and then used its headers as arguments to the Guzzle request when creating it.

This code can be seen in our ContestsApiClient here

Ideal Solution

This library should be able to sign a Guzzle request

$request = $guzzleClient->createRequest($method, $url, [
    'Date' => 'Wed, 30 Jul 2014 16:40:19 -0700',
    'Accept' => 'llamas',
]);
$context->signer()->sign($request);

The server should be able to require the client to sign certain headers, and reject any messages in which these headers are unsigned.
For example, a server should be able to require a signed digest header for POST requests, and reject any message that doesn't have a signed digest header.

This protects against sloppy clients "leaving the door open": if a POST request with an unsigned digest is intercepted, the message body can be manipulated without invalidating the signature, and the forged message would be accepted.

This could be prevented by supplying a list of required headers to the constructors of the Verifier and Verification classes.
It might be useful to supply two sets of headers, one for requests without a body, and another for messages with a body. (Note that DELETE requests may or may not have a body).

For reference: https://datatracker.ietf.org/doc/html/rfc9421#verify-requirements

@mtibben says:

@pda: you may want to consider using PSR7 Request rather than Symfony Requests for that lib

http://www.php-fig.org/psr/psr-7/

That PSR-7 page describes a Psr\Http\Message\RequestInterface. Maybe worth noting it also says:

An HTTP client MUST ignore the values of Uri::getPath() and Uri::getQuery(), and instead use the value returned by getRequestTarget(), which defaults to concatenating these two values.

Also, I regret not wrapping whatever request object in a locally-defined interface, making issues like #8 much harder to solve. So a breaking change version of this library would probably introduce a new Message interface with a SymfonyReqestMessage and PSR7RequestMessage implementation.

The latest version of the spec is quite a bit different:

• https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-08.html
• https://httpsig.org/

I'm trying to use this with a js library (https://github.com/dhensby/node-http-message-signatures/), but can't since the specs don't agree.

I can try to work on a PR if I have time, but wanted to check in and see if this project was still maintained and if you'd be open to supporting the newer spec.

Copied from 99designs/http-signatures-ruby#10

Currently key rotation is difficult; the verifier needs to start verifying with the new key at the same moment the new key is used by the signer. In a high-traffic environment this can be near impossible without dropping requests.

It should be possible to pass multiple keys to the verifier, so that both old and new keys can be accepted for a period of time. Either N keys, or a static limit of two keys (current and previous) would work.

This could be represented by passing an array of keys per ID; using the first for signing, and using all of them for verification. Or… something else?