The curious case of insecure HTTPS certificates
Published: 2019-08-09 16:53:41

This article is a first in series of explanations to all claims done by our former colleague that claimed he found numerous security and performance issues in our project shortly after joining our team.
You can [find the preface here](https://dev.to/slavius/your-code-has-lots-of-security-and-performance-issues-he-said-24c7).

Lets have a look at the first claim:

> I guess that we transfer data from GUI to the API server probably with HTTPS , but this is not enough. Because a person can easily get a SSL certificate with DNS spoofing and listen to the packages. So the first thing is , We are sending our password for login or any other transaction as a plain text and then we will only encrypt it on DB. We must also encrypt the passwords on the client-side with another salt or another type of encryption when we want to send a request like LOGIN function. (recommend different salt for different customers)

First question that should come to our minds is; why would everyone including huge international companies like Microsoft, Google, Mozilla and Intel invest so much time and money into developing support for HTTPS and SSL/TLS into basically all web browsers, improving SSL/TLS protocols with enhancements, bug and performance fixes, forming certification authorities and creating selling points of certificates for companies and individuals when based on this description it seems to be totally trivial to overcome the whole protection of SSL/TLS and certificate based security??? 
How would you justify in your company buying a $199 EV SSL certificate for just one site for one year if this would be true?

Let's first start with how SSL certificates are obtained. Most certification authorities (from now on called CAs) require you to prove your personal identity to get basic certificates. This can be accomplished e.g. by validating and assigning your e-mail address to your CA account. For so called EV (Extended validation) certificates - that give you this well known "green lock" in the browser's URL bar, you need to undergo a more strict procedure in addition to the personal verification by e.g. faxing/photocopying a company certificate, address and/or validating your relationship by making a phone call from a phone-number associated with your company in public registry, or receiving a validation code using postal service delivered to your company postal address. This guarantees that nobody else without access to your e-mail, private company post box, office or phone device can validate him/her-self as company representative to gain EV validation for your company at the CA.

Now that you have validated your person or company you need to actually prove you own the domain you'd like to get certificate for. Of course e.g. google.com domain is no more owned by Google company (it's now called Alphabet) so when you are validated as a company you are eligible to request any domain certificate not only one that matches your company name.
For this purpose you have to alter the public DNS records or your HTTP server settings to return expected response to your CA request. E.g. you may be asked by your CA to set up a special DNS record with name d24ecd160f4443b5ba55374b15516fc3.yourdomain.com that points to their server or return specific TXT response; or that by visiting URL http://yourdomain.com/d24ecd160f4443b5ba55374b15516fc3.txt you present a content from a text file delivered to your previously validated e-mail address by the CA.
This way only person that has access to the DNS management of your domain and a web server that your DNS records points to, is able to successfully validate certificate request by the CA.

As you can see without extensive social engineering, wiretapping, breaking into someone offices or post box at the right time, hacking your DNS provider and server hosting it is quite hard to request a certificate to arbitrary domain name on someones behalf.

Let's be honest and say that in the past, there were some incidents where due to human errors and heavy social engineering some less known, smaller CAs erroneously issued certificates for different company domains like Google. This can happen but it was soon discovered and corrected. In this case certificates must be invalidated (revoked) and new ones for affected sites re-issued. For this purpose each CA exposes so called Certificate Revocation List (CRL). These lists are checked by your browser by each time an access to certificate protected site is made, to disallow access to sites that are compromised and served with certificate already revoked by the CA.

So now when we've explained how it is hard (not impossible) to fake a certificate let's explore options how this actually can be done without any user even noticing!

And here everything boils down to trust. The easiest way to convince someone he's accessing a perfectly valid and secure certificate protected site is by lying to him. What does that mean you ask?
The whole sense of safety is a result of you relying on your browser to tell you if the site you are visiting is fine or there's something fishy going on by looking at the browser error displayed when you visit misconfigured or fake site.
**Rule number one: Use only web browser downloaded from verified source**
Never ever download a web browser from untrusted sources (download sites, warez sites, custom browser builds on GitHub, etc.). It may be tempting to have an "Un-Googled Chromium" - perfect browser based on Chromium with Google spyware removed (TM). The only source of these browser builds are random people on the internet. You may get a browser that was built from official GitHub repo with Google stuff removed but sneakily one CA certificate added that is under control of an attacker. Results may be disastrous. By having an attacker controlled CA certificate bundled into your browser one can, in addition to DNS spoofing redirect you to an attacker controlled server hosting an exact copy of Gmail login page. Just type in the credentials and they will be sent to the attacker's server without you even noticing!
Some browsers do not come with CA certificates bundled and instead rely on the operating system CA certificate store. There is also a risk associated with it because the code in the source code of this untrusted browser download may have been modified to use internal CA certificate bundled in it.
In case of browsers like Internet Explorer running on Windows without antivirus combined with untrusted applications from unverified sources can result in system infection that imports own CA certificates into Windows/Linux CA store. All browsers using these store would then be compromised even if the browser itself comes from verified vendor's site.
**Rule number two: Run antivirus combined with software from trusted sources**
Do your job and verify downloaded file's hash with the one the vendor provides. Most of them do now!
An alternative would be to run regular browser in a sandbox or Virtual Machine and only use trusted browser on your main operating system to access important sites (banking, mails, company portals, social media, etc.)

Some attacks are also possible on insecure networks, especially public WiFi. Here the claim about DNS spoofing comes to effect. Although without compromising your operating system and/or web browser it's hard to fake certificates, what can actually happen is that your request to gmail.com will be handled by the DNS server under attacker's control and you will be redirected to similarly looking gmial.com domain with valid certificate. It is common to do this kind of tricks as user's don't usually check what they typed in after the page they receive looks what they expect it usually does. Similar typo-based domains are registered and pretend to be their original counterparts so always beware on untrusted networks. Use your own DNS settings paired with DNSSEC or DNS over HTTPS or use VPN to browse the internet. Or if you have such option, do not connect to unknown networks and use cellular network instead.
**Rule number three: Never trust unknown networks and use VPN if you need to**

Hope you enjoyed this post and thank you for reading!

In the next part we can have a look at why may accessing even self-signed certificate sites be secure in some cases and what it means to establish an SSL/TLS session with remote host.