If I log onto my bank’s website using a VPN, wouldn’t I be linked to that VPNs IP address which just might so happen to be used by thousands of other people…some of which might do shady stuff on that VPN. So if the bank/FBI/etc wanted to investigate me, they can say I am linked to those shady activities because of my ip address.
Therefore wouldn’t it be safer to use the IP address that your ISP gives you for things which requires your personal information? And use a VPN for all anonymous browsing?
Most banks have a secure connection anyways (https instead of http), but I normally just leave my VPN running all the time anyways. I would not think it matters too much.
As long as you’re using HTTPS, neither your ISP nor someone on your local network will be able to intercept your credentials. You should avoid any site without HTTPS: even if you’re not sending sensitive data, unencrypted traffic opens you up to MITM attacks.
With HTTPS, however, people would see what sites you’re visiting and any subdomain within them. The same goes for your VPN.
The advantage of using a VPN would be in the realm of operational security: maybe you don’t want to let your ISP or people on your network know that you’re visiting a particular site. Maybe you’re using a public network, and you don’t want someone to know that you’re accessing your bank’s website, as they might take an interest in you and try to pop your box in order to get access to that data.
As far as linking shady activity to you, through the VPN’s IP address: the bank knows the IP from where you’re accessing your account, but it’s probably not tracking other activity from the same IP. The FBI and any other law enforcement agency already know whether an IP belongs to a VPN provider or not. In any case, it doesn’t matter. You can always say: “I was using a VPN, these are my credentials. That IP belongs to that provider, not to me. I’m not responsible for what other users do”.
If you want to hide the fact that you’re visiting a particular site, use a VPN. If you don’t care, it won’t make much difference. The bank might contact you to know if you’re the one trying to accessing your account from a particular location, but it probably won’t be a problem.
You are right, using public vpn to connect to financial institutions may just add inconvenience by triggering additional verification checks and confirmations when the institution detects that you are connecting from such unusual place.
There is no value in using vpn for that — you don’t need anonymity, secirity is already provided by https, and you would avoid those extra security checks.
If you can swing it, I would use a specific device to log into sensitive websites like this. Maybe an old beat up laptop that has a fresh install. And i wouldnt use the VPN when logging into my bank.
The FBI will know the IP block belongs to a VPN, and won’t waste their time going after everyone that connects through it because the address is “linked”.
The FBI is not going to investigate everyone who is using a specific shared IP address. If someone did something bad through a shared VPN IP address they will first have to find information that narrows their search down. Otherwise it’s a waste of time to investigate potentially hundreds of thousands of people based off an IP address alone.
My personal belief is you should not use VPN for anything personally identifiable UNLESS you 1) are trying to hide your use from local ISP, Work, School, or a hostile government* -OR- 2) You need access to content or services that are region locked or blocked by local ISP, Work, School, or a hostile government*.
Remember that some governments may view using a VPN as a crime or have ways of interception and decryption. I read a white paper once that estimated over half of VPN providers have misconfiguration that would allow governments access to what was sent/received from the VPN. While I would hope this is improving, I wouldn’t count on it.
You verify the integrity of the packages through cryptographic signatures. APT doesn’t use HTTPS on the premise that it doesn’t matter if someone sees what package you are downloading, as long as they’re unable to forge them or modify them in transit. That’s the protection against MITM attacks: the signature doesn’t match, you discard the package.
If you’re accessing to your bank’s website, you type your credentials. It matters a lot if someone is able to see them in transit. Even if you guarantee that they’re not modified in transit, if they sniff them, they get access to your account.
You should avoid any site without HTTPS: even if you’re not sending sensitive data, unencrypted traffic opens you up to MITM attacks.
Bank account credentials and other fields you need to fill would classify as sensitive data. I was taking issue with the fact that you said to avoid HTTP(entirely?). I obviously use HTTPS whenever possible, but I’m not necessarily going to refuse to use an applet etc. only available with HTTP. I’m not sure what kind of MITM attacks you are thinking of. Do you mean file format exploits such as how PNGs were handled in Android.
I must confess that “Ahem” left a lot of place to guess what you meant. But I think we’re on the same page:
use HTTPS whenever possible
I consider that’s the best approach. If you must use it, use it. But if you can avoid it, you’re probably better off doing it.
Obviously, not everyone has to worry about someone actively trying to exploit unencrypted connection on their home LAN or even on a public network. Threat models for regular users don’t include these sort of attacks as they might be complicated enough that it’s not worth the effort.
That’s not the sort of exploit I was thinking. I was thinking something more of a hands-on approach in manipulating data packets.
If you don’t encrypt the content, you might loose sensitive data. If you don’t validate its integrity it can be modified in traffic: you could forge and replace some of the packets going to certain device; and since most packets give you information about application, versions of services running, etc. you could try to exploit some of the software being used. For example, you know of a vuln on Firefox and you can see that someone on your network is using that browser to view an unencrypted site; now you can inject packets into the network pretending to be that website, including the payload to exploit Firefox when it tries to process the “data”.