Skip to content
This repository has been archived by the owner on Jul 15, 2021. It is now read-only.

An expired or missing CRL doesn't result in the manifest being considered invalid #162

Closed
job opened this issue Mar 30, 2020 · 1 comment

Comments

@job
Copy link
Member

job commented Mar 30, 2020

This issue was also informally reported to RIPE NCC staff in late February 2020.

It appears that RIPE NCC validator doesn't consider an expired CRL cause to consider the associated manifest and underlaying objects invalid. It logs a warning, but does not consider this situation erroneous.

Theoretically a replay attack can be executed by making the CRL unavailable in a monkey-in-the-middle scenario, or presenting the validator with old data. The RPKI data download procedure in RIPE NCC's Validator must assume it is collecting untrusted data, which must be verified using the certificate verification model where an expired CRL means that none of the X509 objects pointing to the CRL can be validated or considered valid.

Some more (hard to read) context is available in the RPKI standards forum at IETF via https://mailarchive.ietf.org/arch/msg/sidrops/BKbYujWcr4qWJOahFoBqgZHrFX8/ and specifically https://mailarchive.ietf.org/arch/msg/sidrops/6bHseJeNPSsK0lebbNTDGFKVYsA/

If the CRL is expired, the manifest & directory should not be considered eligible for further processing and the associated VRPs should not be emitted to the RTR process. Manifests and CRLs compliment each other, manifests are not a replacement for CRLs.

The manifest specification assumes a sensible policy regarding CRL expiration is applied. Since RPKI does not have any other certificate revocation mechanisms other than CRLs (there is no OSCP and other tricks in the specs) - I believe that ignoring the CRLs expiration date opens up RIPE NCC's validator for replay attacks which can have adverse operational consequences (aka an attacker has the ability to flip BGP routes from valid to invalid)

To be transparent: I'm filing this bug publicly so I can reference this later on in a write-up about how these validation issues were handled.

@lolepezy
Copy link
Contributor

lolepezy commented Jul 7, 2020

It's been addressed in the latest release
https://github.com/RIPE-NCC/rpki-validator-3/releases/tag/3.1-2020.07.06.14.28
it would still require explicitly setting the property rpki.validator.strict-validation = true but the functionality is there.

@lolepezy lolepezy closed this as completed Jul 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants