GithubHelp home page GithubHelp logo

tritondatacenter / node-http-signature Goto Github PK

View Code? Open in Web Editor NEW
403.0 59.0 122.0 210 KB

Reference implementation of Joyent's HTTP Signature Scheme

Home Page: https://tritondatacenter.com

License: MIT License

Emacs Lisp 0.16% Makefile 12.16% JavaScript 87.68%

node-http-signature's Introduction

node-http-signature

node-http-signature is a node.js library that has client and server components for Joyent's HTTP Signature Scheme.

Usage

Note the example below signs a request with the same key/cert used to start an HTTP server. This is almost certainly not what you actually want, but is just used to illustrate the API calls; you will need to provide your own key management in addition to this library.

Client

var fs = require('fs');
var https = require('https');
var httpSignature = require('http-signature');

var key = fs.readFileSync('./key.pem', 'ascii');

var options = {
  host: 'localhost',
  port: 8443,
  path: '/',
  method: 'GET',
  headers: {}
};

// Adds a 'Date' header in, signs it, and adds the
// 'Authorization' header in.
var req = https.request(options, function(res) {
  console.log(res.statusCode);
});


httpSignature.sign(req, {
  key: key,
  keyId: './cert.pem',
  keyPassphrase: 'secret' // (optional)
});

req.end();

Server

var fs = require('fs');
var https = require('https');
var httpSignature = require('http-signature');

var options = {
  key: fs.readFileSync('./key.pem'),
  cert: fs.readFileSync('./cert.pem')
};

https.createServer(options, function (req, res) {
  var rc = 200;
  var parsed = httpSignature.parseRequest(req);
  var pub = fs.readFileSync(parsed.keyId, 'ascii');
  if (!httpSignature.verifySignature(parsed, pub))
    rc = 401;

  res.writeHead(rc);
  res.end();
}).listen(8443);

Installation

npm install http-signature

License

MIT.

Bugs

See https://github.com/joyent/node-http-signature/issues.

node-http-signature's People

Contributors

alokmenghrajani avatar antialias avatar arekinath avatar bahamas10 avatar bahamat avatar bbaia avatar blacktemplar avatar bsletten avatar davidlehn avatar dgwynne avatar dwlf avatar felix-n avatar jasonbking avatar jclulow avatar jharris4 avatar jmar777 avatar keiichihirobe avatar kilianc avatar krosenk729 avatar kusor avatar leipert avatar lizheming avatar max-mapper avatar mcavage avatar mwindle avatar pfmooney avatar ralphtheninja avatar raynos avatar travispaul avatar trentm 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  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  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

node-http-signature's Issues

Security hole: Header names must be included in the signature string

There's a security hole with this scheme. It looks like only the header values are signed, not the actual headers (their names) those values are associated with. That means that an attacker can change the meaning of a request by swapping various header values.

For example:

Original request:

POST /pay HTTP/1.1
Host: example.com
Date: Thu, 05 Jan 2012 21:31:40 GMT
X-Payment-Source: [email protected]
X-Payment-Destination: [email protected]
Authorization: Signature keyId="Test",algorithm="rsa-sha256",headers="x-payment-source x-payment-destination" MDyO5tSvin5...

Attacker captures the request and changes it to:

POST /pay HTTP/1.1
Host: example.com
Date: Thu, 05 Jan 2012 21:31:40 GMT
X-Payment-Source: [email protected]
X-Payment-Destination: [email protected]
Authorization: Signature keyId="Test",algorithm="rsa-sha256",headers="x-payment-destination x-payment-source" MDyO5tSvin5...

Note that the "X-Payment-Source" and "X-Payment-Destination" header values have been swapped and their order in the Authorization header have been swapped.

The resulting signature string in the original request will be:

The resulting signature string in the attacker's request will be:

So the signature will still be valid in the attacker's request, however, the attacker will have successfully reversed a financial transaction (in this contrived example).

A solution to this problem would be to include the header names in the signature. They should be normalized to lowercase, etc. If this change were made, the original request's signature string would be:

x-payment-source: [email protected]\n
x-payment-destination: [email protected]\n

And in the attacker's request:

x-payment-destination: [email protected]\n
x-payment-source: [email protected]\n

As you can see, the attack would fail here as the signature strings are different.

Crashing when using altered keys.

Working with the sample code, I tried changing a valid signing key and a valid verification key by 1 character. The change in the signing key crashed the client. The change in the verification key crashed the server. The following are the errors.

On client, when signing key was altered.

