TechRepublic members are asking some excellent questions on how to ensure secure Wi-Fi connections while traveling. As an occasional road warrior, I have garnered a great deal of respect for the serious road warriors and their ingenuity, committing their hard-earned advice to memory. In appreciation, I’d like to return the favor by providing additional tips and maybe some insight with regards to Wi-Fi security. My first posting “10 Wi-Fi security tips for road warriors” started this informal series and TR member Jhelliot recently asked the following important question:
“When using a laptop on an open WIFI network to connect to banking like CIBC or TD which has 128 encryption, How secure is the info you are sending and receiving?”
I was going to answer the question in the discussion area, but the topic is a serious one and deserves its own posting. I wish the answer was simple, but it’s not. We all know that on-line banking involves some risk, but do we know what the risk factors are and how to mitigate them?
Security zones revisited
To understand security requirements, it helps to divide the electronic path from the Wi-Fi enabled mobile computer to the bank’s web server into three distinct security zones. In the posting “Wi-Fi security for the road warrior; revisited” I described the concept of security zones in detail. This approach should make it easier to determine what security measures will be the most effective.
On-line banking and SSL/TLS
Banking institutions must abide by strict governmental regulations and are very adept at providing security for personal information. All financial institutions (any organization wanting secure Web browsing) use Secure Sockets Layer and the newer Transport Layer Security (SSL/TLS) protocol to provide secure digital communication links to their websites. Remember to look for the secure lock symbol in the browser window and make sure the URL address begins with https and not http. That’s how to tell if the SSL/TLS VPN tunnel is in place.
Even with everyone being familiar with this concept, it’s important enough to make sure we are all on the same page. So let’s review the process:
Step 1: Go to the bank’s on-line banking Web page, your browser then communicates the fact that it wants to setup a SSL/TLS tunnel with the bank’s web server.
Step 2: The bank’s Web server creates a session encryption key, which is a random number chosen only for that session.
Step 3: Using public key cryptography, the bank’s web server securely sends the session key to the customer’s Web browser. Once the session key (only known by the customer’s Web browser and bank’s server) is exchanged, the customer’s browser will use it to encrypt any digital traffic sent between it and the bank’s server.
Step 3: Since the session key is a symmetric encryption key, the bank’s server then uses that same session key to decrypt the digital traffic that it received from the customer’s Web browser.
Step 4: If a response is required, the bank’s server then uses the same session key to send encrypted information back to the customer’s Web browser.
Essentially a secure, encrypted, virtual, digital tunnel (whew) is created between the customer’s Web browser and the bank’s Web server.
Is SSL/TLS secure enough?
The SSL protocol does create a secure tunnel that traverses all three security zones, which means the digital traffic should be secure and not allow any kind of capture and analysis by attackers. Right?
Well, not exactly. In theory, the encrypted SSL tunnel is bullet-proof. If digital traffic happened to be captured by an attacker, it would appear as complete gibberish and almost impossible to decrypt. It may seem like I’m hedging by saying almost impossible, but I’ve learned to “never say never” when discussing security or cryptography.
What’s the problem?
The problem has to do with authentication. Is your web browser directly linked with the bank’s web server? Sure, there’s an authentication certificate that tells me I’m associating with the bank web server. OK, now for the million dollar question. Are you sure the authentication certificate is real? If you’re not sure about this process, please read “Hacking Online Banking and Credit Card Transactions and How to Prevent It” by Daniel Hoffman. I consider Mr. Hoffman’s explanation to be exemplary. He’s able to take a very complicated subject and explain it so even I understand.
In a nutshell
Attackers are able to inject attack computers between the customer’s computer and the bank’s Web server. Creating circumstances that allow the attackers to steal the customer’s bank logon information and that’s pretty serious. Again, please read Mr. Hoffman’s article, understanding how fake SSL authentication certificates are used is paramount to preventing the SSL Man in the Middle (MITM) attack.
Get ready for another security concept of mine: Most attack vectors are designed to compromise the first and last hop of any digital connection. Even though a SSL MITM attack can occur anywhere along the connection path, the weakest links are the devices at either end of the connection.
First: Wi-Fi especially public Wi-Fi access creates conditions that SSL MITM attackers just love. The attack requires very little effort (no wires) to covertly inject a MITM configured computer into the traffic path.
Second: Decrypting the captured data isn’t trivial, so the attacker would prefer mounting the attack as close as possible to the source, eliminating all ancillary digital traffic.
Are there any safe methods?
Before discussing what to do, I would like to get somewhat philosophical, if I may. Simply put, there is no for sure “black and white” answer on how to create secure connections. Every solution can be compromised if an attacker is motivated enough. The solution that comes closest to affording complete security is an IPsec VPN connection, as the VPN tunnel reaches across all three security zones. Having everyone use an IPsec VPN maybe required in the future, but as far as I know it’s not an option offered by financial institutions at this time.
Road warriors having the option of using their employer’s VPN access to tunnel through to the Internet are reaching past two of the most attack-prone security zones. That is a definite plus and can be the best solution if available. I felt compelled to use worst case scenarios for this post. Which in my mind meant not using any outside support. Besides there are many occasions where it is not possible to setup a VPN due to perimeter router/firewall port configurations.
Okay. I need to access my bank account via the Internet from a public Wi-Fi hot spot. I would use one of these two following options:
First option: I would use an IronKey device to setup a TOR-like SSL session with known (known is important) IronKey TOR servers. Then I would login to the bank’s web server using the log on web page. This creates a SSL tunnel within a SSL tunnel until the digital traffic exits from the last TOR server. After that, there’s still the single SSL tunnel connecting to the bank’s web server. This virtually eliminates any chance of the SSL MITM attack working.
Second option: This is the option I prefer, albeit more cumbersome to setup and requires other hardware. I again use an IronKey device to setup a SSL session with IronKey’s TOR servers. I then go to LogMeIn’s home page via SSL. Once again, I have created a SSL tunnel within a SSL tunnel until the digital traffic exits from the last TOR server. After that, there’s the single SSL tunnel connecting to the LogMeIn web server. Using LogMeIn I access my home computer. Once that SSL tunnel is setup I am virtually using the home computer as if I was there. On that computer, I would then open the web browser, go to my bank’s website using yet another SSL tunnel, and finally login. This option eliminates any chance of the SSL MITM attack working. This option has a second advantage, which is not transferring any sensitive information back to the computer I’m actually using.
There are other options; in fact, Chad Perrin describes a very good approach in his post, “Use OpenSSH as a secure Web proxy.” I like the two options mentioned above, mainly because they have a better than average chance of working. On many occasions, port sensitive applications will not work due to router or firewall configurations at the Wi-Fi hotspot.
Finally, I hope I was able to answer Jhelliot’s question by explaining the SSL process and its shortcomings when public Wi-Fi is used.