jetstack / paranoia

Inspect certificate authorities in container images

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Asking for suggestions for my use cases

fredmaggiowski opened this issue · comments

Hi there, I was at KCD UK when I found out about this project; I immediately found it interesting and wanted to experiment a little bit with it.

Now I've tried adding the paranoia action in a project I'm maintaining where unfortunately I was already adding lots of cerfiicates so I now find myself with having three options:

  1. remove all the certs and find a better way to add only a specific subset of certs (I'm still studying whether this is actually feasible but I'm worried it won't)
  2. audit every single certificate and add them to the allow list so that, after the audit, I have 100% control and understanding over the certificates I'm using
  3. allow any certificate that is installed (like I did in this PR or better by allowing all the current fingerprints) but it practically means I'm not actually using the tool so I'm just wasting action resources without adding any security with the risk of having to patch the paranoia.yml file anytime a new certificate is issued.

I believe that I should stick with option 1, however if that's not feasible what do you think would be the best option in your experience?

Also, assuming that option 1 is not feasible and that auditing +100certificate will be a pain, do you think option 3 can still be useful? I believe it can if paranoia fails the check for some unexpected issues (such as expired certificates, etc) do you see that coming? or have any plan for some interesting features that may be letting me adopt the tool even with such options at hand?

Thanks in advance!
Cheers!

Hey @fredmaggiowski, thanks for coming along at KCD UK, and for trying out Paranoia.

It's a hard problem to be sure. For me I'd look at alternatives first.

  1. Does the tool need network access at all? If it's a server it probably doesn't need CA certs, It only needs them if it's acting as a TLS client, or if it's planning to use client authentication (which probably needs a custom CA anyway).
  2. Can you use trust-manager, or some other way of distributing trust at runtime?

If either of thsoe are true, you could omit the certs alltogether.

Failing that, if you know you only need access to some sites, like specific APIs, then you could bundle just those certs (there's a risk if the developer of those sites changes their CA though — such as moving to Cloudflare).

If you do need generic certs, you're realisticly not going to be able to audit all 100+ certs in the normal bundle by yourself. Honestly the built-in OS bundles are not bad — it's just that they get outdated quickly.

As for what Paranoia can do, there's already a paranoia inspect command that gives a bit more detail about each CA. It's not all that automated though. I'm super interested in thoughts here!

Hi @JamesLaverack sorry for my late reply, thank you for this thorough answer!

Yes the service needs network access but I guess we could look into trust-manager, when running in k8s it may be a viable alternative (even though the service may also run outside k8s therefore someone would have to ship the necessary CA some other way, which may still be acceptable imho).

I've tried using paranoia inspect and it gave me an interesting output, currently in my bundle there are 12 certificates with issues

inspect output
Certificate CN=Cybertrust Global Root,O=Cybertrust\, Inc
┣ 🚨 expired ( expired on 2021-12-15T08:00:00Z, 52 weeks 23 hours since expiry)
┗ 🚨 removed from Mozilla trust store, comments: June 2015: DigiCert acquired this root cert from Verizon.
Certificate CN=DST Root CA X3,O=Digital Signature Trust Co.
┣ 🚨 expired ( expired on 2021-09-30T14:01:15Z, 1 year 10 weeks since expiry)
┗ 🚨 removed from Mozilla trust store, no reason given
Certificate CN=E-Tugra Certification Authority,OU=E-Tugra Sertifikasyon Merkezi,O=E-Tuğra EBG Bilişim Teknolojileri ve Hizmetleri A.Ş.,L=Ankara,C=TR
┗ ⚠️ expires soon ( expires on 2023-03-03T12:09:48Z, 11 weeks 1 day until expiry)
Certificate CN=GeoTrust Primary Certification Authority - G2,OU=(c) 2007 GeoTrust Inc. - For authorized use only,O=GeoTrust Inc.,C=US
┗ 🚨 removed from Mozilla trust store, no reason given
Certificate CN=GlobalSign,OU=GlobalSign Root CA - R2,O=GlobalSign
┣ 🚨 expired ( expired on 2021-12-15T08:00:00Z, 52 weeks 23 hours since expiry)
┗ 🚨 removed from Mozilla trust store, comments: Ownership transferred to GTS:
https://bug1325532.bmoattachments.org/attachment.cgi?id=8844281
Certificate CN=Hellenic Academic and Research Institutions RootCA 2011,O=Hellenic Academic and Research Institutions Cert. Authority,C=GR
┗ 🚨 removed from Mozilla trust store, no reason given
Certificate CN=Hongkong Post Root CA 1,O=Hongkong Post,C=HK
┗ ⚠️ expires soon ( expires on 2023-05-15T04:52:29Z, 21 weeks 3 days until expiry)
Certificate CN=QuoVadis Root Certification Authority,OU=Root Certification Authority,O=QuoVadis Limited,C=BM
┣ 🚨 expired ( expired on 2021-03-17T18:33:33Z, 1 year 38 weeks since expiry)
┗ 🚨 removed from Mozilla trust store, no reason given
Certificate CN=Sonera Class2 CA,O=Sonera,C=FI
┣ 🚨 expired ( expired on 2021-04-06T07:29:40Z, 1 year 36 weeks since expiry)
┗ 🚨 removed from Mozilla trust store, no reason given
Certificate CN=Staat der Nederlanden EV Root CA,O=Staat der Nederlanden,C=NL
┗ 🚨 expired ( expired on 2022-12-08T11:10:28Z, 6 days 20 hours since expiry)
Certificate OU=Trustis FPS Root CA,O=Trustis Limited,C=GB
┗ 🚨 removed from Mozilla trust store, comments: Email from the CA April 26, 2021: no new certificates have been issued since January 2018 and all expired as of January 2021.  We have a project in place to revoke any associated relying certificates which is currently being scheduled.
Certificate CN=VeriSign Universal Root Certification Authority,OU=VeriSign Trust Network+OU=(c) 2008 VeriSign\, Inc. - For authorized use only,O=VeriSign\, Inc.,C=US
┗ 🚨 removed from Mozilla trust store, no reason given
Found 129 certificates total, of which 12 had issues

I'm thinking about removing these certificate and put them in the rejection list in my .paranoia.yaml configuration to make sure I don't have them anymore, this may be a nice starting point in using the tool.

On a side note It would be nice to have fingerprints in both paranoia export and inspect commands to make it easier to find out where are certificate located and use the fingerprints for exceptions.

What do you think?