Error: error:0D07209B:asn1 encoding routines:ASN1_get_object:too long
    at Error (native)
    at Sign.sign (crypto.js:327:26)
    at Object.signRequest (/Users/garygriswold/node_modules/http-signature/lib/signer.js:166:26)
    at Object.<anonymous> (/Users/garygriswold/BibleApp/Server/www/DigitalSignatureClient.js:22:15)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)
    at startup (node.js:129:16)

On server, when validation key was altered.

Error: PEM_read_bio_PUBKEY failed
    at Error (native)
    at Verify.verify (crypto.js:356:23)
    at Object.verifySignature (/Users/garygriswold/node_modules/http-signature/lib/verify.js:31:19)
    at Server.<anonymous> (/Users/garygriswold/BibleApp/Server/www/DigitalSignatureServer.js:14:22)
    at Server.emit (events.js:110:17)
    at HTTPParser.parserOnIncoming [as onIncoming] (_http_server.js:491:12)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:111:23)
    at Socket.socketOnData (_http_server.js:343:22)
    at Socket.emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)

Fails to install with older versions of npm

The '^' specifier used in package.json is not available on versions of the semver module (used by npm) bundled with older versions of node (for example, 0.8.3). This will cause npm installs to fail with the following error:
npm ERR! Error: No compatible version found: assert-plus@'^0.1.5'

New release

It would be nice to get a new patch release so that downstream packages can take advantage of the new uuid fork, and stop getting warnings about the deprecated node-uuid dependency.

httpsig trusts the algorithm given by the client

Currently in verify.js we're trusting the algorithm passed in by the client and never verifying what sort of key we were given. This is a problem.

Let's imagine we parse the Authorization header and look at the keyId, then go into our database and get the key with that id. It turns out to be a string of bytes that looks something like -----BEGIN PUBLIC KEY-----\nMII..... We take this string of bytes and we give it to verifySignature. Note that at no point in this have we ever told node-http-signature that our string of bytes is an RSA key.

Now imagine verifySignature runs as normal. In line 31 (https://github.com/joyent/node-http-signature/blob/master/lib/verify.js#L31) it looks at the algorithm value which was entirely derived from whatever the client sent in their Authorization header. Normally this would say something like rsa-sha256, but let's imagine this time it says hmac-sha1. Now verifySignature will take the opaque string of bytes we gave it (the RSA public key) and HMAC the signing string with it and check that against the signature value and... oh dear. The public key isn't meant to be secret, is it? Now we're accepting requests from anyone who has the user's public key, without them needing the private half at all. Woops.

The only way I can see out of this is to make verifySignature take an algorithm argument with the key. And then verifySignature needs to make sure that it matches the parsed algorithm value. This should probably just be the first part of the algorithm string (ie, "rsa", "dsa" or "hmac").

verifyHMAC requires that the binary secret be a string

Right now verifyHMAC asserts that secret is a string. This secret is used for createHmac.

Hmac secrets work with binary data, so when a string is used that means it converts that to the utf8 binary representation of that text to use as the secret.

In comparison the Python library I used required that the secret be a binary type (bytes).

I think it would be fair for verifyHMAC to allow the secret to be a Buffer.

Any Go signing libs in the wild

Looking for a Go signing library, have you seen one? Looked around about, but wanted to check before I go about implementing myself.

Example use with restify?

Hi!
You can send example use this module with restify? I find in google but not found. Can you help-me?

Add "license" and "licenses" to package.json

Specifying your license in package.json makes it a lot easier for your users to find and comply with GNU Affero licenses.

Also giving licenses (an array of objects with type and url keys) helps users whose legal departments request both the license name and the text. See this example from async:

  "licenses": [{
    "type": "MIT",
    "url": "https://github.com/caolan/async/raw/master/LICENSE"
  }]

Though licenses isn't specified in the npm package.json spec, it is supported by the NPM site, as you'll see if you check async's NPM page.

Thanks!

EdDSA sign and verify

Making another run at #58

Here is a first draft of an implementation that uses the RequestSigner API as a patch to request: request/request@master...digitalbazaar:httpSign

I found that it was necessary to duplicate much of the code involved in generating the signing string. I hopeful that we can figure out a way to improve on this situation.

The show stopper at the moment is the lack of support for eddsa algorithm here: https://github.com/joyent/node-http-signature/blob/master/lib/utils.js#L13-L17

And there does not appear to be any support for custom verifiers which would allow one to validate an EdDSA signature. Even if one would roll their own verification code, there is still a need to specify the proper algorithm.

I'm hoping to start a conversation about how to make this module more extensible generally. Some goals:

  • a way to implement signers/verifiers that does not involve reimplementing header/signing string boilerplate in other libs
  • a way to extend the available signing/verification algorithms

Why EdDSA? Here's some informal benchmarking that shows that ed25519 signing is much faster that RSA 2048. https://github.com/digitalbazaar/crypto-bench

Will not parse pem files that have a passphrase - solution offered

I was trying to parse a passphrase that was encrypted using a password. When I tried passing in the passphrase attribute in with the rest of the other options, I still got the same error:

/Users/jdavies/getObj/node_modules/sshpk/lib/private-key.js:192
			throw (e);
			^
KeyEncryptedError: The PEM format key (unnamed) is encrypted (password-protected), and no passphrase was provided in `options`
    at Object.read (/Users/jdavies/getObj/node_modules/sshpk/lib/formats/pem.js:75:12)
    at Object.read (/Users/jdavies/getObj/node_modules/sshpk/lib/formats/auto.js:24:16)
    at Object.PrivateKey.parse [as parsePrivateKey] (/Users/jdavies/getObj/node_modules/sshpk/lib/private-key.js:185:27)
    at Object.signRequest (/Users/jdavies/getObj/node_modules/http-signature/lib/signer.js:362:21)
    at sign (/Users/jdavies/getObj/getObj.js:61:19)
    at getUser (/Users/jdavies/getObj/getObj.js:99:5)
    at Object.<anonymous> (/Users/jdavies/getObj/getObj.js:144:1)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)

