Code Monkey home page Code Monkey logo

httpsig's Introduction

httpsig

HTTP Signatures made simple

Build Status Go Reference Go Report Card License Chat OpenCollective

go get github.com/go-fed/httpsig

Implementation of HTTP Signatures.

Supports many different combinations of MAC, HMAC signing of hash, or RSA signing of hash schemes. Its goals are:

  • Have a very simple interface for signing and validating
  • Support a variety of signing algorithms and combinations
  • Support setting either headers (Authorization or Signature)
  • Remaining flexible with headers included in the signing string
  • Support both HTTP requests and responses
  • Explicitly not support known-cryptographically weak algorithms
  • Support automatic signing and validating Digest headers

How to use

import "github.com/go-fed/httpsig"

Signing

Signing a request or response requires creating a new Signer and using it:

func sign(privateKey crypto.PrivateKey, pubKeyId string, r *http.Request) error {
	prefs := []httpsig.Algorithm{httpsig.RSA_SHA512, httpsig.RSA_SHA256}
	digestAlgorithm := DigestSha256
	// The "Date" and "Digest" headers must already be set on r, as well as r.URL.
	headersToSign := []string{httpsig.RequestTarget, "date", "digest"}
	signer, chosenAlgo, err := httpsig.NewSigner(prefs, digestAlgorithm, headersToSign, httpsig.Signature)
	if err != nil {
		return err
	}
	// To sign the digest, we need to give the signer a copy of the body...
	// ...but it is optional, no digest will be signed if given "nil"
	body := ...
	// If r were a http.ResponseWriter, call SignResponse instead.
	return signer.SignRequest(privateKey, pubKeyId, r, body)
}

Signers are not safe for concurrent use by goroutines, so be sure to guard access:

type server struct {
	signer httpsig.Signer
	mu *sync.Mutex
}

func (s *server) handlerFunc(w http.ResponseWriter, r *http.Request) {
	privateKey := ...
	pubKeyId := ...
	// Set headers and such on w
	s.mu.Lock()
	defer s.mu.Unlock()
	// To sign the digest, we need to give the signer a copy of the response body...
	// ...but it is optional, no digest will be signed if given "nil"
	body := ...
	err := s.signer.SignResponse(privateKey, pubKeyId, w, body)
	if err != nil {
		...
	}
	...
}

The pubKeyId will be used at verification time.

Verifying

Verifying requires an application to use the pubKeyId to both retrieve the key needed for verification as well as determine the algorithm to use. Use a Verifier:

func verify(r *http.Request) error {
	verifier, err := httpsig.NewVerifier(r)
	if err != nil {
		return err
	}
	pubKeyId := verifier.KeyId()
	var algo httpsig.Algorithm = ...
	var pubKey crypto.PublicKey = ...
	// The verifier will verify the Digest in addition to the HTTP signature
	return verifier.Verify(pubKey, algo)
}

Verifiers are not safe for concurrent use by goroutines, but since they are constructed on a per-request or per-response basis it should not be a common restriction.

httpsig's People

Contributors

42wim avatar blacktemplar avatar cjslep avatar ejain avatar ewilde avatar yukimochi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

httpsig's Issues

Bump version

Hi, I used this with a go modules project and by default it sets the version to v0.1.0, which seems to be old.
Would it be possible to bump the version to v0.1.1 or something?

Sample code?

Hi,
I have not been able to figure out how to use this library, even from the code in the README.md. I also cannot find any examples on Github. Can you please provide a short example from start to finish?

Signature verification : Digest should be calculated upfront using the body

At the time of verification, we use the value of digest header(if required) for verifying signature.
This opens a gate to the attackers. Suppose someone was able to tamper with the request/response body without touching any of the headers, signature verification will still be OK because we are using the digest header sent for the verification purpose.

To prevent such attack , we should
Either,
i) recalculate the 'digest' to be used in signature verification.
Or,
ii)Compare the[ 'digest' header value] with the [re-calculated 'digest' from body] , if the signature calculation method for verification remains as is.

Make showing algo configurable?

This commit 221cfc4
hides the algo from the receiver.

I'm integrating against apis that don't expect this.
Are we open for making this behaviour configurable?

Support for newer HTTPBIS message digest headers

Existing, deprecated header style:
Digest: SHA256=abc,SHA512=xyz

Newer, IETF HTTPBIS (RFC track) header style:
Content-Digest: SHA256=:abc:,SHA512=:xyz:

The difference is that the header key is changed, and the base64 values are enclosed with colons (per Structured Headers).

Would be nice if we could have an option to use the newer header style.

Support ECDSA encryption

At the moment the only asymmetric encryption supported is RSA, we should also support ECDSA encryption.

Authorization header should begin with `Signature`

Try to validate signatures generated by httpsig, with other languages i.e.: https://github.com/joyent/node-http-signature.

It appears that httpsig does not add the Signature value at the beginning of the header. According to the Signing HTTP Messages draft-cavage-http-signatures-10

Draft example

 Authorization: Signature keyId="rsa-key-1",algorithm="rsa-sha256",
   headers="(request-target) host date digest content-length",
   signature="Base64(RSA-SHA256(signing string))"

Http sig

Authorization: keyId="pubKeyId",algorithm="rsa-sha512",headers="date digest",signature="Base64(RSA-SHA256(signing string))"

(request-target) should use path instead of URL

Description

Currently the (request-target) header is using URL; however it should according to the spec use the path

If the header field name is (request-target) then generate the header field value by concatenating the lowercased :method, an ASCII space, and the :path pseudo-headers (as specified in HTTP/2, Section 8.1.2.3 [7]). Note: For the avoidance of doubt, lowercasing only applies to the :method pseudo-header and not to the :path pseudo-header.

So currently:

(request-target): post http://example.com/foo

Should be:

(request-target): post foo

Voice implementer support for HTTP Signatures in IETF HTTP WG

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!

c++ counterpart

motivation

I've been using a go project sending to another go project which worked great!

Now I need to send the request from a c++ client, anyone can recommend a library for this?

Integrate with vgo

Make this package compatible with golang's proposed semantic versioning package manager.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.