On Sun, Jun 12, 2016 at 8:57 AM, Dale <rdalek1...@gmail.com> wrote: > Howdy, > > I ran up on a video website that had some info on it. I found it > interesting and was curious about what it said and another question I > been wondering about. It mentioned using a VPN so that the NSA, my ISP > and others couldn't "see" what was going on. So, my first question, > does that work and does it require the site on the other end to have it > set up as well? Bonus question, is it easy to use on any site if it > doesn't require the other end to use it? I'm thinking of using this for > my banking/financial sites as well if it is a good idea. >
Firstly I suggest you dont consider the NSA your adversary, because; 1. They're probably not interested in you 2. If they are interested in you, just adding a VPN is not going to make much difference. So lets just consider an employee at your ISP. There's typically no need to use a VPN when accessing an HTTPS website, as the SSL/TLS already provides most of the privacy that a VPN would supply. The extra that the VPN gives you in this case is to hide which websites you're visiting. So the data is protected in both instances, but the VPN also hides the connection metadata. So if you use just SSL/TLS then your ISP can deduce which bank you have an account with. If you use the VPN as well, then cant even tell that. There are issues with SSL/TLS that could allow someone in the path between you and the bank to decrypt your traffic, and if they can do that they would be able to log into your account if the bank uses simple password/passphrase style auth. The two main SSL/TLS issues are; 1. Improperly issued certificates 2. Older/weaker crypto The trust system around certificates can be summarised as "you trust any certificate as much as you trust the least trustworthy certificate authority in your trusted certificate store". Your browser ships with many CA certificates in its trusted certificate store. Any of these CAs can issue cryptographically valid certificates for any domain. So, if I manage to fool a CA that I am bigbank.com then i can buy a certificate to bigbank.com. Or, I can just find a staff member of a CA in a very poor country and offer them a big bag of sweet cash to have them issue the certificate for me. Certificate pinning reduces this exposure significantly so use a browser that supports it like chrome or firefox. Weak crypto? Turn off all SSL, TLS 1.0 and 1.1 in the browser, and disable RC4 crypto. That might block you out of some sites with weak crypto that you may still want to use. Assuming your bank has good crypto, use chrome or firefox with the weak crypto disabled for your banking, and another browser for everything else. This is something I been wondering about and I've seen a few posts here > that bump around the edges of this question. As most here know, I use > Gentoo. It's a older install but I keep it up to date. I sit behind a > DSL modem, a older Westell one, and a Linksys router, the old blue nosed > one. Neither modem or router has wireless stuff included. Is that > hardware and my Gentoo install pretty secure for most hackers? If one of those devices is PATing your IP, then that effectively blocks all inbound sessions, so it will prevent anyone on the internet scanning your system, and attempting inbound connections. This makes you much more secure. If there's no PAT, then you need to turn off all unneeded network services (use netstat to show what ports are open), and harden any services you leave on. For example, you could run sshd with only the stricter crypto enabled (this stops most bots as they havent implemented those functions), and run fail2ban to lock out any IPs that are running password guessing attacks. > In other > words, since I don't keep the formula to run car/truck engines on water > here, would this stop most since there is nothing worth stealing here? > I'm not interested in a NSA based hardened install here, just reasonably > secure. > Ok - ignore previous comment on NSA :) > > Basically, I'm just wanting to make sure I'm reasonably secure here. > > With regular patching and the above, you should be in pretty good shape. Next step after that would probably be to look at gcc's stack protector. In gcc 4.9.0+ -fstack-protector-strong is enabled by default. And in the kernel .config set CONFIG_CC_STACKPROTECTOR_STRONG=y. Then after that take a look at hardened sources and PaX (still on my todo list)
