Being a Defensive Computing kind of guy, I am a frequent flyer when it comes to VPN usage. But VPNs have both an upside and a downside.
Previously, I wrote about an unexpected downside that I ran into while making a purchase while logged into a VPN server in another country. I won't be doing that again.
This time, a VPN interfered with a charitable donation.
I am a big fan of Libre Office. Yesterday, I tried to make a donation to the organization behind it, The Document Foundation, but my credit card was denied with a "transaction failed" error message.
At first I thought it might have had something to do with Firefox, which was in high safety mode (my term). That is, all the extensions were disabled, it was in private browsing mode and I was using a portable copy of the browser.
Firefox users can disable extensions, services and themes by running the browser in Safe Mode. Considering that browser extensions can spy on you, turning them off should be second nature.
There are a number of ways to invoke Firefox in Safe Mode. I keep an icon on my Windows desktop that starts Firefox with the "-safe-mode" parameter. Note that this does not disable plugins. From Safe Mode, I then open a private browsing window.
This is all done with a portable copy of Firefox because malware has a harder time finding the software when it runs from a non-standard location.
From a Defensive Computing standpoint, these are good steps for anything involving finances. Firefox in this mode is not as secure as Guest Mode on a Chromebook or running Tails Linux off a USB flash drive, but it is more secure than regular browsing.
As it turned out, the browser was not the problem.
After the card was rejected, my bank sent a text message, asking if that was really me. I responded that it was, and the bank immediately replied that the transaction was cleared and I should try it again.
I did, but this time I connected to a different VPN server. Having learned my lesson regarding foreign countries, both VPN servers were in the US.
The run-around this time was a bit different. After entering my credit card details, I was bounced to securesuite.net for some extra verification. There, I had to both re-enter the credit card information and also provide some additional personal information. I do so, but the credit card was again denied.
Yet another text from the bank, and, again, I confirm that it really was me. As before, they authorize the transaction and say to try it again.
This time, I stay connected to second VPN server. I restart Firefox (in safe mode), open a private browsing window and all goes well the third time. Clearly, the transaction was approved from one IP address but not from another.
What was going on here?
One guess is that the transactions were rejected because the VPN servers were thousands of miles from my home. Then too, that The Document Foundation is based in Germany may have factored into things.
Another distinct possibility is that the VPN servers are flagged as being suspicious. It is quite likely that bad guys do bad things from the VPN servers I was connected to.
On the other hand, this was a moderate donation to a charitable organization. Hard to imagine stolen credit card information being used for that sort of thing.
Secure websites are notoriously hard to do well. As such, I am in the habit of checking out the sites I deal with using the Qualys SSL Server Test. Not many get A ratings.
The site where I initially entered my credit card information was secure.payengine.de which does get an A rating from Qualys. Thanks go to The Document Foundation for choosing a truly secure payment processor.
The same can not be said for the other website, securesuite.net, where I was sent for extra super duper identity verification. The SSL Server Test shows that it does not support Perfect Forward Secrecy. There are two reasons for not supporting Forward Secrecy: incompetence or deliberately enabling a spy agency to decrypt transmissions.
Viewed in Chrome, the browser complains that "the connection to this site uses ... an obsolete key exchange (RSA), and an obsolete cipher (AES_256_CBC with HMAC-SHA1)."
Both types of certificates can use the same encryption, but only the more expensive EV certificates insure the identity of the website you are communicating with. Scam sites, such as
icloud-logon.com (I made that up) all use Domain Validated certificates. With no one validating that this "icloud" is really from Apple, bad guys can use look-alike domain names to fool victims into divulging passwords. The real
icloud.com uses an EV certificate.
Using a cheap Domain Validated certificate is truly shameful for anyone trying to make a secure financial website. Maybe, that was not the goal. Maybe the goal is merely to appear secure.
So, who is behind securesuite.net? According to the Whois information for the domain, the company is RSA Security LLC.
Bottom line: my personal information was potentially exposed thanks to the extra validation that was triggered by using a VPN. Ugh.
- - - - - - -
UPDATE March 11, 2017. Originally this article said that securesuite.net was dinged by SSL Labs for an intermediate certificate with a weak signature. I am told that this is a bug in the SSL Server testing.
- - - - - - -
Now that Computerworld, and all of parent company IDG's websites, have eliminated user comments, you can get in touch with me privately by email at my full name at Gmail. Public comments can be directed to me on twitter at @defensivecomput