WiFi Security

COZICAN

Recycles dryer sheets
Joined
Aug 18, 2018
Messages
255
Location
YUKON,OK
I have never done anything financial on my phone other than look at my credit card or bank statement and even then I always do it under my secure wifi connection. That said....I'm wanting to buy an IPad mainly so I can sit in my backyard and do the things I normally do on my desktop. Do you feel secure accessing your VG, Fido, TDA etc accounts on your own secure wifi? What about on other wifi (restaurant, airport etc)? I've always been leery of wifi on general. But then again it is 2019.

Coz
 
All of my devices, laptop, iPad and iPhone are connected to the internet via my home’s secure WiFi, so if I didn’t trust it I would never do any financial transactions electronically.

I never do financial transactions over public WiFi networks such as hotels, malls and cafes, however I do trust the data connection (3G, 4G etc) through my iPhone and often do financial transactions, particularly using Apple Pay which is everywhere here.
 
I trust my home WiFi security and regularly check/update the router firmware.

Outside the home my phone will auto-connect to secure hotspots from my provider (Spectrum aka Time Warner) and I feel OK with that but don’t need to connect with financial institutions/brokerages, those can wait.

If I’m using a wide-open hotspot somewhere, I have a VPN available but not often used.
 
My home wifi is secure, so I'm comfortable using it. Wireless and wired.

Note, if you use wired at home to a router with wifi, and if the wifi is not secure, someone can get on your network to try to see your wired machine activity. So just using a wire does not mean nobody is looking.

I now have VPN to use when traveling so that makes me feel better about outside use, even just getting email.
 
If you have to type a password for the WiFi and your connection is https, it's probably going to be fine. If it's your own home wifi and has a non obvious password, you're fine because your devices will be the only ones connected. In a restaurant WiFi, if you have to type a password, you're in ok shape, but there's the possibility that bad actors are also on the restaurant LAN and so your device could be attacked. But if you apply updates to your OS, then there are probably no attack vectors open for exploitation. In any case, I don't use wifi without the lock/password (don't use open WiFi) for any web browsing that requires a password. You can tell which of your friends use open WiFi when you see spam emails coming from them.
 
Last edited:
With security enabled on my personal wireless router (e.g. WPA2), sure.
 
So long as your web transactions are to sites that connect via https rather than http, the security or lack thereof on the WiFi connection isn’t important. Your communication is encrypted within your browser and decrypted at the destination host. Furthermore, the browser authenticates the destination to ensure it isn’t being faked. Only sites like early-retirement.org which allow or use http connections are at risk. Any username and password you use when logging in to this site goes over the Internet in clear text. WiFi security may encrypt the hop from mobile device to the wireless access point, but doesn’t help for the remaining router hops to the destination unless each in turn uses link-layer or transport-layer encryption. Even with all that the destination isn’t authenticated.

(Just before I retired, one project I worked on was a tool designed to stress test TLS software libraries to ensure they were robust and conformant to Internet standards(RFCs). TLS is the protocol used in https web connections.)
 
Last edited:
........................... Only sites like early-retirement.org which allow or use http connections are at risk. username and password you use when logging in to this site goes over the Internet in clear text. .....................................

Thanks for your observation about this site. I had never noticed before that this site (unlike any of the 10 other sites I have on my toolbar) does have the plain http (w/o the s) when using it. However I believe that when you log in, it does have the https but switches to http after log in step is completed.......at least for my Mac. Is there a security issue then if you are not posting "secret" stuff?
 
Thanks for your observation about this site. I had never noticed before that this site (unlike any of the 10 other sites I have on my toolbar) does have the plain http (w/o the s) when using it. However I believe that when you log in, it does have the https but switches to http after log in step is completed.......at least for my Mac. Is there a security issue then if you are not posting "secret" stuff?

More info about ER.org security here: http://www.early-retirement.org/forums/f32/not-secure-93581.html
 
.
Only sites like early-retirement.org which allow or use http connections are at risk. Any username and password you use when logging in to this site goes over the Internet in clear text. WiFi security may encrypt the hop from mobile device to the wireless access point, but doesn’t help for the remaining router hops to the destination unless each in turn uses link-layer or transport-layer encryption. Even with all that the destination isn’t authenticated.
From the page REWahoo linked.
The login pages here are secure (httpS) but as noted by many, the rest of the site is not. We store no financial info or other sensitive content here and we long ago changed login pages (where password data is passed) to meet current security standards.

The primary reason for not changing the rest of the site is that we have thousands of links in posts to offsite images and content that are not https. ALL those links would break. As the www updates it will be easier to make this change but for now we would rather retain that content then break it.
 
With security enabled on my personal wireless router (e.g. WPA2), sure.

Bingo, if you are not using WPA2, I would not call your home network secure.
 
When using Web browsers, it’s easy to tell if you’re on a secure connection either through the “https” URL/protocol displayed or some type of lock symbol shown by the browser.

I wonder (due to my lack of knowledge) about mobile apps. Are there standards in the underlying software that enforce security/encryption between the app and its connections to external systems?

For example, I just logged in to my Fidelity account using their app, which I expect is very secure and requires authentication through explicit password or other ID (touch, face), but see no indication on the app that the connection is secure.
 
Last edited:
When using Web browsers, it’s easy to tell if you’re on a secure connection either through the “https” URL/protocol displayed or some type of lock symbol shown by the browser.

I wonder (due to my lack of knowledge) about mobile apps. Are there standards in the underlying software that enforce security/encryption between the app and its connections to external systems?

For example, I just logged in to my Fidelity account using their app, which I expect is very secure and requires authentication through explicit password or other ID (touch, face), but see no indication on the app that the connection is secure.

All iOS applications are currently required to use App Transport Security - which is built on https and enforces TLS 1.2 (1.3 was ratified in the last year, so I expect they will be moving to this level soon). This doesn't apply to websites in a browser, but apps downloaded via the App Store.
 
All iOS applications are currently required to use App Transport Security - which is built on https and enforces TLS 1.2 (1.3 was ratified in the last year, so I expect they will be moving to this level soon). This doesn't apply to websites in a browser, but apps downloaded via the App Store.


Thanks! A quick Google search turned up more details on App Transport Security, of which I was formerly unaware. Apparently introduced in iOS 9 and MacOS v10.11.

As an Apple device user, I feel a bit more confident. All before brunch!!
 
I do not know what secure is these days. It keeps changing as the black hats outsmart the latest white hat security fix.

We do not like accessing our finances when we travel but we really have no choice. We are of course as careful as we can be in using public wifi or ATMs. No issues yet after 8 years of frequent international travel. We never pay with a debit card when travelling. Either cash or credit card.
 
I did add a VPN to my phones for use away from the house. I have it set not to go on when using my home wifi or a cellular network. However, if I'm doing anything financial away from my house, I will turn the VPN on, even on a cellular network.
 
VPNs seem like be a good idea except that there are many VPN's that are black hats.

I wouldn't trust a "free VPN" or even paid ones unless you trust the company offering it. And it's hard to know who to trust. You can trust your employer's VPN, but who has one of those!!!

Search (may I suggest DuckDuckGo) for "VPN scams" and read all about them.

Unless you are trying to hide your location (for Netflix say) a VPN doesn't really buy you much if the apps you are using are using good security practices. I would *hope* Fido, Vanguard, most banks, etc. do so.
 
When away from home and using free wi-fi (even the login kind), I use a VPN along with my browser to access email or the internet. The whole reason to use free wifi is to avoid data charges. On my phone, if I should need to access my bank, I use the bank's app, not my browser - with VPN turned off!

VPN hides the IP address, and banks will refuse entry to their sites if they can't see your location. Using their app removes the issue and the entire transaction is secured. The only other alternative to doing financial transactions when away from home is to use a phone with data turned on.
 
https is good, but you still are trusting the WiFi hotspot. The attack vector is a man in the middle where you ask for https:/BofA.com, and it sends you to https:/B0fA.com and presents you with an identical login page. It's a fairly sophisticated attack, but not unheard of.
 
https is good, but you still are trusting the WiFi hotspot. The attack vector is a man in the middle where you ask for https:/BofA.com, and it sends you to https:/B0fA.com and presents you with an identical login page. It's a fairly sophisticated attack, but not unheard of.

https is designed to avoid that type of man-in-the-middle (mitm) attack. It uses public/private certificates and keys. The browser asks BOfA.com to send a confirmation encoded with BofA.com’s private key. The BOfA.com guy doesn’t have BofA.com’s private key, so encodes using its own. When the browser then attempts to decode using BofA.com’s public key it wont decode correctly and the mitm attack will be detected.

One may ask how the browser got BofA.com’s public key and not BOfA.com’s public key - well a browser is pre-populated with a handful of public keys of central “certificate authorities” (CA) (https://en.wikipedia.org/wiki/Certificate_authority) that are trusted repositories of certificates/public keys of other sites, such as BofA.com. There are some techniques designed to minimize problems with tainted browsers containing subverted CA certificates or keys. One has to both subvert the CA keys in the browser and intercept and respond to all traffic appropriately to fake the user. Exceedingly hard to pull off.

Lots of material on the net explaining how some of this stuff works - but I haven’t run across any simple explanations.
 
The look-alike domain has a legit cert that's signed by a CA, so doesn't throw any alerts to the user. The only defense is the user noticing that the domain doesn't match. The way the TLS handshake works, the MITM is able to insert themselves...they open a real session to BofA and send the user a copy of the login page, but from a domain of B0fA, which is a TLS session that uses a signed cert. The bottom line is that you should be on guard, double checking the domain and https status when on wifi that is controlled by someone else.
 
The look-alike domain has a legit cert that's signed by a CA, so doesn't throw any alerts to the user. The only defense is the user noticing that the domain doesn't match. The way the TLS handshake works, the MITM is able to insert themselves...they open a real session to BofA and send the user a copy of the login page, but from a domain of B0fA, which is a TLS session that uses a signed cert. The bottom line is that you should be on guard, double checking the domain and https status when on wifi that is controlled by someone else.

The cert signed by the CA would be for B0fA.com (unless the mitm convinced the CA they were BofA.com; this a known weak point.) If the user correctly types BofA.com the cert sent by the mitm would be for B0fA.com and the browser would note that the cert is not for the domain requested (bugs in browsers and TLS libraries sometimes include failure to properly determine the cert is valid! Part of a typical test suite is to verify the browser/agent rejects such certs.) The way certs are signed makes it almost impossible for a mitm to substitute some other domain into their CA signed cert - they would have to know the CA’s private signing key to re-sign the cert.
 
When away from home and using free wi-fi (even the login kind), I use a VPN along with my browser to access email or the internet. The whole reason to use free wifi is to avoid data charges. On my phone, if I should need to access my bank, I use the bank's app, not my browser - with VPN turned off!

VPN hides the IP address, and banks will refuse entry to their sites if they can't see your location. Using their app removes the issue and the entire transaction is secured. The only other alternative to doing financial transactions when away from home is to use a phone with data turned on.

VPN does not hide the IP address, it shows to the bank an IP address of the VPN server, which can be in a foreign country (if you want).

I use VPN now on my phone internet, to hide when I'm going next on the internet, even if its encrypted, the part where you say you are going to the Bank before the TLS handshake is plain text, but being on VPN means this is encrypted as well.
It will prevent MITM attacks (which are super rare).
 
The cert signed by the CA would be for B0fA.com (unless the mitm convinced the CA they were BofA.com; this a known weak point.) If the user correctly types BofA.com the cert sent by the mitm would be for B0fA.com and the browser would note that the cert is not for the domain requested (bugs in browsers and TLS libraries sometimes include failure to properly determine the cert is valid! Part of a typical test suite is to verify the browser/agent rejects such certs.) The way certs are signed makes it almost impossible for a mitm to substitute some other domain into their CA signed cert - they would have to know the CA’s private signing key to re-sign the cert.
The cert would be signed by B0fA.com, true. The user types BofA.com, true. The MITM can't present a signed cert for BofA.com, true.



The thing is, if I've got evil software on the WiFi hotspot, I recognize you want to go to BofA.com and before the TLS handshake, I redirect the browser to B0fA.com. These redirections happen all the time in legit situations, so that isn't considered nefarious. So yes, the user first typed BofA, but they end up with a secure connection to B0fA and there's no alert presented because B0fA has a signed cert. If the user sees a legit looking login page and doesn't notice the difference in the domain name, they're pwnd.


There's probably a better or more technical description of this attack out there on the internet somewhere, but I'm sure it's a standard attack vector.
 
VPN is a very good thing to use when out of your home, but it's not 100% perfect. 99% maybe, but just be aware of possible problems that may or may not be related to the VPN usage.

Here's a good discussion from the very well respected Krebs:
Post-FCC Privacy Rules, Should You VPN?
 

Latest posts

Back
Top Bottom