Turns out that in the http-signature/lib/signer.js file that the 'passphrase' option is never checked for or propagated. Here is my hack that got this to work:

In signer.js:
At line 293 I inserted the following:
assert.optionalString(options.passphrase, 'options.passphrase');

At line 363 (formerly line 362) I modifed the line to the following to propagate the options object:
key = sshpk.parsePrivateKey(options.key, 'auto', options);

Obviously, hardcoding 'auto' for the format is not the correct approach, but it made the code work for me. Here is the command I used to generate my private key:
openssl genrsa -out ~/oci_api_key.pem -aes128 2048

the openssl tool required me to provide a passphrase. When I later tried to use the http-signature module, I came across this issue. I hope this helps.

parseRequest throws on time skew

This is a bit odd, because the parsing is actually successful is the verification that is off IMHO.

For example, if I want to attach the keyId to the error, I can't because I don't get the parsed object back.

Would a PR to change this behavior be accepted?

Thanks!

http-signature authorization is impossible via ajax request

Hello There,

I am using restify to implement an API layer. The client portion of the code that will consume this API is written in javascript as well (mostly), although not using node.

I am attempting to work through an implementation of Joyent's "HTTP Signature" Authorization header (and if this issue belongs there, my apologies, and please just let me know) and am unable to have restify succeed in parsing the authorization header without the Date header being present as well. I know from reading the docs, that the Date header is pretty much the only thing you actually need, so here comes my problem...

You cannot send a date header in an XMLHttpRequest from the client side (ie: in the browser)... Chrome says "Refused to set unsafe header 'Date'", and any attempts at working around this (for example by still including a UTC date format string that is sha-256 hashed and base64 encoded results in the following exception being returned as a response by restify:

{"code":"InvalidHeader","message":"Authorization header invalid: date was not in the request"}

My further research (http://www.w3.org/TR/XMLHttpRequest2/#the-setrequestheader-method) indicates that you cannot in fact expect to be able to set the Date header via an XMLHttpRequest.

With that said, my request would be to remove the limitation on requiring a date header, or provide some other sort of work around.

Thanks very much for your time

** Migrated from: restify/node-restify#204 **

Problem with sshpk dependency

My app is using node 0.8.28 and i use request package which depends on node-http-signature which depends on node-sshpk and because of new version of node-sshpk i can't build my app. It is because node-http-signature use ^1.7.0 version of sshpk, We should change it to 1.7.0 and everything will be fine.

move https://github.com/joyent/node-http-signature/blob/master/lib/util.js into it's own module?

Hi, would you consider moving ./lib/util.js into it's own module?
this is quite useful on it's own, independently of http-signature.

Moving it out will make more discoverable (more searches for convert SSH key to PEM will hit it) and modules that need that will be able to use that directly,
and won't have to review unrelated changes in http-signature.

If this was something else, i'd be inclined to refactor and republish this myself, but obviously the security of this particular module is much more important and It's not worth creating a fork just for the sake of a architectural style issue.

document how to create and verify signatures using openssl

While debugging #54, I spent a while trying to figure out the right openssl invocations, as well as the correct input formats. It would be helpful to have some documentation that describes what formats the various files should be in for creating and verifying http-signatures using the openssl tools.

Relatedly, it would be useful if there were a tool that takes some description of an HTTP request (either JSON or the actual HTTP headers or whatever) and a public key file and verifies the signature in the HTTP request using that public key.

Fails in webpack environments

Unfortunately the latest version fails to build in webpack environments, due to the following error:

define cannot be used indirect

This appears to be caused by introducing jsprim as a dependency in v1.0.0, which depends on a webpack-incompatible module.

shoud use `request.originalUrl` instead of `url` to fill up `request-target`?

https://github.com/joyent/node-http-signature/blob/523e7c5a3a081e046813f62ab182e294a08eaf0d/lib/parser.js#L266

express.js will overwrite req.url using app.use:

app.use('/first', anotherRouter)
anotherRouter.post('/second', verifySignature)

inside verifySignature the req param has the property url without the /first part of path so it fails.
I'm actually overwriting it to make it works:

req.url = '/first' + req.url
const parsed = httpSignature.parseRequest(req)

so the question: shoud we use originalUrl param instead?

Multiple header values not serialized properly per the spec

There are multiple places in this lib that do not serialize multiple header values according to the spec. The code assumes that the value of a header will be a string -- or, that if it is an array, that the default join will suffice. This is not the case -- the spec says (in Section 2.3. Signature String Construction):

If there are multiple instances of the same header field, all
header field values associated with the header field MUST be
concatenated, separated by a ASCII comma and an ASCII space , ,
and used in the order in which they will appear in the
transmitted HTTP message. Any other modification to the header
field value MUST NOT be made.

This means that everywhere in this lib that does the construction: header + ' ' + value (or similar), where value may be an array, is incorrect. It should be header + ' ' + value.join(', '). Ideally, all of these spots would also be consolidated so only one place needs to be maintained.

At least these instances need to be fixed:

https://github.com/joyent/node-http-signature/blob/master/lib/signer.js#L130
https://github.com/joyent/node-http-signature/blob/master/lib/signer.js#L133
https://github.com/joyent/node-http-signature/blob/master/lib/signer.js#L338
https://github.com/joyent/node-http-signature/blob/master/lib/parser.js#L271

content-length: 0

see this line which will emit an error if the content-length is 0 -- throw a MissingHeaderError

according to the rfc I looked at, a zero value should be valid.

Remove the sshpk from peerDependencies

http-signature doesn't play well with npm prune and npm shrinkwrap when using npm@2. The reason for this is the sshpk dependency in peerDependencies:

  "dependencies": {
    "assert-plus": "^0.1.5",
    "jsprim": "^1.2.2",
    "sshpk": "^1.4.6"
  },
  "peerDependencies": {
    "sshpk": "^1.4.6"   <- this
  },

How to reproduce the problem:

  1. create a package.json file like this:
{
  "dependencies": {
    "http-signature": "~1.0.2"
  }
}
  1. run npm install (use npm@2, I used 2.14.0)
  2. runing npm shrinkwrap fails:
npm ERR! extraneous: [email protected] c:\dev\labs\http-signature-test\node_modules\sshpk
  1. running npm prune and then npm shrinkwrap results in npm prune unbuilding the peer dependency and npm shrinkwrap failing:
npm ERR! missing: sshpk@^1.4.6, required by [email protected]

I propose to remove sshpk from peerDependencies, since it is already specified in dependencies.

(sshpk was added to peerDependencies in this commit: dc1ac85)

Thanks.

Bump `assert-plus`.

http-signature depends on assert-plus@^0.2.0. It also depends on sshpk, which depends on assert-plus@^1.0.0. So, currently, http-signature requires two versions of assert-plus.

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!

Getting :RSA_EAY_PUBLIC_DECRYPT:padding check failed:openssl\crypto\rsa\rsa_eay.c:697

I am getting this erro while verifying signature
Error: 596:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:openssl\crypto\rsa\rsa_pk1.c:100: 596:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:openssl\crypto\rsa\rsa_eay.c:697: at CleartextStream._pusher (tls.js:508:24) at CleartextStream._push (tls.js:334:25) at SecurePair.cycle (tls.js:734:20) at EncryptedStream.write (tls.js:130:13) at Socket.ondata (stream.js:38:26) at Socket.emit (events.js:67:17) at TCP.onread (net.js:367:14)

Any idea about that.

Non constant-time hmac comparison in verify.js

https://github.com/joyent/node-http-signature/blob/master/lib/verify.js#L34 uses === to compare two base64 encoded hmacs. From a crypto point of view, this is not secure as the comparison leaks timing information.

There are two common ways to address this issue:

  1. use a constant time comparison. This is nearly impossible when dealing with a JITed language like javascript, unless you can guarantee that everything is stored in fixed size buffers.
  2. hmac each side of the equality operator, blinding any timing information.

You can read more about this here: nodejs/node-v0.x-archive#8560 and on my blog too http://quaxio.com/salted_hmac/.

uses 'request-line' as in draft 01 of the spec; does not use (target-request) as in draft 03

Draft 03 of the http signatures spec (http://tools.ietf.org/html/draft-cavage-http-signatures-03) says to use something like this, to include the http method and path into the signature base:

(request-target): POST /foo + "\n"
date: Tue, 07 Jun 2011 20:51:35 GMT + "\n"
content-type: application/json + "\n"
content-md5: h0auK8hnYJKmHTLhKtMTkQ==

Whereas this implementation seems to still comply with draft 01 (http://tools.ietf.org/html/draft-cavage-http-signatures-01), which says to specify a 'request-line' header and use this as the sig base:

POST /foo HTTP/1.1 + "\n"
date: Tue, 07 Jun 2011 20:51:35 GMT + "\n"
content-type: application/json + "\n"
content-md5: h0auK8hnYJKmHTLhKtMTkQ==

This implementation should stay current with the latest spec.

Documentation incomplete

I just spent days struggling because the authorizationHeaderName option wasn't mentioned in the documentation. Having the documentation mention all the available options so people don't have to read the code to find them would make things much easier.

Node-http-signature-v1.1.0 (File: index.js) Vulnerability

Vulnerability: CVE-2019-20149
Library: Node-http-signature-v1.1.0 (File: index.js) Vulnerability
Description: ctorName in index.js in kind-of v6.0.2 allows external user input to overwrite certain internal attributes via a conflicting name, as demonstrated by 'constructor': {'name':'Symbol'}. Hence, a crafted payload can overwrite this builtin attribute to manipulate the type detection result.

Kindly Suggest me the fix.

node-http-signature

Security: Update dependency sshpk

I am indirectly referencing your package, and GitHub has warned me that your current package version is referencing a version of sshpk that has a security issue (for more information see NVD).

Would it be possible for you to update your dependency towards sshpk?

How to use with Bearer user authorization?

My understanding is that this module will sign the request storing the signature in the Authorization header which I usually use to check user credentials.

What's best practice to use them together? I want to know which user and from what client basically.

examples are wrong

This example:
https://github.com/joyent/node-http-signature/blob/0da7520aeea2be98f1b295aac00e3f21c71db314/http_signing.md#appendix-a---test-values

Appears to be wrong. When I use the given key:

$ cat privkey 
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDCFENGw33yGihy92pDjZQhl0C36rPJj+CvfSC8+q28hxA161QF
NUd13wuCTUcq0Qd2qsBe/2hFyc2DCJJg0h1L78+6Z4UMR7EOcpfdUE9Hf3m/hs+F
UR45uBJeDK1HSFHD8bHKD6kv8FPGfJTotc+2xjJwoYi+1hqp1fIekaxsyQIDAQAB
AoGBAJR8ZkCUvx5kzv+utdl7T5MnordT1TvoXXJGXK7ZZ+UuvMNUCdN2QPc4sBiA
QWvLw1cSKt5DsKZ8UETpYPy8pPYnnDEz2dDYiaew9+xEpubyeW2oH4Zx71wqBtOK
kqwrXa/pzdpiucRRjk6vE6YY7EBBs/g7uanVpGibOVAEsqH1AkEA7DkjVH28WDUg
f1nqvfn2Kj6CT7nIcE3jGJsZZ7zlZmBmHFDONMLUrXR/Zm3pR5m0tCmBqa5RK95u
412jt1dPIwJBANJT3v8pnkth48bQo/fKel6uEYyboRtA5/uHuHkZ6FQF7OUkGogc
mSJluOdc5t6hI1VsLn0QZEjQZMEOWr+wKSMCQQCC4kXJEsHAve77oP6HtG/IiEn7
kpyUXRNvFsDE0czpJJBvL/aRFUJxuRK91jhjC68sA7NsKMGg5OXb5I5Jj36xAkEA
gIT7aFOYBFwGgQAQkWNKLvySgKbAZRTeLBacpHMuQdl1DfdntvAyqpAZ0lY0RKmW
G6aFKaqQfOXKCyWoUiVknQJAXrlgySFci/2ueKlIE1QqIiLSZ8V8OlpFLRnb1pzI
7U1yQXnTAEFYM560yJlzUpOb1V4cScGd365tiSMvxLOvTA==
-----END RSA PRIVATE KEY-----

on the given date:

$ xxd input 
0000000: 6461 7465 3a20 5468 752c 2030 3520 4a61  date: Thu, 05 Ja
0000010: 6e20 3230 3134 2032 313a 3331 3a34 3020  n 2014 21:31:40 
0000020: 474d 54                                  GMT

I get a different signature:

$ openssl dgst -sha256 -sign ./privkey -out signature.bin ./input 
$ base64 < signature.bin 
jKyvPcxB4JbmYY4mByyBY7cZfNl4OW9HpFQlG7N4YcJPteKTu4MWCLyk+gIr0wDgqtLWf9NLpMAMimdfsH7FSWGfbMFSrsVTHNTk0rK3usrfFnti1dxsM4jl0kYJCKTGI/UWkqiaxwNiKqGcdlEDrTcUhhsFsOIo8VhddmZTZ8w=

@arekinath figured out that the input date had been updated, but not the signature. If you change the input date's year to 2012, then you get the signature that appears in the documentation:

$ openssl dgst -sha256 -sign ./privkey -out signature.bin ./input
$ base64 < signature.bin 
ATp0r26dbMIxOopqw0OfABDT7CKMIoENumuruOtarj8n/97Q3htHFYpH8yOSQk3Z5zh8UxUym6FYTb5+A0Nz3NRsXJibnYi7brE/4tx5But9kkFGzG+xpUmimN4c3TMN7OFH//+r8hBf7BT9/GmHDUVZT2JzWGLZES2xDOUuMtA=

Signature problem

Hi
I use node-http-signature to sign request. The request is sent to a Java tomcat application. In this one I use Tomitribe Http-Signature project. This one failed on signature verification.
After code debugging I think there is a little error in Signer.js in the WriteHeader :

RequestSigner.prototype.writeHeader = function (header, value) {
  assert.string(header, 'header');
  header = header.toLowerCase();
  assert.string(value, 'value');

  this.rs_headers.push(header);

  if (this.rs_signFunc) {
    this.rs_lines.push(header + ': ' + value);

  } else {
    var line = header + ': ' + value;
    if (this.rs_headers.length > 0)
      line = '\n' + line;
    this.rs_signer.update(line);
    console.log(line);
  }

  return (value);
};

Your test
if (this.rs_headers.length > 0)
is always true because you push header first...

Thanks

README needs public key generation steps

I have been unable to get the client and server in the README to work, and suspect the problem is simply because I do not understand the correct process for generating the public/private keys, which the node-http-signature module expects. It would be a great help if those instructions were added. I very much want to be able to use node-http-signature.

bump min node version to 0.10 and add CI testing

I ran into an issue today on my lab machine when trying to run the latest version of buckets-mdplacement (a freshly made image).

/opt/smartdc/electric-boray/node_modules/imgapi-cli/node_modules/sdc-clients/node_modules/smartdc-auth/node_modules/http-signature/lib/utils.js:62
  HEADER,
        ^
SyntaxError: Unexpected token ,
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/opt/smartdc/electric-boray/node_modules/imgapi-cli/node_modules/sdc-clients/node_modules/smartdc-auth/node_modules/http-signature/lib/parser.js:5:13)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
$ /opt/smartdc/electric-boray/build/node/bin/node -v
v0.10.48

The shorthand property setting is what caused the issue:

var cat = 'pumpkin';
var obj = { cat };
// obj => { cat: 'pumpkin' }

Judging by https://node.green/#ES2015-syntax-object-literal-extensions-shorthand-properties it looks like this shorthand syntax was added in node 4.9, and doesn't exist in 0.8 or 0.10.

This specific issue will be fixed in v1.3.1 of this module, but going forward there are some things we may want to consider. As @trentm mentioned in an email:

Though bumping the engine would have to go to at least 4.9 if what I mentioned above is correct. Ensuring we run make check on our changes in this repo should help identify this issue happening in the future as well.

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.