Certificate You Trust

We already know that over 50% of global web traffic is SSL/TLS encrypted and it was not just a singular event, but rather a steady trend towards 90% expected in 2019. It's critical for our online life, especially when using internet banking or trusting the source of the information we are reading.

At the base of SSL/TLS lies the x.509 infrastructure making sure that at least the server side identity can be verified by the client (and sometimes the client can be identified as well). It works quite simple - your browser has got the list of Certificate Authorities (CAs) and their root certificates used to sign the chain of secondary certs that legitimise the websites you access.

Here the TRUST kicks in:

• you need to trust the browser maker to embed the right root certificates
• you need to trust the CA that they follow internal policies used to check the identity of entities applying for certificate issuance and the entire process of certificate issuance is duly followed uninterrupted and not influenced by any third party - basic`lay that they give certs only to the parties they know are true and that no-one else can generate the certs on behalf of the real CA (eg. having access to their root cert and signing whatever they want)
• you need to trust your network provider (public ISP, local cafe WiFi hotspot, your corporate network) to not manipulate the SSL/TLS traffic
• you need to trust your browser is displaying properly the website certificate properties with all possible caveats, errors, warnings etc. - the worst case being your browser modified by malware to mislead you and accept the maliciously tempered certificates

In the attempt to amplify the visibility of certificate properties, the Extended Validation (EV) version was introduced couple of years ago. Most browsers emphasise the EV cert presence with some additional highlights like the colour of the font or displaying full name of the party owning the website. This way users can quickly identify "safe" HTTPS site. Of course some malware found a way how to mimic this protective behaviour by working in full screen mode and covering real browser window with the fake messages misleading the user.

But it's just one of the many "certificate sins" abusing your trust and making way to the huge growth of attacks through encrypted channels. Just look at the recently discovered massive amount of certificates issued by Let's Encrypt and used in phishing campaigns against PayPal users. Over 15000 of such certificates!

Let's Encrypt is a Linux Foundation initiative supported by major vendors and aimed at quick adoption of SSL/TLS standards. It should remove the main blocking factor - expensive x.509 certificates. Acting as CA it automates and issues free certificates so virtually any website can switch to HTTPS almost instantly. This specific practice, which removes expensive credentials checking process to make x.509 accessible also enables the criminals to issue any cert they want. Such certificates can be then used to phish for the users who have almost no way to verify that the site they are accessing is not really affiliated with they party they intend to connect. Instead of updating their PayPal account they can be easily redirected to the server owned by the attackers and give them their personal details and passwords. All inside a browser reporting the connection is safe, displaying a padlock and showing a valid certificate with a name similar to PayPal. Who wouldn't be fooled by this trick?

Public, free CA like Let's Encrypt were planned to increase the usage of SSL/TLS, but if the policy of issuing a certificate is breached, the trust model crumbles. Symantec, having 30% market share of all EV certificates, was recently queried by Google regarding issuance of certs without any control, especially related to Google and Opera sites. It seems that the Symantec allegedly highly secured CA infrastructure was accessible by third parties who could generate any arbitrary certificate and violating the CA practices. As a result Google has removed the recognition of EV certs issued by Symantec inside the Chrome browser, in order to protect the users against any abuse of the trust.

If you add the simple fact that the list of CAs inside your browser includes government-owned entities that can be ordered by such governments to do whatever is needed by the national security, the "trust issue" becomes really painful. Such certificates can be forced to be included because of the local regulations and then subsequently used for SSL/TLS interception. The encrypted traffic is subject to easy Man-in-the-Middle (MitM) attack where the intermediate network equipment is pretending to be the server to the user and terminating the encrypted tunnel. For the connection to happen, the user needs to see a certificate his/her browser would accept, so it's usually a wildcard (matching all sites) cert signed by such government CA. It is applicable to all sites so there is no difference between the trusted ones and fake ones.

SSL/TLS interception doesn't need to be a bad thing for corporate networks though. In such environments ability to selectively (respecting the privacy of eg. online banking) decrypt the traffic in order to defend against advanced malware or targeted attacks might be of a great value. This way organisation's IT can be effectively guarded from cybercriminals trying to control and covert their operations by simply using the common HTTPS protocols usually allowed to traverse networks and firewalls.

Still, the interception needs to be done wisely, so the certificates presented to the user are not just a simple wildcard, blanket super-cert. They need to carry all the parameters from the original site, so both the user and the browser can justify if the connection shall be trusted. Otherwise both the software and the user become blind and have no way to tell the difference.

If you would like to play a little and check how your browser (and yourself) reacts to bad SSL/TLS connection attempts, check it at BADSSL. It's a set of tests where the website tries to fool the browser, eg. wrong certificate parameters, self-signed (not CA-issued) cert, expired cert, a cert for a different website, without domain name, low cipher-suite, using known bad cert (like Lenovo or Dell service certs), wrong key exchange, but also tricks on the website where login is in fact going in cleartext or mixed scripts smuggling unsecured content.

Play around with the red tests. Have fun! And remember - the art of illusion is that what you see is not what is really happening...

Your browser should detect such attempts and warn you accordingly. With the keyword being "should", hence double checking if everything is right with the certificate presented by the website is absolute key to your personal and corporate security. Hence, before you make this next bank wire transfer it's not enough to just trust - verify the certificate and all the environment properly.