HTTPS: Option to assert authorized before sending request data. (possible security problem) #2247

Closed
GeorgeBailey opened this Issue Dec 2, 2011 · 8 comments

Comments

Projects
None yet
3 participants

Original post: http://stackoverflow.com/questions/8304084/node-js-assert-authorized-before-sending-data-over-https

I understand I need to check the response.connection.authorized field to see if the SSL/TLS connection is secure and to the correct server.

Trouble is, I have to send a request before I can check that field. I need a way to assert the connection is authorized before sending any (potentially private) data.

Granted, there needs to already be another security flaw installed such as cache poisoning or router intrusion for this to even matter, but counter-measures expected of HTTPS are a little late due to this issue.

Owner

bnoordhuis commented Dec 2, 2011

Agreed. The mechanism is in place in the TLS layer (the rejectUnauthorized argument to tls.SecurePair) but there is no good way to toggle that behaviour from the HTTPS layer.

koichik commented Dec 2, 2011

@cjavapro: Can you try like this?

  var req = https.request(options, function(res) {
    ...
  });
  req.on('socket', function(socket) {
    socket.on('secureConnect', function() {
      if (!socket.authorized) {
        req.abort();
        return;
      }
      req.write(...); // if necessary
      req.end();
    });
  });
  req.on('error', function(err) {
    ...
  });

@koichik, I am not in a good place to test this on the latest version. Someone could test on one of Google's IP addresses shown in nslookup google.com. It looks like a sound solution for the purpose of holding back data until authorization.

However, in the source code, I have not found any definitive logic that states that the headers will not be written until after secureConnect is called. If someone would guarantee that by locating the logic that ensures this and documenting it, I would count this as Closed.

But until there is guarantee for both the headers, and the body, the resolution is still incomplete.

I do like the rejectUnauthorized solution, if it is implemented, that would be nice, but it may be useful to reject connections except for a certain unauthorized reason. Granted, this is not a very bright idea, but it may be necessary at times.

But either solution works for me.

Owner

bnoordhuis commented Dec 3, 2011

@koichik: The issue is not so much that it's impossible to check the authorization status (because it's not) but that there is no simple / straightforward / obvious way to do it. We can fix it by either improving the documentation or the API. I'm open to suggestions. :-)

@koichik koichik added a commit to koichik/node that referenced this issue Dec 6, 2011

@koichik koichik tls: enable rejectUnautholized option to client
Fiexes #2247.
163967c
Owner

bnoordhuis commented Dec 6, 2011

@koichik: Reviewed. One documentation nit, otherwise LGTM. Do you want to merge this in v0.6 or master?

koichik commented Dec 7, 2011

@bnoordhuis: Thanks!

Do you want to merge this in v0.6 or master?

The patch is based on v0.6 but this is not a bug fix, I will merge it in master.

@koichik koichik added a commit that referenced this issue Dec 7, 2011

@koichik koichik tls: enable rejectUnauthorized option to client
Fiexes #2247.
f8c335d

koichik commented Dec 7, 2011

@cjavapro: Thanks for the report, fixed in f8c335d.

koichik closed this Dec 7, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment