node-http-proxy SSL connections is not working.

Created on 28 Nov 2015  路  7Comments  路  Source: http-party/node-http-proxy

I have set up a proxy node-http-proxy server on port 8009. and my actual http server on port 3000. But it seems like they are not working. My code looks like this:

var fs = require('fs');

var httpProxy = require('http-proxy');

httpProxy.createServer({
  target: 'http://127.0.0.1:3000/',
  ssl: {
    key: fs.readFileSync('./sslcerts/key.pem', 'utf8'),
    cert: fs.readFileSync('./sslcerts/cert.pem', 'utf8'),
    passphrase: 'password1'
  },
  requestCert: true,
  rejectUnauthorized: true
}).listen(8009, function(){
  console.log("SSL server started listening on port 8009");
});

// thats the node http proxy

var http = require('http');

var port = 3000;
app.set('port', port);

var server = http.createServer(app);

server.listen(port, function(){
  console.log("Express non-SSL server listening on port " + port);
});

Now I have used wireshark to sniff the traffic and there was a post field that was sending data to the https://localhost:8009/ server and it was viewable in plain text on the localhost loopback interface.
Not only that, the wireshark protocol detected was http (not TLS/SSL like its supposed to show). there was no indication of TLS handshake or anything like that. I have tested with other legitimate webpages with wireshark and what I found was those webpages have a TLS key handshake like the client hello/server hello stuff but that was not seen when I used wireshark on a request to localhost:8009 https server. So I would like to know what I could do to fix the issue and go through the steps of the TLS server hello/client hello handshake and make sure the data is not being sent on plaintext but rather, encrypted.

confirmed-bugs

All 7 comments

@BadBoy20 I think it is the port. I had all kinds of issues trying to get it to connect ports that weren鈥檛 80 or 443. Once I switched to those it worked fine. You can have your proxy listening on 8009, just trying changing your test server upstream from 3000 to 443.

If it fixes it, it looks the issue is under:

https://github.com/nodejitsu/node-http-proxy/blob/master/lib/http-proxy/common.js

Selection of port seems to be in multiple places and inconsistent.

Oh I see what you mean @pyper. Because the port number is hardcoded in there to be either 80 or 443 to determine if it is encrypted or not it does not work with any other user given port to listen to. It doesn't know what to do with them? I see what you're saying. If that is the case, could that be reported as a bug? Implying I have to have root access to test run node code? I was actually hoping to have it listen for https on port 8009 then have an iptables rule on 443 to route it to 8009.

I'll try to change it and test it when I get home. Also something I had to run by to clarify, did you say to have the proxy listen on 8009 and the 3000 one to 443? because 8009 was my https port and the 3000 was my http port. I guess I'll try.

This looks like a bug. We should only default to 443 or 80 if we do not have a port in the target as well. Seems like this is not handling all cases since we only use the port if its in the header. Would love a PR to clean this up. @pyper seems like you are already on the right track if you want to take a stab at it :)

@BadBoy20 Yes change 3000 to 443 or 80. You could also confirm it further by trying it without any encryption.

@jcrugzz So your last name is Cruger and you want me to stab something? :)

I will give it a shot hopefully soon, cheers.

This might be a good time to mention my last name is scissorhands

This is a pretty big bug! Right now it seems a lot of other reverse proxy modules for NodeJS are based on this module (such as node-reverse-proxy and rocky), so they are broken as well. Are you guys gonna push a patch release with this fix soon?

Was this page helpful?
0 / 5 - 0 ratings