Secure Websites

SECURE WEBSITES ARE A SCAM

Secure websites are a scam. Actually, many scams.

This page needs to be much longer to describe the many scams involved in the concept of a secure website as it is sold to the general public. Hopefully, I will get around to expanding this page.

By "secure websites" I am referring to websites with a lock icon in the address bar. At least, it used to be a lock. Now its a thingy that defies an easy description. We have Google to thank for that. On Windows, Firefox and Edge still use a lock, Chrome and Brave use the new thingy. For our purpose here, it's a lock.

This lock is sold to the general public as indicating that encryption is being used to transmit the web page. For the most part this is true, but it is scam nonetheless (more below).

Some (many?) people assume that the lock also means that the website is actually the one it appears to be. This is not true. In the old days there was some truth to this, but it is very rarely true any more. You can very easily be using encryption while communicating with a website run by Tony Soprano and his chums.

Back to encryption.

Perhaps the original sin with websites and encryption involves direction. What is HTTPS anyway? It is a request made by a web browser for a web page. For example

HTTPS://www.mybank.com/abc.html

is a request for the abc.html page at the www.mybank.com website. Period. End of meaning. That's it. Nothing more.

Something is missing. Do you see it?

Before Donald Trump, the big lie was about entering passwords into secure web pages. HTTPS indicates the page used encryption when it traveled from the website to you. It says NOTHING about data going the other way. Nothing. Nada. Zilch. I blogged about this back around 2005 and again in February 2020: Submitting Data with HTTP and HTTPS. Long story short, some browsers warn about insecure/unencrypted data leaving your computing device and some do not. And sure, most web pages will send data from your device back to the website in a secure way, but this is not guaranteed by the HTTPS request that sent the web page to you.

The next scam involves the secure transmission that HTTPS is supposed to insure.

To have websites truly send well encrypted data is not a simple yes/no or on/off thing. It is complicated, very complicated and much of it is over my head. There are somewhere around 20 or so technical knobs and dials that need to be perfectly adjusted. Here are some:

The formula used for encryption. There are many different supported formulas and they vary in strength. Some are considered secure from hacking, some are not. If a weak formula is used the end user has no idea.
Although HTTPS has been around for a long time and appears, to the genera public, not have changed, it has changed. The underlying protocol used to be called SSL and there were 3 versions of it. Now, all these versions are known not to be secure. The last 4 versions are known as TLS and, again, the newer versions of TLS are more secure than the older versions. All this is also hidden from the end user. For years web browsers were very happy to support old versions of SSL and TLS even though all the nerds knew they were not secure.
Perfect Forward Secrecy was a minor obscure feature until Edward Snowden came along in 2013 and told the world that the US was recording Internet traffic. Sometimes the NSA could probably break the encryption and sometimes not. If they did break it, they could decrypt old recorded historical sessions if Forward Secrecy was not being used. But, that is just the appetizer here. The main course is that without PFS (as its sometime abbreviated) there is one key per website. Let me explain with an example: You go to www.mybank.com on Monday and Tuesday and Wednesday. The encryption is unlocked with the same key. I go to www.mybank.com on Thursday and my encrypted web pages are unlocked with the same key as yours. In fact, all 3 million customers of mybank are using the same encryption key for the website. If one employee from mybank, gives the NSA a post card with a bunch of zeros and ones on it, then the NSA can decrypt every www.mybank.com web page. Without Perfect Forward Secrecy, the encryption of a web page downloaded to your device is a big [expletive deleted] scam. I blogged about this back in June of 20123: Perfect Forward Secrecy can block the NSA from secure web pages, but no one uses it.

The technical complication of truly secure encryption of in-flight data has led to websites that test these many knobs and dials and issue a report. My favorite of these is the SSL Server Test from Qualys. Just looking at the Recent Best and Recent Worst list shows the huge variation in websites. Some are so bad, the test can't even run to evaluate them. Interesting tidbit: back in early 2013 the Qualys test would give a site a grade of A, even if it did not use Perfect Forward Secrecy. Then, sites got dinged for not using it and eventually, the lack of Forward Secrecy prevents any site from getting an A grade, regardless of the other 19 things it evaluates. Another tester is the Website Privacy Test from Immuniweb.

Our next scam involves the concept of a website.

This is a scam because a website is not a single thing. Websites vary in two very different ways.

One involves subdomains. Many years ago, the website for the US Social Security Administration was secure, or at least the WWW part was (www.ssa.gov). However, when people logged in to the website they were at the SECURE sub-domain (secure.ssa.gov) which was not actually secure. Every subdomain has its own profile when it comes to truly encrypting in-flite data. It is quite possible that one sub-domain may do this well, and another not. In a large organization different departments may be responsible for different sections/sub-domains of the corporate website. You can test individual sub-domains at the Qualys SSL Server Test mentioned above.

For a current (February 2024) real-life example, here are some sub-domains at the Bank of America website:
secure.bankofamerica.com
autodealer.bankofamerica.com
careers.bankofamerica.com
bettermoneyhabits.bankofamerica.com
homeloanhelp.bankofamerica.com
locators.bankofamerica.com

