Possible to add proxy after TOR exit node? - tor

Can I configure the Tor Browser Bundle so that it becomes an extra hop after the Tor exit node without using special OS such as Whonix?

The Tor Browser Bundle just comes pre-configured to use Tor as a socks proxy so as far as I know, you cannot add an extra HTTP proxy after Tor.
Another alternative to using a special OS would be to use proxychains to chain requests through Tor and then an HTTP proxy. You wouldn't necessarily want or need to use the Tor Browser Bundle for this.
I have Tor running locally on port 9050 so I added these lines to my proxychains.conf file under the [ProxyList] section:
[ProxyList]
# tor
socks5 127.0.0.1 9050
# then chain through http proxy
http 2.3.4.5 80
Then to launch your browser which will proxy through Tor and then the HTTP proxy, run proxychains /usr/bin/firefox
It will cause all connections from the browser to first go through Tor, then through the HTTP proxy.
You should see output similar to this on the command line to know its working:
|S-chain|-<>-127.0.0.1:9050-<>-2.3.4.5:80-<><>-74.125.239.39:443-<><>-OK
127.0.0.1:9050 shows it chained through Tor, then 2.3.4.5:80 is the HTTP proxy, and finally out to the destination 74.125.239.39:4443 (Google).
A note on security, I used firefox browser for the example. You could use Tor browser instead but you will want to make sure its proxy configuration is set not to use a proxy since you're already chaining through Tor via proxychains.
Tor Browser will be a little safer since it won't keep history/cache and its signature much less unique.
Hope that helps.

Related

Chromium proxy only https

I use mac os & chromium 80.0.3987.0 and I have problem with proxy.
When I start for example: ./Chromium --proxy-server=123.123.123.123:8888 and open https page I have proxied IP but when I open http I have my own ip! What's wrong?
How to get proxy on both http & https and return error in other cases to prevent connecting from own IP? I use it also with puppeteer.
http://whatismyip.host/ - no proxy
https://whatismyipaddress.com/ - with proxy

Run nodejs app through HTTPS

I have a node app that is setup on SSH by running node osjs run --hostname=dc-619670cb94e6.vtxfactory.org --port=4100.
It starts at http://dc-619670cb94e6.vtxfactory.org:4100/ without problems, but instead I want to serve it through HTTPS https://dc-619670cb94e6.vtxfactory.org:4100/ , where I receive an error ERR_CONNECTION_CLOSED.
If I use the port I'm unable to reach it with https, but https://dc-619670cb94e6.vtxfactory.org/ is accessible.
How can I serve the port 4100 through htttps?
Thanks.
This is an implementation detail of OS.js. Their docs recommend setting up a reverse proxy for servers. Doing this will give you more control over SSL and ports, like you want
https://manual.os-js.org/installation/

Having issues setting running Meteor app with SSL on AWS Opsworks

My base case is that my Meteor App runs perfectly on Opsworks.
I do a Meteor build, tweak the files and all is good (without HTTPS/SSL). I am not using METEORUP. I just upload my tweaked build file and deploy on opsworks.
Also, I am using the out of the box Opsworks HAPROXY loadbalancer.
I then install the SSL certificates for my app and set Meteor to list on PORT=443 as per screenshot:
In the browser, I see:
503 Service Unavailable
No server is available to handle this request.
In the log files I see:
Mar 8 03:22:51 nodejs-app1 monit[2216]: 'node_web_app_buzzy' start: /bin/bash
Mar 8 03:23:51 nodejs-app1 monit[2216]: 'node_web_app_buzzy' failed, cannot ope
n a connection to INET[127.0.0.1:443/] via TCPSSL
Any ideas welcome
Your HAproxy configuration is expecting meteor/node to respond with SSL.
It should instead, terminate SSL and talking to node/meteor in plain HTTP. This is because, meteor doesn't do SSL ; it expects a server in front to handle it.
Solution:
Update the frontend https-in section to terminate ssl and redirect to the http backend
defaults
#... add this line to enable the `X-Forwarded-For` header
option forwardfor
# ...
# .... update this section ...
frontend https-in
mode tcp
# this bit causes HAProxy to talk TLS rather than just forward the connection
bind :443 ssl crt /path/to/your/certificate
reqadd X-Forwarded-Proto:\ https
# now direct it to your plain HTTP application
acl nodejs_application_buzzy_domain_buzzy hdr_end(host) -i buzzy
use_backend nodejs_app_servers if nodejs_application_buzzy_domain_buzzy

