How to force whole-network Tor with LAN -> Tor -> WAN configuration?



  • I have installed Tor on my pfSense system, and I'd like to configure pfSense to route all traffic through Tor. I'm new to pfSense, and I don't understand how that should be done. Can someone point me in the right direction? Tor is basically a proxy at 127.0.0.1:9050, but I just don't know how to set up routing such that the LAN is forced to enter 127.0.0.1:9050 before being allowed to leave via the WAN.

    I guess that means I'd have to make it so only Tor is allowed to access the WAN, and the LAN is only allowed to access Tor, but I don't know how that translates into configuration with pfSense. LAN and WAN are already "linked", which was set up automatically for me by the installer config steps, and I think there must be a way to insert Tor in the middle there somewhere. Any ideas?



  • I've never done this, but I'm thinking out loud and asking…

    If you have TOR installed (its basically a proxy)
    And if you install squid and make it transparent on the LAN
    and then you set squid in Proxy server > Upstream proxy settings to:
    127.0.0.1 and port 9050

    Would that do what you need?  (I don't know, so Its a guess)

    You would still need to block the users such that they can only have access to Squid and not any protocol on any port outside your network.



  • This might work. I had a similar half-baked idea that involved using a VPN, but I never came up with anything that would work. Tor supports any TCP port or protocol (it might be possible to tunnel UDP), but I think using Squid as a facilitator would restrict usage to only HTTP ports, right? That might not matter much, at least for the purpose of getting something to work soon. I just installed the Squid package, and I'll see what happens when I follow your suggestions.

    A member of the New York York *BSD User Group is working on a package for Tor. Once it's available, I hope it will be inviting for people to add features to it, like hidden services and forced-Tor routing. The Whonix system was created to serve this need, and I think pfSense can provide a better platform. There are many similar efforts, and many are now defunct. The one thing they all have in common is they each tried to reinvent the wheel to build upon their own platforms. I think pfSense is the right tool for the job, and I'm hoping I can get it working well enough to perhaps guide some enhancements to the upcoming Tor package for pfSense to achieve the same goals. You can read about that here:

    http://comments.gmane.org/gmane.org.user-groups.bsd.nycbug/9793

    Thanks for the idea of using Squid. I'm going to see what happens with it now. I think it's probably not the "right" way to do this, so I'm guessing there's some sort of fundamental routing configuration that can do this. If you or anyone else thinks up a better way, please post. Likewise, more tips on using Squid to facilitate it are welcome, since I have no idea what I'm doing yet, and I'll probably need advice.



  • I do know, for sure that if you run TOR on a separate box inside the LAN and then point squid at that box, it will work.

    (That separate box could even be a tiny low ram single processor VM running a sever install of Ubuntu or CentOS)

    Never tried pointing squid at TOR running on the same box as Squid, but I'd love to know.

    Plan on trying it?



  • I actually like using TOR > Transparent Squid proxy (with caching on)

    Because that way it will be huge increase in performance.  TOR is a slowwwwwwwwww thing.  Cache will help alot.



  • Here's what I'm planning to set up. I'm concerned that the transparent proxy option would make the pfSense web UI inaccessible without the "Bypass proxy for Private Address Space" option checked also. Does that sound right? Can you look over this config, and warn me if there's something wrong that might cause me to lose access to the pfSense webConfigurator? Is there anything else that needs to be done, beyond what I've listed here? I can try turning caching on once this setup works for forcing Tor. I like the idea of faster browsing and more efficient bandwidth use with Squid.

    Services -> Proxy server -> Upstream proxy

    • Enable forwarding: Check the box
    • Hostname: 127.0.0.1
    • TCP port: 9050

    Services -> Proxy server -> General

    • Transparent proxy: Check the box
    • Bypass proxy for Private Address Space (RFC 1918) destination: Check the box


  • Will you be on the LAN? 
    If so, no.  You will not be getting locked out, especially if your anti lockout rules on the LAN are still in place.
    Do use these though.

    • Transparent proxy: Check the box
    • Bypass proxy for Private Address Space (RFC 1918) destination: Check the box


  • Yes, I will be on the LAN. What are the anti-lockout rules on the LAN that you speak of? I'm not familiar with it.



  • I got this error when trying to visit a URL:

    The following error was encountered:

    Invalid Request

    Some aspect of the HTTP Request is invalid. Possible problems:

    Missing or unknown request method
       Missing URL
       Missing HTTP Identifier (HTTP/1.0)
       Request is too large
       Content-Length missing for POST or PUT requests
       Illegal character in hostname; underscores are not allowed



  • In Firewall > rules > lan - Should be right there at the top of the list.



  • This probably means that running a TOR proxy on the same machine as Squid proxy and then pointing Squid at TOR might not be possible.  I have usually ran TOR in a separate box.  Any old out-dated POS computer will work.  Some very outdated machines are still quite reliable and perfect for this.  Interesting experiment though.

    (Another way would be to create a tiny virtual machine and use that as your TOR machine)



  • I think maybe the problem is that Tor gets pointed to Squid with transparent proxy option set, and Squid gets pointed to Tor, which creates an infinite loop that can't be used to traverse from LAN to WAN via Tor. That might be fixable, but it would probably need to be done another way that's designed to handle this kind of need.



  • Could be…  two boxes is out of the question?



  • I tried disabling Squid's transparent proxy, and then pointing my web browser's proxy configuration to the Tor instance on the pfSense machine, at 192.168.1.1:9050, but it didn't work. It seemed to be connecting, but it always times out. Because of that, I haven't yet tried it on another machine.

    If I can get Tor and Squid to work with multiple machines, I can use that temporarily, but that setup can't be accepted as the "solution" because it's wasteful both for the hardware and the power used to run it (probably also if it's a virtual machine too). On top of that, it's very difficult to make a multi-machine setup that can work for people who want to use it in a portable arrangement. However, I did find this:

    http://team.adafruit.com/onion-pi/

    Once again, the wheel has been reinvented. Although that gadget is probably quite handy like any other portable device might be, pfSense is still the right tool for the job, and I'm sure it can easily be packaged in a similar hardware form - perhaps even the exact same form.

    In System -> Routing -> Routes it looks like it might be possible to configure the LAN to connect to Tor, and maybe the WAN to correct to Tor too, but I have no idea exactly what should be done to set that up, if it is indeed possible. Until then, how is the multi-machine arrangement set up? Right now, my arrangement is like this:

    PC -> pfSense -> Router/Gateway

    I suspect a multi-machine setup would be like this:

    PC -> pfSense -> Tor -> Router/Gateway

    Except, the Tor machine would be a peer on the gateway-side LAN, and not physically blocking pfSense's path to the gateway. In that case, pfSense would need to be trusted to block any traffic directed anywhere other than to the gateway via Tor, which it is designed to do.

    Is all that correct? If so, I'll just plug another PC running Tor into the router/gateway LAN, and then what? I just configure Squid as a transparent proxy pointed to Tor's proxy at, for example, 192.168.1.3:9050, like you have already described?

    I just tried to use Squid without Tor, and I get the same error message when I enable the transparent proxy. There seems to be some other problem that has nothing to do with Tor. How can I try to connect directly to the Squid instance, to test if Squid is working at all? Then, I can narrow down what the problem is with Squid. I see there is a Varnish package too, maybe I'll try that next.



  • OK, let's see if I understand you correctly:

    • Machine 1: pfSense + Squid.
    • Machine 2: Bridged VM with Squid + Tor on machine 1.

    Is that right?



  • Yes  - It might be better if the VM running tor were on an interface not inside the transparent squid proxy.



  • OK, I set up another physical machine with Tor. I put it on the WAN side of the pfSense + Squid machine. I pointed the pfSense Squid at the Tor instance on the WAN side, and nothing worked. It looks like you're describing a second instance of Squid? What is that for? I didn't set up Squid on the Tor machine.

    Here's what I have:

    • Machine 1: pfSense + Squid. LAN 192.168.1.1 WAN 192.168.0.198
    • Machine 2: Tor. 192.168.0.199, on the same network as Machine 1 WAN.

    Machine 1 Squid proxy -> Machine 2 192.168.0.199:9050.

    I'm not sure if port 9050 is being blocked on Machine 2. It's PCBSD. Is that possibly the problem? I expected this to just work at each step of the way, so maybe we just need to keep hacking away at it until it works? With all that effort, what is the "right" way to do this? It might be better to skip this complex network of stuff and go directly to whatever is the right way. I'm not very familiar with this, as you know, but I'm guessing routers like pfSense should be able to "route" whatever to whatever, like this:

    PC 192.168.1.x -> pfSense LAN 192.168.1.1 -> pfSense Tor 127.0.0.1:9050 -> pfSense WAN 192.168.0.198 -> Internet

    Conceptually, it seems to simple to me, but I've never found anyone or any documentation that can explain how to do that. The pfSense docs don't mention anything like that, and no router hardware or firmware I've ever studied mentioned anything like that either. Tor's documentation leads to Whonix documentation, and I tried digging through Whonix docs, but it meanders and crosses topics in a kind of messy "work-in-progress" way, without ever getting to the point about how to do this kind of networking. Of course, Whonix is designed to be limited to only 2 VM's on a single PC - why, I don't know. pfSense seems to not be designed to be limited, but why does no one know how to make a route through Tor? Am I wrong, that's it's really not simple at all?

    I have wasted months on this, and I'm frustrated. Is this kind of setup so unusual that no one in the world ever needs it? I'm almost certain I'm wasting time on this complex setup. Don't get me wrong, I appreciate the help, but needing 2 machines, 2 Squids, and so on and so forth, just to achieve a simple goal that pfSense ought to be able to do, just seems like duct tape on a jackhammer. Am I wrong? I'm grasping anything. What is it about a Tor LAN that makes it impossible to obtain?



  • Thanks for the encouragement. I won't be strapping hotdogs to my chest any time soon, if I can get this working. Here's what I have:

    • Machine 1: pfSense + Squid. LAN 192.168.1.1 WAN 192.168.0.198.
    • Machine 2: Tor. 192.168.0.199, on the same network as Machine 1 WAN.
    • User PC: 192.168.1.100.

    User PC 192.168.1.100 ->  Machine 1 pfSense + Squid LAN 192.168.1.1 -> Machine 1 Squid 192.168.0.198 -> Machine 2 Tor 192.168.0.199:9050 -> Internet

    I enabled just the Squid proxy in transparent mode, and nothing broke. I'm not sure how to test whether it's working or not, but I can still get out on the internet OK, so I decided to assume it's working. Then, I pointed Squid to Machine 2's Tor, and once again, I don't know if that worked or not. I checked Tor's logs and it doesn't show any connections. When I went to ip-check.info, it showed I was not using Tor, so I think that means my PC isn't passing through Squid, and thus it doesn't matter whether the Tor side is working yet.

    I just noticed that the transparent proxy option appears to only apply to port 80. Since I'm almost always using SSL whenever it's available, that means it will bypass Tor, right? If so, that's bad.

    It also looks like Squid can't do any caching for SSL sites. It might have been nice if it could do a man-in-the-middle thing for the SSL certificates, but then I wouldn't be able to check them myself, probably. No big deal for that though, since caching isn't critical.



  • @kejianshi:

    you can always just run TOR with no squid and load the TOR proxy settings into all the browsers and chat tools etc that you use.

    I just wanted to clarify that this actually does not work at all. If you run the tests at ip-check.info, you'll see just a few examples of all the ways your IP can leak past Tor. It's really pointless to try using Tor, because if your PC knows your true IP address, then it's only a matter of time before it can be learned by attackers or casual observers. Whonix is the first solution I've seen that thoroughly solves that problem, but only for one very limited VM.

    Basically, by forcing Tor for a whole network, and blocking everything else, it's quite EASY(!) to ensure your PC doesn't know its own IP address. Then, even if you get rooted, your IP address, and thus your location, remains secret. This is why I'm so incredibly dumbfounded that no one cares about forcing Tor for a whole network. Even Whonix skips over that entire simple catch-all solution for 99.99999% of everything that's wrong with Tor. If you wanted to, you could even run a hidden service with open root access, and there's no way to learn its IP address.

    Whole-network Tor is the H-bomb of privacy, and nobody seems to have fully realized that yet. The Whonix developer, adrelanos, is aware of that, but I don't think he has yet understood how important it is as a first step to using Tor. Instead, he designed Whonix to serve a much more narrow niche that perhaps 100 people in the world will bother to use. Whonix comes with a nearly useless desktop that's so limited, it's meant to be difficult to distinguish from others just like it, even if it gets rooted. In other words, Whonix promises ultimate anonymity AND location security, at the price of being useless. So, almost nobody has heard of it, almost nobody talks about it, and almost nobody wants it.

    Step 1 is securing a location. That can be done, and it can be reasonably well-assured without sacrificing very much (slower Tor speed, UDP only with tunneling, etc). Anonymity can't be assured by any software package, and it's strange that Whonix bothers to try. There is no limit to all the ways anonymity can be lost. No amount of software, or restrictions of it, can prevent that. It's each individual's responsibility to be aware of what can go wrong. And, if someone MUST have anonymity, then they can simply use Tor Browser and turn off JavaScript, without bothering with Whonix.

    For the amount of effort that adrelanos has put into Whonix, it serves a very tiny niche, for very few people. pfSense, or anything - SOMETHING - that can force Tor and block direct usage of an internet connection - that's useful, for everyone. I am shocked that no one seems to be aware of that. Even hardcore Tor people don't talk about it.

    What I'd like to know is what the right way to do this is. Once I know that, then I can investigate making pfSense do it.



  • @badon:

    I just noticed that the transparent proxy option appears to only apply to port 80. Since I'm almost always using SSL whenever it's available, that means it will bypass Tor, right?

    I couldn't see anything in your reply that answered this critical question. If the answer is yes, then I'm wasting effort on this solution, because it won't force whole-network Tor. If the answer is no, can you explain?

    Once again, I appreciate that you're trying to help, but if this strategy with Squid doesn't achieve the goal I'm looking for, I'm sorry, but I've accidentally wasted your time, and I apologize. I'll have to find another way to force Tor. In that case, there's no need to answer the other questions I have to clarify what you've said, below. Either way, thank you very much for your help. Even if I didn't quite achieve my goal, I still have gained some familiarity with Squid and pfSense, thanks to the time you've spent with me here.

    @kejianshi:

    Proxies are subject to all sorts of "leaks" generally caused by running script.
    So, NO SCRIPT.

    What script are you talking about?

    @kejianshi:

    "Basically, by forcing Tor for a whole network, and blocking everything else, it's quite EASY(!) to ensure your PC doesn't know its own IP address."

    Only an idiot would block their clients computer to contact the router/firewall.
    That doesn't mean that you have to allow egress to the open internet to all the clients.

    What router/firewall are you talking about? pfSense? Internet-connected router or modem (that pfSense connects to on its WAN interface)?

    Who is the idiot you're talking about that would block contact to the router/firewall? An inexperienced pfSense user like me? adrelanos? "Hardcore Tor people"?

    What do you mean by "allow egress", "open internet", and "all the clients"?

    @kejianshi:

    Its not all that unusual or weird what he is asking and I doubt it requires every user on his network run Whonix.

    Who are you talking about that is asking something? Asking what? What is not unusual? What do you mean by "it" when you say "I doubt it requires every user on his network run Whonix"?

    Whonix is designed to serve a single computer, not a network, so what does Whonix have to do with a network, and why did you mention it? Are you talking about a redesigned configuration using bits and pieces from the Whonix system (Whonix workstation + Whonix gateway = Whonix system)? Who's network is it that you're talking about that has something to do with Whonix?



  • You know, the more I think about this the more I'm thinking you really want a VPN f you wish to access streaming content, HTTPS and sites that use script.



  • Haha, you're reading my mind. I'm actually using a VPN over Tor right now. The only reason is because some sites blindly block all Tor nodes, and other sites freak out and assume my accounts have been hacked if IP geographic locations change frequently. The VPN gives me control over that, but it doesn't do anything "secret" like Tor does. The biggest problem with it is that when the VPN connection drops, communication continues via my raw internet connection. So, in practice, it doesn't work.

    The thought crossed my mind that a local VPN could be used to connect to the pfSense machine or the Tor machine to ensure all traffic is being routed correctly, and nothing can escape unintentionally. Being local, the VPN connection couldn't drop unexpectedly. Also, anything that's not on the VPN connection could be blocked by the pfSense firewall.

    Or, everything that's not Tor could be blocked by the pfSense firewall, similarly to what is described here:

    http://torforum.org/viewtopic.php?f=f&t=18280



  • I have made some progress on achieving my goal of forcing no-leak Tor access to the internet using the pfSense firewall. It's not quite as thorough of a solution as I have wanted, but it's still useful because it serves the job of isolating my entire network from the internet, and only allowing connections via Tor. In the process of setting this up, I've discovered several leaks I was not aware of, and some of them were even bypassing the VPN somehow. It's been a learning experience overall, and I think I have a workable version of a simple solution, just like I wanted, thanks to pfSense. Here's what I have done in detail, in case someone finds this discussion wanting to make Tor safer with pfSense:

    1. Configure Tor to Use a Tor bridge: Vidalia -> Settings -> Network -> Bridge Settings. This will make it possible for the pfSense firewall to allow connections only to the Tor bridge IP address, and block all other connection attempts. Adding several different Tor bridges will ensure you have connectivity if one of them goes down. Using 3 different Tor bridge IP's is recommended, but only 1 is necessary to try this out. It is much easier to find mistakes if you start with only 1 Tor bridge. More can always be added later.

    The format given by the official Tor bridge service (search the web for "Tor bridge") is intended for direct addition to the "torrc" config file. Remove the word "Bridge" and add each IP and port pair one line at a time in Vidalia. That is not explained anywhere that I could find, which is strange because Vidalia is supposed to make this easy.

    2. pfSense Firewall -> Rules -> LAN: Click the green icon to disable the "Default allow LAN to any rule". The rule is usually at the bottom of the rules list. That disables all communication to the internet. Don't delete it, because you might want to re-enable it in the future (it is easy to re-add it if you delete it). Next, we allow only Tor to communicate with the internet.

    3. pfSense Firewall -> Rules -> LAN -> add new rule (click the + sign): Allow the Tor bridge IP's, and make sure the "Anti-Lockout Rule" is at the top of the rules list, and the "Default allow LAN to any rule" is at the bottom of the list (and disabled).

    Action: Pass
     Disabled: unchecked
     Interface: LAN
     Protocol: TCP
     Source: not: unchecked
     Source: Type: any
     Destination: not: unchecked
     Destination: Type: Single host or alias
     Destination: Address: Enter the Tor bridge IP address here
     Destination port range: from: Enter the Tor bridge port here (usually 443)
     Destination port range: to: Enter the Tor bridge port here (usually 443)
     Log: checked
     Description: Allow Tor bridge

    4. pfSense Firewall -> Rules -> LAN: A prompt will appear above the list of firewall rules asking you to apply your changes. Click "Apply".

    5. pfSense Diagnostics -> States -> Reset States: Existing connections will not be stopped when you change firewall rules, so you must close those connections before you can see the results of your firewall changes. Click the "Reset" button, then you can immediately reload the Reset States page manually. Because the connection was disrupted by clicking the reset button, the page will not be able to load on its own. When it loads, the reset is done (almost instantaneously).

    6. Edit your Tor torrc configuration file, and add "DNSPort 53" on a new line at the bottom, without quotes, then save the file and restart Tor. The built-in torrc editor in Vidalia did not work for me, so I only used Vidalia to find the path to the torrc file, and then I edited it with a regular text editor. You can find the path in Vidalia -> Settings -> Advanced -> Tor Configuration File. On Windows, it might look like "C:\Users\Somebody\AppData\Local\Vidalia\torrc". To use the built-in torrc editor, click the button that says "Edit current torrc".

    7. Configure your OS's DNS settings to use 127.0.0.1 as the primary DNS. If you are forced to enter a secondary DNS, you can enter 127.0.0.2 (it doesn't work and it doesn't do anything).

    8. Test your setup just to verify that you have internet access. Use a safe computer on a safe connection so that it's OK if something goes wrong and your IP address leaks out.

    9. In pfSense, check the firewall logs in Status -> System Logs -> Firewall. You should see a lot of stuff getting blocked, and only a few things passing through. Make sure those things passing through are supposed to be passing through, and also that it's ONLY passing through the Tor bridge IP's. If there is a problem, you will see it in the firewall log. Check the log frequently to be sure everything except Tor is being blocked. pfSense is good at that, so there's not much to worry about.

    10. Turn on Flash, JavaScript, and all the nasty little backdoors that Tor users fear, and use the "full anonymity test" for your web browser at http://ip-check.info/?lang=en . In every test I have run, only VPN and Tor exits have been detectable, which is exactly the way it's supposed to be!

    Because pfSense is blocking EVERYTHING except Tor, there is no way for any PC on your network to learn what IP it is using to access the internet. Because every bit of data leaving and entering your PC and your LAN must pass through Tor, there is no way anyone else can learn what your true IP is either. I setup my pfSense system with 2 separate ethernet ports, so there is physical isolation between the LAN and the WAN.

    I'm sure this setup isn't 100% bulletproof, but as far as I can tell, as long as pfSense doesn't get hacked, it would be OK for any PC on my network to get hacked, and the hacker would not be able to learn my IP address (and location). Because I'm not using Tor Browser, my activities online are still trackable with cookies, JavaScript, browser profiling, etc. Although no one knows my name and where I live if I don't tell them, the ability to track my internet usage means that, in the strictest sense, I'm not using the internet anonymously.

    If I wanted to be completely anonymous AND untrackable, I would have to switch to using Tor Browser, or even better, Whonix. I may do that when my tasks require that much protection, but for most things most of the time, I don't care if people know which websites I'm visiting. In my case, that information isn't a problem for me. It might be for you.

    To have a full-featured internet experience (with Flash, JavaScript, etc) combined with the ability to conceal my location, is good enough for me 99% of the time. I can always switch to Whonix or Tor Browser if I need more privacy than that. The pfSense firewall will still do its job of blocking everything that's not Tor, if something goes wrong with Tor Browser or Whonix. I see that surprise bugs have been found in Tor Browser before, and pfSense would have prevented the bug from doing any damage. Here's more info about one of those bugs:

    https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-tbbs

    I'm sure my setup can be improved. I've noticed that sometimes my PC tells me I've got no internet access when I actually do. That's probably because pfSense is blocking DHCP. As long as stuff keeps working, then the more the merrier :)



  • One more thing, Squid will not be effective for caching on pfSense with this setup because all connections are encrypted. There might be a way to get it to work, perhaps on my local PC, but it would take some interesting gymnastics to give Squid access to decrypted traffic so it could cache some of the data. That would be nice.



  • FYI, I polished up that info a little better and turned it into an article for LBC: 10 steps to make Tor safer with pfSense. Thanks for the help kejianshi. Even though I didn't quite get to where I wanted to go, your help eventually led me to another solution that worked for me, and will probably work for a lot of other people who ought to take a look at using pfSense. I guess that's the only part of this that I got right from the start - pfSense is the key component!



  • Another FYI, my article is now slightly famous thanks to reddit:

    http://www.reddit.com/r/onions/comments/1l15hx/10_steps_to_make_tor_safer_with_pfsense/

    http://www.reddit.com/r/privacy/comments/1l25mu/adding_more_tor_to_your_day_leading_up_to_a_total/

    I hope the attention will lead more people to try using pfSense. It's a fantastic system that more people ought to know about. Being able to so easily do unexpected stuff with it will probably get people's imaginations going. What will they think of next?!



  • Well - as long as you are happy, I am happy.  Are you using it?



  • Yes, I am using it. Further research indicated that Tor was not configured to accept external connections, so I will be revisiting this topic later. It may still be possible to force whole-network Tor, without any LAN client configuration. I have succeeded in tunneling UDP over Tor and Torifying everything using a VPN. I tested it with VoIP, and despite such a long route, the increased latency was acceptable! I fully expected VoIP to be miserable to use, but it was not much worse than using it without Tor. That was a huge surprise.



  • I just created a VLAN using pfSense, and am routing all external traffic over Tor using a Raspberry Pi 2…

    pfSense is my acting DHCP server, but the Raspberry Pi 2 is the default gateway...  The Raspberry Pi 2 is also provided Internet access using a different VLAN that's traffic is routed over my PIA (PrivateInternetAccess) VPN, but that's defaulted at my Cisco Smart Switch... So I'm double covered...

    I created an SSID on my Meraki Wireless AP just for the new VLAN so all my wireless clients that use it will be doing so over the VPN/TOR networks...

    I'm also not using SQUID at all...  Everything just works...

    If anyone is interested, I can gladly post a tutorial...

    FYI, and any traffic that shouldn't (or can't) transmit over the Tor network is being dropped to prevent leaks.

    I haven't thoroughly tested for leaks yet, but am doing so now...



  • I would be very curious to see your tutorial if you write one.



  • I posted it to my blog for initial posting…

    Here's the link: http://www.lennysh.com/create-a-tor-vlan-using-a-raspberry-pi-and-pfsense/

    Please let me know if I missed anything, or could of done anything better.

    Once I get it fine tuned, I may copy/paste it here for easy finding...



  • Just remember the spooks run their own honeypots including smaller honeypots on public websites & services in plain view.

    You can be found using TOR because in maths its possible to workout unknowns and thus you wont ever have perfect privacy or anonymity which is especially bad news for introverts.



  • +1 on the need for a TOR package. It would make setting up a guest wireless network really easy. No WLAN passwords needed and no worrying about what the guest do on the network.



  • I just found out that Intel has had backdoors in their hardware for years. Of course they claim it's just a bug, and only processors from 1995 to 2011 are affected, but there is conveniently always a "bug upgrade" that removes the old backdoor and creates a new one that will take a while to be found. With that in mind, I have to wonder if we're all wasting our time. AMD said they would review the possibility that they have a backdoor, but I'm not optimistic. Who can we trust these days?

    I don't know much about Raspberry Pi - is it running on something that is less likely to be backdoored? The thought crossed my mind that since ARM designs, but does not manufacture, that means anyone they license their design to would be able to see the licensed design specs, and spot a backdoor if one existed. Intel, AMD, etc don't let anyone look at their designs, so it literally takes a decades and a lot of luck for someone to find out about a backdoor.

    “We cannot trust” Intel and Via's chip-based crypto, FreeBSD …

    Intel left a fascinating security flaw in its chips for 16 years – here's …

    I don't know why everyone isn't talking about this, and bringing it up in every conversation that remotely involves cryptography. The Intel backdoor is so phenomenally effective that it can be installed into the CPU microcode. It cannot be detected, and it can never be removed. Wiping an HDD and doing a fresh OS install will not get rid of it. Of course, Intel claims they got rid of it in 2011, but then they introduced something that could potentially be a wireless backdoor:

    “Secret” 3G Intel Chip Gives Snoops Backdoor PC Access Alex …

    That article seems alarmist, and people criticizing it point out that a lack of an antenna would give it pathetically short range, but I completely disagree. I think the alarmist reaction is the right one. First of all, being able to gain complete access to a CPU even if it requires you to be within 10 inches of it, is more than adequate to make the backdoor useful. Simply walking past a PC might be sufficient to gain access to it. Or, what about sending RF signals down ethernet or power lines? That'd do it too. That kind of weak signal espionage is well-developed in "spook" world, and even lowly amateur radio enthusiasts are able to pull off tricks like that.

    This whole-network Tor thing is something I take pretty seriously, and I'm not afraid to turn to specialized hardware like Raspberry Pi or whatever if that's necessary to ensure Tor's cryptography can't be rendered useless by hardware backdoors. This is crazy that this even needs to be discussed, but since it does, it ought to be tattooed on everyone's forehead until solutions are found and made available. Everyone needs to worry about this.



  • IMHO if you need THAT much encryption, you're doing something really bad.  Either that or you need a titanium tin-foil hat.

    If you're really worried about it, drive 100 miles in any direction, find a home with an unsecured wireless connection, and use a throw-away Netbook each time you access the Internet via Tor.  Oh, and either steal the Netbook or pay with cash in a back alley.



  • tim.mcmanus, how much encryption are you referring to as "THAT much"? Because what I've described obliterates ALL encryption. What exactly is a "really bad" use of encryption in your opinion? How much do you think your opinion of badness matters to people who want to use effective encryption? And, most importantly, what gives you the idea that you know anything at all about what other people are encrypting?

    If you will kindly give me your login credentials for this forum, I will write your opinion for you, posing as you. I might then proceed to proclaim your love of evil and all things forbidden, once again, posing as you. You don't like the sound of that? Oh, then it looks like you need "THAT much really bad" encryption too.

    No, sir, you can take your opinion of what I'm doing with my encryption, and shove it  - into your favorite encryption tool, and then delete the key.





  • Time to loosen the tinfoil hat.



  • @badon:

    Because what I've described obliterates ALL encryption.

    Um, Tor…

    And, most importantly, what gives you the idea that you know anything at all about what other people are encrypting?

    Usually you encrypt things you don't want people to see.  You're either severely paranoid or doing something really bad.

    If you will kindly give me your login credentials for this forum, I will write your opinion for you, posing as you. I might then proceed to proclaim your love of evil and all things forbidden, once again, posing as you. You don't like the sound of that? Oh, then it looks like you need "THAT much really bad" encryption too.

    It's actually a violation of the terms of using this board, sharing of login credentials.  And I like it here, so, no, I won't share.

    No, sir, you can take your opinion of what I'm doing with my encryption, and shove it  - into your favorite encryption tool, and then delete the key.

    I thought what you were doing obliterated all encryption.  Are you sure you know what that word means?



  • @badon:

    Because what I've described obliterates ALL encryption.

    @tim.mcmanus:

    Um, Tor…

    Yes, Tor. Onion routing is fundamentally onion encryption. The only reason the onion routers don't know the source or destination of packets is because they're encrypted. No encryption, no Tor. Encryption backdoor, Tor backdoor.

    @badon:

    And, most importantly, what gives you the idea that you know anything at all about what other people are encrypting?

    @tim.mcmanus:

    Usually you encrypt things you don't want people to see.  You're either severely paranoid or doing something really bad.

    I wear clothes too.

    @badon:

    If you will kindly give me your login credentials for this forum, I will write your opinion for you, posing as you. I might then proceed to proclaim your love of evil and all things forbidden, once again, posing as you. You don't like the sound of that? Oh, then it looks like you need "THAT much really bad" encryption too.

    @tim.mcmanus:

    It's actually a violation of the terms of using this board, sharing of login credentials.  And I like it here, so, no, I won't share.

    You missed the point. Without effective encryption, you don't have to share your login credentials, they can simply be taken from you. Are you using an American-made CPU?

    @badon:

    No, sir, you can take your opinion of what I'm doing with my encryption, and shove it  - into your favorite encryption tool, and then delete the key.

    @tim.mcmanus:

    I thought what you were doing obliterated all encryption.  Are you sure you know what that word means?

    You missed the point again. The point was that the encryption key isn't required. Don't worry, you won't lose your opinion by encrypting it, even if you do delete the key.


Log in to reply