I tried to evaluate these B of A sub-domains at the Qualys SSL Server Test but the Bank of America has opted out of being evaluated. Not a good look. Citibank does not mind being evaluated, both their main site citi.com and their online banking sub-domain online.citi.com got an A rating. Wells Fargo also does not mind being evaluated. Both their main site and the subdomain used for their Vantage system wellsoffice.ceo.wellsfargo.com got an A+ rating. JP Morgan bandk also consents to being evaluated. Their main site jpmorgan.com got an A rating but their Careers sub-domain careers.jpmorgan.com got an A+. TD Bank gets straight As at td.com, apply.td.com and etreasury.td.com. They also get an A at onlinebanking.tdbank.com. American Express is a bit better, they get an A+ at www.americanexpress.com, global.americanexpress.com and online.americanexpress.com. They also get an A+ at their www.amextravel.com domain and at the site they use for jobs aexp.eightfold.ai. Only at network.americanexpress.com do they get a lowly A rating. As for me, this site got an A+, but not due to anything that I did. All the blame/praise goes to the company providing shared hosting for this website.
In addition, web pages consist of many pieces and these pieces are typically included from the outside. By that I mean that not every chunk of the www.mybank.com website came from mybank. Many chunks came from other sites and other companies. This too, is hidden from the general public. This website is a rare exception. So too, the KrebsOnSecurity.com website, by Brian Krebs, is a rare exception. The rule, is indicated by CNN. Their site includes components from amazon-adsystem.com, cdnjs.cloudflare.com, publishers.temorhub.com, ib.adnxs.com, pubmatic.com, rubiconproject.com, fwmrm.net and more. The lock icon in the address bar has nothing to say about these other sites.

Slightly off topic: Many of the outside data sources that are included in websites are ads and trackers. For detecting them, you can use Blacklight from The Markup.

And, the scams keep coming ...

The general public is supposed to think that if data is transmitted securely (which really means "encrypted") that it is safe. Not true.

Even on a website like this one that does not include any data from other websites and does not use sub-domains at all. Even on this site, which gets a good score in terms of the encryption of in-flight data. Even on this site, the web pages you view can be spied upon. What allows this is the lack of identity verification in HTTPS, SSL and/or TLS.

The lack of identity information can be exploited in two ways.

1. MAN IN THE MIDDLE ATTACKS

Because there is no real identity verification with HTTPS/TLS your web browser can be talking to a man in the middle attacker/spy computer rather than the website you appear to be communicating with. Your web browser talks to a bad guy server which pretends to be (for example) www.mybank.com. The bad guys decrypt whatever your computer has sent, read it and/or save it and then re-encrypt it and pass it along to the real www.mybank.com. Then, they do the same in reverse. When the real www.mybank.com sends the bad guys encrypted data, they decrypt it, save it, then re-encrypt it and send it to you.

Nerds that understand networking can tell this is happening but only if they go out of their way to look for it. The general public has no idea when this happens to them.

If you use Windows, Firefox can be your best friend when it comes to detecting this. Just hover the mouse over the lock icon. Firefox will pop-up a small bubble that says "Verified by xxxx" where the xxxx is the name of a Registrar. What is a Registrar? Part of the missing section of this page. But for this purpose, just note which Registrar is being used by the websites that you care about. Financial websites, of course, but anything else you care about. If you see the name of the Registrar change, then you are talking to a man-in-the-middle bad guy server and not the real www.mybank.com.

2. DOMAIN NAME TRICKS

But, it is not necessary for bad guys to create man-in-the-middle attacks to spy on you. Since there is no real identity checking in HTTPS/TLS, it is very easy to create a scam copy of a website using assorted tricks involving a domain name. The Domain Name Rules page on this site is your defense here as it explains many of the tricks. Simply put, if you buy an iPhone at www.apple.io or www.apple.org or www.apple.us or apple.cn or www.apple.biz or www.secure-apple.com or buyonline-apple.com or this-is-really-apple-trust-me.com, you may never get anything in the mail. Instead, expect unrecognized charges on your credit card.

THE REVERSE PROBLEM

In addition to the above issues with the lack of warning about weak encryption and other security issues, we also suffer from the reverse problem: warnings about things that are not problems.

The two main aspects of a supposedly secure website are encryption and identity verification. The ID verification is miserable, I need to expand on this a bit. But, even if the ID verification fails, we still get encryption. All the web browsers that I have used are miserably coded. Instead of saying this, they yell DANGER, DANGER, DANGER and warn about the lack of security (a purposely vague term).

You typically will see this when using a browser to communicate with a device on your Local Area Network (LAN) such as a printer, router or NAS. You typically talk to the devices using their LAN-side IP address, something like

HTTPS://192.168.1.123

The identity checking in HTTPS/SSL/TLS is based on a domain name such as mybank.com or DefensiveComputingChecklist.com. It does not work with IP addresses. Thus any device on your LAN that uses HTTPS with an IP address will generate a false warning in your web browser. Everyone knows this, yet web browsers put out mis-leading error messages.

As an example, see this screen shot from Chrome version 120.something on Windows 10.

The warning that the connection is not Private is bogus. Tere is no Privacy when it comes to HTTPS, there is only encrypted data sent to you and Identify verification. The terms "security" and "privacy" are used for marketing purposes.

The warning that an attacker might be trying to steal your information from 192.168.6.8 is also bogus. When someone really is trying to steal your information, using a scam website such as apple-online-store.edu, there is no warning.

The "CERT_COMMON_NAME_INVALID" is the only clue that the real issue is using an IP address.

The device that caused this error was a Peplink router which is where captive-portal.peplink.com comes from. And this name does not match an IP address. No device name will ever match an IP address.

Clicking on the Advanced button, produces more bogus baloney:

"This server could not prove that it is 192.168.6.8; its security certificate is from captive-portal.peplink.com. This may be caused by a misconfiguration or an attacker intercepting your connection."

As for: "May be caused by", we know exactly what caused it and Google is just too lazy to write an accurate error message. Other browsers are no better.