Can a local root certificate make a user more susceptible to phishing?

Question

In order to scan encrypted network traffic, security software usually installs root certificates on the user's machine. Sometimes on websites with standard digital certificates, the local installed root certificate is shown instead of the actual one.

I have for a while been a bit weary of this, not for snooping reasons, but for phishing reasons. The Punycode PoC phishing site contains a digital certificate, and with other phishing sites being issued certificates too (source), it is possible that checking the certificate on a suspeted site might just reveal a the local root certificate of the security software.

This makes me wonder whether this raises security concerns, as I normally check the digital certificate on pages where I am sending sensitive data to check that everything is ok. If however I am given a local root certificate, I don't have the same degree of certainty.

So essentially how can you know whether a personal root certificate is trusting a genuine site with a digital certificate, or just any site with a digital certificate?

Answer 1

Nowadays, any phishing operator can set-up a phishing site with a valid SSL/TLS certificate for free. This happens a lot with Let'sEncrypt, but happened in the past with other CA's as well. And phishing site operators do use SSL/TLS more and more frequently.

The main issue here is that most Internet user believes HTTPS means the website is safe to visit, it is secure. Which is not true. People don't understand that HTTPS means basically only that the communication between the browser and webserver is secured.

So if you are concerned about users being phished via SSL/TLS sites, invest energy in education, test users with phishing sites and teach them when they failed how they could have avoided/spotted the phishing site.

Root certificates in the trusted root certificates can increase the risks at different areas, but phishing is ain't the priority here.

Answer 2

Who are you imagining is doing the checking? A standard end-user is never going to check to see who issued a certificate, so I don't think it makes an end-user more vulnerable to phishing. You're lucky if a user checks the domain name and for the 'lock' icon (users will fall for phishing attacks, period. No amount of education or planning makes any of us immune to being phished. Plan accordingly. :) )

But, as user689443 mentioned above, it's important that the appliance doesn't let a phisher "upgrade" their cert - I've pentested proxy applications that didn't do proper certificate validation, and it did exactly that: it would take a crappy self-signed or mis-domained certificate and pop out one that's signed and trusted. Be careful of that!

And it's always worth noting that these certificates are as valuable to somebody attacking your organization as a root CA certificate is online: you have to treat them with care and make sure they don't get stolen. Otherwise, an attacker can use any number of attacks to make essentially perfect phishing schemes.

Answer 3

You have to configure the SSL intercept appliance right. That means the appliance should block all selfsigned, insecure or not trusted certificates; in this case the appliance will do the trust checking for you. But this needs a strong security organization, because many (most?) HTTPS-Sites have certificate errors. Here is a nice site which shows the not so good security of HTTPS-Sites: https://www.trustworthyinternet.org/ssl-pulse/

On the other hand, from a view of an user, the whole concept of SSL Interception dont looks so nice. According to an actual study (https://zakird.com/papers/https_interception.pdf) 10% of all encrypted internet traffic are intercepted by now and all the interception products undermining the security in a way like you afraid of.

Its just a classical trade off: in our network we measure 40% encrypted SSL-Traffic by now, in the other 60% we found 50.000 viruses per year. It means we dont see 30.000 viruses. The client Antivirus is much to weak. And so we decided to buy a SSL-Intercept-Appliance even if it bring other risks with it...