How to put a proxy server with authorization on the output, according to the documentation
The end still shows TOR, not a proxy
/etc/torrc
`Socks5Proxy
Socks5ProxyUsername
Socks5ProxyPassword
`
You should probably edit /etc/torrc.conf or /etc/tor/torrc.conf config
I found this for you :
HTTPProxy host[:port]
Tor will make all its directory requests through this host:port (or
host:80 if port is not specified), rather than connecting directly to
any directory servers.
HTTPProxyAuthenticator username:password
If defined, Tor will use this username:password for Basic HTTP proxy
authentication, as in RFC 2617. This is currently the only form of
HTTP proxy authentication that Tor supports; feel free to submit a
patch if you want it to support others.
HTTPSProxy host[:port]
Tor will make all its OR (SSL) connections through this host:port (or
host:443 if port is not specified), via HTTP CONNECT rather than
connecting directly to servers. You may want to set FascistFirewall to
restrict the set of ports you might try to connect to, if your HTTPS
proxy only allows connecting to certain ports.
HTTPSProxyAuthenticator username:password
If defined, Tor will use this username:password for Basic HTTPS proxy
authentication, as in RFC 2617. This is currently the only form of
HTTPS proxy authentication that Tor supports; feel free to submit a
patch if you want it to support others.
Socks4Proxy host[:port]
Tor will make all OR connections through the SOCKS 4 proxy at
host:port (or host:1080 if port is not specified).
Socks5Proxy host[:port]
Tor will make all OR connections through the SOCKS 5 proxy at
host:port (or host:1080 if port is not specified).
Socks5ProxyUsername username
Socks5ProxyPassword password
If defined, authenticate to the SOCKS 5 server using username and
password in accordance to RFC 1929. Both username and password must be
between 1 and 255 characters.
Related
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>'
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.
Is there way to set Proxy settings (route via proxy Server) for HazelcastClient to connect to remote cache server (which is behind a firwall)
Thanks
No since Hazelcast clients use an internally developed (even though open source), plain TCP protocol, there is no real proxy support. You might be able to use a SOCKS proxy though but this is not supported.
There's also a prototype to tunnel the protocol through a HTTPS session but same thing, not officially supported: https://github.com/noctarius/https-tunnel-openshift-hazelcast
In my setup, I have 2 layers of transparent proxies. When a client makes an SSL request, I wish to have the first proxy it meets simply forward the traffic to another one without attempting to do the handshake with the client.
The setup seems funny, but it is justified in my case - the 2nd proxy registers itself to the first one (through some other service) only occassionally. It tells the first: "I'm interested in some traffic that looks like___". In most cases, the 1st proxy simply does the work.
Can an httpProxy (in node-proxy) proxy SSL requests? Must I use an httpsProxy (which will then do the handshake with the client)?
You could do all of this with the existing httpsProxy if you wanted to. Unless you are wanting to use a non-Node proxy or proxy to a different server, I can't see what you would gain by having two.
Simply add the required the logging/signing logic to the existing httpsProxy.
Typically, I use https on the proxy to both restrict the number of open ports and to remove the need to do https on all of the Node servers running. You can also add Basic Auth using http-basic library too.
See my example code: https://github.com/TotallyInformation/node-proxy-https-example/blob/master/proxy.js
EDIT 2012-05-15: Hmm, after some thought, I wonder if you shouldn't be looking at something like stunnel to do what you want rather than Node?
(For reference, I've already made some of those points in my answer to your similar question on ServerFault.)
If you are after a MITM proxy (that is, a proxy that can look inside the SSL content by using its own certificates, which can work provided the clients are configured to trust them), it will hardly be fully transparent, since you will at least have to configure its clients to trust its certificates.
In addition, unless all your client use the server name indication extension, the proxy itself will be unable to determine reliably which host to issue its certificate for (something that a normal HTTPS proxy would have been able to know by looking at the CONNECT request issued by the client).
If you're not after a MITM proxy, then you might as well let the initial connection through via your router. If you want to record that traffic, your router might be able to log the encrypted packets.
Having your router catch the SSL/TLS packets to send them transparently to a proxy that will merely end up relaying that traffic untouched anyway to the target server doesn't make much sense. (By nature, the transparent proxy will imply the client isn't configured to know about it, so it won't even send its CONNECT method with which you could have had the requested host and port. Here, you'll really have nothing more than what the router can do.)
EDIT: Once again, you simply won't be able to use an HTTP proxy to analyse the content of the connection transparently. Even when using a normal proxy, an HTTPS connection is relayed straight through to the target server. The SSL/TLS connection itself is established between the original client and the target server. The point of using SSL/TLS is to protect this connection, and to make the client notice if something is trying to look inside the connection.
Plain HTTP transparent proxy servers work because (a) the traffic can be seen (in particular, the request line and the HTTP Host header are visible so that the proxy can know which request to make itself) and (b) the traffic can be altered transparently so that the initial client doesn't notice that the request wasn't direct and works as if it was.
Neither of these conditions are true with HTTPS. HTTPS connections that go through an HTTP proxy are simply tunnel, after explicit request from the client, which has sent a CONNECT command and was configured to make use of such a proxy.
To do something close to what you're after, you'd need an SSL/TLS server that accepts the SSL/TLS connection and deciphers it (perhaps something like STunnel) before your HTTP proxy. However, this won't be transparent, because it won't be able to generate the right certificates.
If I set up a proxy (such as Squid for example) configured with certs to listen for HTTPS are browsers able to connect to the proxy over TLS/SSL?
Example of what I'm asking:
Browser Proxy Server
yahoo.com -> TLS -> Squid -> HTTP -> yahoo.com
I've set up a proxy listening on 443, but am not having success getting browsers to use it (connecting to the http proxy on port 80 works fine).
Chrome can do that:
http://www.chromium.org/developers/design-documents/secure-web-proxy
It also supports a directive in PAC file to point to HTTPS proxy.
If you want to secure your communication between browser and proxy, use STunnel (SSL tunneling) or VPN or SSH tunnel to the "proxy" server, then run your communication over this secure tunnel. I.e.:
Browser -> STunnel on the client -> STunnel on the server -> Squid Proxy -> Remote host
To answer your direct question - what you want is for the browser to act in a similar way to STunnel itself. I don't know a browser or even HTTP/HTTPS component (if we are on a programming site) to work this way.