I got a tor client using on mashine in my local network, so I capture all traffic.
Also I can redirect all tor traffic on any server/client, add some clients in network, modify or inject every packet from this mashine.
So, is there way to decrypt this tor traffic or just see requested resources?
One of the ways to see requested resources is DNS-sniffing. If client isn't encapsulate DNS-requests traffic into tor network and requested only internet (not tor internal) resources you can capture network packets between client and DNS-server.
Related
Do they automatically send all the sites open on the browser through the vpn, or does the traffic not get sent through the vpn until the pages are refreshed?
Depends on if anything loads after you connect to the VPN. If you already have the webpage completely rendered, then there will be no requests from the website being sent to the VPN
When you initiate a VPN you default route will be though the VPN gateway, if it's intended to provide internet access. However, if its just to reach specific subnets on the peer end of the VPN tunnel then the VPN tunnel will be used for that specific subnets.
Although, HTTP uses TCP connection it doesn't keep the connection open after sending all the requested data and upon successfully received by the browser.
Assuming you have the first scenario and HTTP connection behavior it will start sending traffic though the VPN if you refresh or click any hyper link in the page(as this will create a new TCP connection to request that data.
I have read socks5's RFC, but I still don't understand why TCP and UDP packets can be passed through the firewall.
It is not possible to simply bypass a (properly configured) firewall by using the SOCKS protocol and this is also not the intention of the protocol.
In the context of firewalls a SOCKS server is a proxy server which is explicitly installed at the firewall in order to provide internal clients with restricted access to the outside. This usually means that most outgoing traffic except SOCKS is blocked by the firewall and that the SOCKS server is configured to only allow authenticated connections (based on IP, user or similar) and maybe even restrict where specific users can connect to. Insofar it is similar to a HTTP proxy.
I am reading the SOCKS5 RFC, it has:
CONNECT
In the reply to a CONNECT, BND.PORT contains the port number that the
server assigned to connect to the target host, while BND.ADDR
contains the associated IP address. The supplied BND.ADDR is often
different from the IP address that the client uses to reach the SOCKS
server, since such servers are often multi-homed. It is expected
that the SOCKS server will use DST.ADDR and DST.PORT, and the
client-side source address and port in evaluating the CONNECT
request.
For the last part of this paragraph, I have two questions:
The doc states that SOCKS servers are often multi-homed, and will reply to the client different bound address and port than the ones the client originally connects to. Does this mean the SOCKS server the client connects to redirects the connection to another SOCKS server? If so, what is point of letting the client sense the presence of the redirected SOCKS server? What will a client normally do with the bound address and port the SOCKS server replies?
The doc states It is expected that the SOCKS server will use DST.ADDR and DST.PORT, and the client-side source address and port in evaluating the CONNECT request, what exactly does it mean by evaluating the CONNECT request? What am I supposed to do in this evaluating process if I am implementing a SOCKS server?
SOCKS proxies are multi-homed because they are often installed at network boundaries like firewalls. The client connects to the internal interface of the firewall but the outgoing address is the external face. Since some protocols like FTP need to include the external visible IP address and port in-band (see FTP data transfer, i.e. PORT and PASV) they need to know this externally visible IP and port.
A normal socks proxy will connect where the clients wants to, i.e. DST. But when an upstream proxy is configured or when firewall ACL say different the proxy might behave differently.
No. It means the server has 2 (or more) network cards/connections -- you communicate with the server on cardA, but when that server connects to the device downstream, it uses cardB.
That's up to you really...perhaps you want to blacklist/whitelist certain clients/servers/ports (ex. only allow clients from your country, or only allow connections to a specific country). Good example is not letting a client connect back to itself (?). Just a guess. Usually RFCs are good about saying "MUST, MIGHT, MUST NOT, etc" ..if it says "expected", to me that sounds like 'might' which basically means 'can, but doesn't have to.'
I am trying to understand tor and Im confused about one thing. If one modifies a conventional web browser to use tor, does this give access to .onion websites? Seems that the browser would still not be able to resolve the .onion domain suffix. If true, then what is the purpose of trying to add the tor feature to a conventional web browser? If only for anonymity, then how does this differ from using a VPN?
To modify a conventional browser just involves changing its proxy settings to use Tor as a SOCKS proxy. Tor Browser has a number of other security enhancements and anonymity features, but at the very basic level it can communicate with the Tor controller and the browser proxies everything using SOCKS.
When proxied through Tor SOCKS, it will transparently route .onion addresses over the Tor network to the hidden service destination and back if it is available. When accessing regular internet sites, Tor can resolve the DNS, bypassing your local DNS, and proxy your traffic through an exit relay.
It's different from a VPN in the way it routes your traffic to the destination. With a single VPN alone, your traffic is potentially one hop away from your destination. If the VPN is being monitored or is subverted, it could be possible to see your unencrypted traffic, or at least know what IP addresses you may be communicating with. VPN traffic might be more detectable, require the use of special software, or be more complicated to set up in general.
Since Tor traffic is encrypted with TLS and there are thousands of potential entry points, and roughly 1000 exit relays as of today with an additional random hop in between, your traffic is potentially more difficult to trace back to you without massive or very targeted surveillance.
The Tor Overview and Hidden Services pages can be helpful to read too.
Hope that helps.
I have a requirement that I believe may be impossible and wanted to confirm this with experts in this community.
A client wants us to configure a DNS server to point all non-whitelisted domains to an IP address of a server on the internet. This server should forward / redirect all non-http traffic to an IP address associated with the real DNS record as accurately as possible. However, for all port 80 traffic, it should intercept the traffic and forward to a web proxy. This could in theory be possible if we had a large block of public IP addresses that could intelligently route based on the sender's IP to the proper destination, but the engineering effort required there to keep the DNS request and subsequent requests to that same domain in sync would be immense. Not to mention we would be limited from a concurrency perspective.This is probably similar to how OpenDNS does their DNS+Proxying, but they only seem to do it for google.com. This needs to work for an arbitrary set of domains (potentially all of them).
Is the above approach feasible? If not, are there other ways this problem can be approached short of requiring specialized gateway hardware?
Ideally the system will minimize bandwidth usage & latency for non-http traffic without requiring anything besides DNS or firewall configuration. I realize we can forward all http traffic at the firewall level, but the client wants to avoid http requests to CDNs or media heavy sites as well as minimize deployment effort across disparate network configurations.
OpenDNS works by blacklisting instead of whitelisting
When a host is blacklisted, openDNS will resolve the name into their IP address, which in turn prevent the client from accessing the real IP.
In your case, looks like you need transparent proxy where you can route all HTTP traffic to your proxy server:
See :
http://www.howtoforge.com/dansguardian-content-filtering-with-transparent-proxy-on-ubuntu-9.10-karmic
This might not be exactly what you are looking for but take a look at my article "How To Setup A Transparent Content Filtering Proxy" in which I utilize OpenDNS's blacklisting capabilities.
You can do it using two pieces:
DNS resolver configured with *. pointing to IP A.B.C.D (wildcard)
NGINX reverse proxy listening on A.B.C.D that proxy request to the domain present in the Host header.