RRDP fetches should not proceed if the TLS HTTPS endpoint doesn't validate

[job]

RFC 8182 section 4.3 "HTTPS Considerations" states:

Because of this, Relying Parties SHOULD do TLS certificate and host name validation when they fetch from an RRDP Repository Server.

The SHOULD probably should be read as a MUST, given the validator's susceptibility to fetch from a compromised (MITM'ed) RRDP service - especially when combined with a partial withholding attack. Note: checking the TLS certs of the RRDP channel makes MITM's harder - but not impossible! More work is needed in the validation procedure regardless of fixing this TLS RRDP issue.

Recommendation: rpki.validator.rrdp.trust.all.tls.certificates=true should be changed to rpki.validator.rrdp.trust.all.tls.certificates=false in the default distribution & settings. It is hard to imagine a scenario where one would want to disable TLS certificate validation.

[geeohgeegeeoh]

The principle used in the design is that the objects are signed, and mandatory cryptography on the endpoints used to fetch is not required. This SHOULD was discussed widely in the design of the system and it actually isn't clear this should be promoted to a MUST. The conversation in SIDROPS is not tending to decisive in this.

The combination of CRL and Manifest is designed to show occlusion of things which must be seen, and inclusion of things which have been repudiated.

In particular, it would make it impossible to fetch from a self-sign.

[job]

It's crazy easy at the moment to fire off MITM attacks against this validator because TLS certificates are not validated. This is one of those moments where one can say "the spec was dead wrong".

In particular, it would make it impossible to fetch from a self-sign.

People simply should not be using self-signed TLS endpoints for the public Internet's RPKI infrastructure. Speaking as network operator I have no issue ignoring ROAs at self-signed publication endpoints. If I do want to trust it I can manually import it into my local key store, as is how things are with self-signed certificates.

[ties]

It's crazy easy at the moment to fire off MITM attacks against this validator because TLS certificates are not validated. This is one of those moments where one can say "the spec was dead wrong".

I need a clearer threat model to reason about this and would really like it if one is created. RFC8211 does not help me. My intuition is that for sophisticated attackers (or network operators running a large network) it is actually quite feasible to get this SSL certificate.

If I remember correctly https://www.princeton.edu/~pmittal/publications/bgp-tls-usenix18.pdf analysed such a scenario.

People simply should not be using self-signed TLS endpoints for the public Internet's RPKI infrastructure. Speaking as network operator I have no issue ignoring ROAs at self-signed publication endpoints. If I do want to trust it I can manually import it into my local key store, as is how things are with self-signed certificates.

My experience is that importing certificates into the keystore of a containerized java application makes them nearly unusable. I do see value in some form of certificate pinning. You could define a distributionpoint in a CA certificate as well as the hash of the public key of a certificate on the validation path.

[job]

I need a clearer threat model to reason about this and would really like it if one is created.

RIPE NCC's validator is the only validator that does not check the TLS HTTPS properties of a RRDP fetch at all. OctoRPKI, FORT, and Routinator all three apply common TLS validation. Even if the RFC specifications suggest that checking TLS in RRDP fetches is optional, it is not the common practise to skip these checks amongst the validators.

The issue at hand is that if an attacker exploits the insecure behaviour as outlined in this ticket combined with the issues described in #158 or #162, users of this software easily end up in trouble.

The data to validate is there, why not use it? Who knows what vulnerabilities future researchers will? Any checks that are skipped just make life easier for attackers at some future point. I've demonstrated some operational implications by combining two weak aspects of the software in a single attack.

The moment an implementer skips some checks, the implementer has to be 100% confident and sure that all bases are covered via other methods. Such assumptions often turn out to be suboptimal.

[ties]

RIPE NCC's validator is the only validator that does not check the TLS HTTPS properties of a RRDP fetch at all. OctoRPKI, FORT, and Routinator all three apply common TLS validation. Even if the RFC specifications suggest that checking TLS in RRDP fetches is optional, it is not the common practise to skip these checks amongst the validators.

The issue at hand is that if an attacker exploits the insecure behaviour as outlined in this ticket combined with the issues described in #158 or #162, users of this software easily end up in trouble.

I think (and this reply is my personal opinion) that other validation behavior should protect against #158 or #162, TLS is not enough. A threat model would help reasoning there. For example, an attacker with network position can either MITM SSL and/or try to downgrade to rsync (or even MITM SSL validation and get a cert). My intuition is that you should assume that an attacker can control the set of files that you actually receive.

I'm looking into the behaviour when SSL mismatches occur. Even when rpki.validator.rrdp.trust.all.tls.certificates=true it should be logged and I think this should occur.

[job]

I think (and this reply is my personal opinion) that other validation behavior should protect against #158 or #162, TLS is not enough.

Agreed. But things like #158 and #162 are far easier to exploit because RRDP TLS isn't checked.

A threat model would help reasoning there. For example, an attacker with network position can either MITM SSL and/or try to downgrade to rsync (or even MITM SSL validation and get a cert). My intuition is that you should assume that an attacker can control the set of files that you actually receive.

yes, agreed, and we don't need to make it easier for attackers. The presence of rsync itself already poses a lot of challenges to RPKI deployment.

[ties]

I agree that changing the default strictly increases the difficulty of the attack (so that means that changing the default is positive). I'll get back to you about it. However I'm not convinced that it offers any additional security in a reasonable attacker model.

[ties]

Just a heads up: At the moment https://rpkica.mckay.com/rrdp/notify.xml has an invalid ssl certificate. It is a repository under the RIPE NCC tal (see it in the list at https://rpki-validator.ripe.net/trust-anchors/monitor/4).

Some RP software downgrades to rsync for this repo (for me this was only visible when run with -vv but this may depend on timing)

[lolepezy]

The latest release
https://github.com/RIPE-NCC/rpki-validator-3/releases/tag/3.1-2020.07.06.14.28
doesn't accept invalid TLS by default.