briansmith/webpki

It is possible to DoS certificate validation with name constraints and/or a large number of candidate intermediates

briansmith opened this issue · 15 comments

briansmith commented

There is a DoS attack exploits the fact that name constraint checking, in particular, has quardratic (at least) behavior. If certificate A that chains to a certificate B and certificate A has a lot of names and certificate B has a lot of name constraints, then we do a lot of checking. BoringSSL's solution was to verify that the entire certificate chain is valid modulo name constraints, and then check name constraints. (TODO: verify that this summary of what they did is accurate.) We should do that or something better.

#68 might make this easier to do; regardless this and #68 interact with each other.

briansmith commented

I generalized this to cover two DoS-related issues that interact:

  • Name constraint checking is quadratic, so a large number of names in certs and/or a large number of name constraints could cause serious issues.
  • Path building is as bad or worse in the number of candidates certificates.

Both issues are compounded by signature verification being very expensive. They are inter-related because some solutions (e.g. naively doing path building sans name constraint checks before doing name constraint checks) seem to just shift the problem around.

However, it is also the case that anti-DoS countermeasures also have significant DoS side-effects of their own: See spiffe/spire#1004, for example. This issue is especially interesting because it likely motivates the implementation of AKI/SKI matching.

briansmith commented

There is a webpki 0.22.1 release that implements the signature count mitigation.

  • 🎉8
Kixunil commented

Would it be possible to backport the fix for people with MSRV issues?

briansmith commented

Would it be possible to backport the fix for people with MSRV issues?

0.22.2 was released with all the fixes so far, without the MSRV bump. 0.22.4 is the release that has the MSRV bump, IIRC. However, 0.22.2 is using an unsupported version of ring whereas 0.22.4 is using a supported version of ring.

Rust 1.61 was released 18 months ago.

  • 👍2
djc commented

@Kixunil where are your MSRV constraints coming from? I feel like we're generally pretty conservative compared to most of the ecosystem.

Kixunil commented

The new version of rustls breaks my MSRV and it updates webpki from 0.21 to 0.22. So the problem is also related to semver breaking changes.

briansmith commented

The new version of rustls breaks my MSRV and it updates webpki from 0.21 to 0.22. So the problem is also related to semver breaking changes.

That's a separate issue to be discussed elsewhere.

Ultimately there's little getting around the need for MSRV 1.61 unless ring 0.17 reduces its MSRV. But at most that would be temporary, if it were to happen at all.

Kixunil commented

1.61 is fine, rustls has 1.64, I need 1.63 (Debian stable)

djc commented

1.61 is fine, rustls has 1.64, I need 1.63 (Debian stable)

So why do you need to stick to Debian stable? I doubt the ecosystem will stick to 1.63 very long.

BTW, I'm not sure where you're getting that rustls needs 1.64 -- rustls on main only just bumped 1.60 to 1.61.

@Kixunil I agree with @briansmith you should open a new issue to discuss your needs.

briansmith commented

1.61 is fine, rustls has 1.64, I need 1.63 (Debian stable)

ring's and webpki's MSRV is 1.61. If you are running into MSRV problems, they are probably elsewhere. Thanks for letting me know that Debian Stable has 1.63, that must be the rock bottom version of Rust we need to support.

  • ❤️1
Kixunil commented

So why do you need to stick to Debian stable?

I and other people explained this already multiple times in various places, among other things: dissatisfactory security of rustup.

rustls needs 1.64 -- rustls on main only just bumped 1.60 to 1.61.

Oh, it must be tonic then which itself depends on rustls. I will investigate and open an issue s suggested.

djc commented

So why do you need to stick to Debian stable?

I and other people explained this already multiple times in various places, among other things: dissatisfactory security of rustup.

I recently became a rustup maintainer, can you point me to rustup issues where this is documented?

Kixunil commented

Lack of signature verification and enforcement of their correctness (fail if invalid, not warnings).

briansmith commented

Please take the rustup discussion to the rustup issue tracker.