12

This article expose how around 18% of HTTPS connections are being detected as intercepted by MITM proxies. As the great related paper state:

To circumvent this validation, local software injects a self-signed CA certificate into the client browser’s root store at install time.
[...]
Contrary to widespread belief, public key pinning [19]— an HTTPS feature that allows websites to restrict connections to a specific key— does not prevent this interception. Chrome, Firefox, and Safari only enforce pinned keys when a certificate chain terminates in an authority shipped with the browser or operating system. The extra validation is skipped when the chain terminates in a locally installed root (i.e., a CA certificate installed by an administrator) [34].

Is pretty common on companies, desktop antivirus and malware/adware to add root CA. Sometimes even with honest reasons. But to make the situation more clear: SSL web browsing is exactly as strong as the weakest CA (this includes DNS if DNS-over-HTTPS).


I want to check if my HTTPS traffic is intercepted at least in three aspects (better if just with CLI):

So the real questions are:

  • How to list unofficially installed CA certificates (doesn't come with Ubuntu/Firefox/Chrome) to avoid MITM attacks/HTTPS interception?
  • How to reset trusted certificates stores to its default?

Some research and related questions

  • checkmyhttps seems old and not trustworthy
  • Chrome: chrome://settings/certificates this is a subset of what return some of these commands?

    # System wide (I)
    awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
    
    # System wide (II) (`p11-kit` package)
    trust list
    
  • Firefox

    certutil -L -d ~/.mozilla/firefox/*.default*/
    
  • I already sudo update-ca-certificates -v -f. This just updates without removing any sneaky already installed certificate?

Reference

  • 2
    Firefox and Chrome come with their own certificate store which is independent from /etc/ssl/.... The latter is used by other tools like curl but some applications, libraries or tools come with their own CA store (Java, python requests ...). So it is not really simple to check all of these. – Steffen Ullrich Mar 28 '19 at 5:28
  • @SteffenUllrich I didn't say it would be easy, and as you know is not rare. There are already some answers for Windows and Red Hat out there. – Pablo Bianchi Mar 28 '19 at 17:46
0

dpkg -S somefile will tell you what package somefile belongs to. You can use dpkg --verify pkgname or debsums to see if they have been modified.

You can use those to verify /etc/ca-certificates.conf and the directories it refers to -- basically, verify that CA files belong ca-certificates + dpkg-reconfigure -plow ca-certificates to chose among them. As you may have guessed, update-ca-certificates uses this data to recreate the global CA store files.

I don't have an easy answer for app-specific stores like Chrome's and Firefox's. You'd basically start by looking for global configuration directories, if any (dpkg -L), and then look into each user profile to see if custom CAs have been installed in that profile: look at the files, diff with a new one, check if the account is corporate-managed, ... StackOverflow or SuperUser can help more directly.

Obligatory note: installing packages from untrusted third parties can mess up the system in many ways (running any untrusted script, really). I think yours is still a fair question, since benign software sometimes adds a CA and won't try to hide the fact. However, if you suspect someone might have modified your system behind your back, it's far safer to reinstall.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.