I have a server over HTTPS on NodeJS with Express.
When uploading a file, I have used the req.protocol directive in the controller to get either the HTTP or HTTPS "part" of the URL, so that I can save the file with the absolute URL. The problem is that without enabling the "trust proxy" setting of express (http://expressjs.com/en/api.html#trust.proxy.options.table), HTTPS doesn't get detected.
I thought this setting was used in the case of the actual redirect (when using the HTTP URL and the server doing the 301 redirect to HTTPS).
So this is more of an explanation question, rather than a solution one:
Why doesn't the HTTPS get detected when calling the URL through that?
trust proxy has nothing to do with 301 redirects.
That settings is important when running your node server behind a proxy:
+----------HTTPS--------+---HTTP---+
| | |
client --> internet --> proxy --> node.js
It is typical that you have some sort of proxy between the internet and your node server; for example a CDN server, a load balancer, or simply an nginx instance or such. The HTTPS connection is established between the client and that proxy. The proxy cares about the necessary wrangling of the SSL certificate and encrypting the connection and doesn't burden your application server (node) with those details. It is then forwarding only the relevant details of the request via plain HTTP to your node server. Your server only sees the proxy as the origin of the request, not the client.
Since the node server didn't itself handle the HTTPS connection, how could it know whether the connection between the client and the proxy was HTTPS? It can't. The proxy needs to voluntarily forward that information too. It does so in the X-Forwarded-* HTTP headers. The information whether it was specifically HTTP or HTTPS is sent in the X-Forwarded-Proto header.
The thing is, those are just HTTP headers. Anyone can set those headers. The client itself could set those headers. That's why you need to explicitly opt into using those headers with the trust proxy setting, iif and when you know your app will be running behind a proxy which sets those headers. When you're not running behind a proxy but your node server is directly exposed to the internet, you must switch that setting off; otherwise anyone could set those headers, your server would obey those headers and be lead to use false information.
Related
I'd like to have a reverse HTTPS proxy that CANNOT decrypt proxied traffic (ie an HTTPS passthrough/tunnel). The idea is to run this proxy on a VPS and point a domain to it, allowing for the IP address of the origin server to remain unexposed while maintaining end-to-end encryption.
Is this possible? I could probably proxy requests without difficulty since the destination address in that direction is fixed, but proxying responses seems problematic given that the proxy would be unable to read the client IP within an encrypted response.
A potential solution is to have the origin server package the encrypted response and destination address in a request made to the proxy, but I am unsure as to how I might generate the encrypted request without sending it (using node.js, which is the application running on the origin server).
From your question, I got that you want to listen to requests from your VPC server and pass the request to your other server which has to remain unexposed.
This can be configured with the web server which you are using for proxy ( considering AWS allows port forwarding from a VPN server to non-VPN server ).
I prefer doing this with Nginx as it is easy, open-source with less code and more functionality.
There is a concept of load balancing which does the same as you mentioned above.
steps :
Install Nginx and keep it active.
Create a new configuration file in /etc/nginx/sites-enabled
write the below code with modifications:
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
server {
listen 80;
location / {
proxy_pass http://myapp1;
}
}
}
and at the place of srv1.example.com and srv2.example.com add the domain to which you want to redirect requests
Save the file and restart the Nginx
Boom!! it should redirect all incoming requests to your application.
On my machine, im hosting a node server that is listening on port 5000. Before setting up a forward proxy (squid), i was able to perform a GET on https://localhost:<port>. However, after setting up a forward proxy and setting the environmental variable http_proxy=<ip addr:port>, this GET request no longer works.
The error that shows up is: tunnelling socket could not be established, statusCode=503
Some additional information:
The proxy server works as I am able to connect to the internet via it.
Performing curl instead, on the https:localhost:5000/api works.
Am using request.js for the requests, using agentOptions to specify TLS protocols & ca cert.
I am hoping to understand how the traffic is now different after i add in a proxy. From my understanding, now we have to go through a sort of TLS CONNECT / tunnelling since to the proxy first, since its a HTTPS request, before coming back to my localhost. But in the case without the proxy, how is it that its working?
Any help would be greatly appreciated. Thanks!
you must add
export no_proxy='localhost,127.0.0.1'
the https work because you don't use proxy for https , you must set https_proxy='<tour_proxy>'
So I've already done my research and figured out that socket.io only works with cloudflare if you use set ports found that here
So through that research I found that http and https can't use the same port. I'm coming here to as you guys how do you get a socketio server to listen on two ports? So it can support http and https with cloudflare
The common method is referred to as an SSL Termination Proxy (also called SSL off-loading). The proxy accepts incoming messages over HTTPS and passes the decrypted requests to another resource (another server, web service/API, etc.). This would allow your Node.js application utilizing socketio to handle all requests, no matter if the client made an HTTP or HTTPS request. Software like NGINX, Apache, and even Microsoft IIS are capable of providing this functionality.
Here are some links regarding this topic:
General Info: https://en.wikipedia.org/wiki/TLS_termination_proxy
NGINX: https://www.nginx.com/resources/admin-guide/nginx-ssl-termination/
NGINX: https://www.nginx.com/resources/admin-guide/nginx-tcp-ssl-termination/
HAProxy: https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04
IIS: https://blogs.iis.net/wonyoo/ssl-off-loading-in-application-request-routing
app.use(session(
{
...
proxy: true,
resave: true,
saveUninitialized: true
}
));
I found a tutorial on express-session and they have an proxy: true option. Can I leave it on true? What does this do? Is it better to include it? I know what a proxy is however I don't really get why this is an option?
The fine manual states:
Trust the reverse proxy when setting secure cookies (via the "X-Forwarded-Proto" header).
This refers to situations where clients don't connect directly to your Node server, but through a reverse proxy. For instance, clients connect to an NGINX webserver, which forwards the requests to a Node server; NGINX, in this situation, is the reverse proxy.
In reverse proxy setups, it's also quite common that the client communicates with the reverse proxy over HTTPS, yet the proxy communicates with the Node server using plain HTTP.
This is an issue when you configure the session middleware to use so-called "secure cookies" (documented here). The session middleware won't allow these cookies being sent over plain HTTP but requires that they are sent over HTTPS. If your reverse proxy communicates with your Node server over HTTP, this would mean you won't be able to use secure cookies.
To solve this problem, the reverse proxy will set the X-Forwarded-Proto header to every request it forwards. It tells the Node server what the original protocol of the request was, regardless of the way the reverse proxy connects to the Node server.
With the proxy option of the session middleware, you're telling it to trust this header and allow secure cookies being sent over plain HTTP, provided that X-Forwarded-Proto is set to https.
If you are exposing your Node server directly (so clients connect to it), you should set this option to false, because otherwise, a client can fool your server (by sending a X-Forwarded-Proto header itself) into thinking that the connection was secure. However, if you're not using secure cookies anyway, it won't really matter.
If your app does not receive requests forwarded through a proxy, you do not need to worry about this option. Proxies are often used to route requests to one of several apps.
A proxy looks like this:
[Client] ==request==> [Proxy] ==forwarded request==> [Server]
Here, the server can't see the original request and relies of the proxy to truthfully relate each request.
From the express-session docs:
proxy
Trust the reverse proxy when setting secure cookies (via the "X-Forwarded-Proto" header).
The default value is undefined.
true The "X-Forwarded-Proto" header will be used.
false All headers are ignored and the connection is considered secure only if there is a direct TLS/SSL connection.
undefined Uses the "trust proxy" setting from express
Looking at the Stack overflow question What does "trust proxy" actually do in express.js, and do I need to use it? (which references "Express behind proxies"), we see that "trust proxy" means whether the app trusts its proxy to accurately report the source of a request. This impacts secure HTTPS-only cookies: it is necessary to trust the proxy that a request genuinely came from an HTTPS source.
[Client] ==HTTPS==> [Proxy] =="I'm forwarding an HTTPS request"==> [Server]
The server can't see the client. If the proxy is lying, and it's not really an HTTPS request from the client, the server shouldn't send secure cookies. Therefore, we can indicate whether we trust the server to truthfully report the HTTP/HTTPS status of forwarded requests.
A web application i developed is sitting on a server that serves it under https, some of my js code requires to open a socket to another server (nodejs) who is currently not set for https. and thus browser wont allow it to run.
all i want is a simple way without getting involved with certificates just to initiate a https socket connection, i don't mind the lack of security,
just need app to run.
The certificates are not your problem. Your problem is CORS. You need to configure your server to answer with a header allows foreign-origin
res.header('Access-Control-Allow-Origin', 'example.com');
because in your case the technical difference between http (port 80) and https (443) is the port.
EDIT: ... I mean from the browsers point of view