Go, sudo, and apache port 80

I am using gorilla/mux package in golang, but there are some problems. The first is I have no permissions to use port 80 on my application becuase I cannot run the application from sudo as the $GOPATH is not set when using sudo.
Here is the error I get from my program:
$ go run app.go
2014/06/28 00:34:12 Listening...
2014/06/28 00:34:12 ListenAndServe: listen tcp :80: bind: permission denied
exit status 1
I am unsure if it will even work when I fix the sudo problem, because apache is already using port 80 and I am not sure if both my app and apache can "play nice" together.
Any advice on how to solve this would be great. Thank you.
Quoting elithar's comment,
You have two options: either turn off Apache (because only one service
can bind to a port), or (better!) use Apache's ProxyPass to proxy any
incoming requests to a specific Hostname to your Go server running on
port (e.g.) 8000. The second method is very popular, robust, and you
can use Apache to handle request logging and SSL for you.
Reverse Proxying
Using Apache on port 80 in this way is called a reverse proxy. It receives all incoming connections on port 80 (and/or port 443 for https) and passes them on, usually unencrypted, via internal localhost connections only, to your Go program running on whatever port you choose. 8000 and 8080 are often used. The traffic between Apache and your server is itself HTTP traffic.
Because your Go program does not run as root, it is unable to alter critical functions on the server. Therefore it gives an extra degree of security, should your program ever contain security flaws, because any attacker would gain only limited access.
FastCGI
You can improve the overall performance of the reverse proxying by not using HTTP for the connection from Apache to the Go server. This is done via the FastCGI protocol, originally developed for shell, Perl and PHP scripts, but working well with Go too. To use this, you have to modify your Go server to listen using the fcgi API. Apache FastCGI is also required. The traffic from Apache to your server uses a more compact format (not HTTP) and this puts less load on each end.
The choice of socket type is also open: instead of the usual TCP sockets, it is possible to use Unix sockets, which reduce the processing load even further. I haven't done this in Go myself, but the API supports the necessary bits (see a related question).
Nginx
Whilst all the above describes using Apache, there are other server products that can provide a reverse proxy too. The most notable is Nginx (Nginx reverse proxy example), which will give you small but useful performance and scalability advantages. If you have this option on your servers, it is worth the effort to learn and deploy.
Based on this previous answer about environment variables, I was able to solve the sudo problem easily.
https://stackoverflow.com/a/8636711/2576956
sudo visudo
added these lines:
Defaults env_keep +="GOPATH"
Defaults env_keep +="GOROOT"
Using ubuntu 12.04 by the way. I think the previous answer about the proxy for using port 80 is the correct choice, because after fixing the sudo issue I was given this error about port 80 instead:
$ sudo go run app.go
2014/06/28 01:26:30 Listening...
2014/06/28 01:26:30 ListenAndServe: listen tcp :80: bind: address already in use
exit status 1
Meaning the sudo command was fixed but the proxy binding would not work with another service already using port 80 (apache).

Transparent Proxy Issue with SSL

I have a RHEL5 server in a private zone. I've set up a transparent proxy for ports 80 and 443. When I try a wget on 443, I get the following:
# wget -O- https://www.google.com
--2013-02-14 15:16:50-- https://www.google.com/
Resolving www.google.com... 74.125.129.147, 74.125.129.104, 74.125.129.106, ...
Connecting to www.google.com|74.125.129.147|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.
I assume the proxy works because it's connecting. I don't know what else could be causing this.
This OpenSSL error indicates that wget sent the initial SSL ClientHello message, but gets an unexpected response from the server (or proxy) which was not an SSL ServerHello message.
This can be because the proxy speaks plain HTTP with the client, instead of HTTPS, because of a configuration error (e.g. with squid if port 443 is redirected to a http_port instead of https_port with the transparent option), or because it does not support transparent proxying of SSL at all. To debug, you may try connecting to http://www.google.com:443/ to see what happens. To know what's going on, you might want to run tcpdump while connecting to see what the server responds with. Also check the error log of your transparent proxy.
Without the transparent proxy configuration it is hard to tell what the problem is.

Resources