Recently there was another case of BGP hijacking where an attacker acquired a TLS certificate: https://www.coinbase.com/blog/celer-bridge-incident-analysis Le mercredi 23 février 2022 à 12:53:37 UTC+1, [email protected] a écrit :
> On Tue, Feb 22, 2022 at 2:30 AM Matt Palmer <[email protected]> wrote: > >> On Mon, Feb 21, 2022 at 06:03:43PM +0100, Matthias van de Meent wrote: >> > On Mon, Feb 21, 2022 at 5:09 PM Ryan Sleevi <[email protected]> wrote: >> > > On Mon, Feb 21, 2022 at 8:25 AM Michel Le Bihan < >> [email protected]> wrote: >> > >> I know that this has been discussed several years ago, but I didn't >> see >> > >> any definitive final conclusion. In regards to the recent incident >> > >> >> https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600 >> > >> that involved the malicious actor reacquiring a valid TLS >> certificate, I >> > >> think that it might be worth to restart the discussion. >> > >> >> > >> I know that the recommended solution is RPKI, but should there be >> other >> > >> solutions that would mitigate this issue when RPKI is not deployed? >> > >> >> > >> Some possible solutions: >> > >> 1. Allow restricting validation methods in CAA records >> > >> 2. Require CAs to have multiple vantage points >> > >> 3. Not issue certificates shortly after suspicious BGP events >> > > >> > > I’m not sure I see how 1 addresses this risk by itself. Are you >> thinking >> > > about this in isolation, or combined with some other mitigations >> (like RPKI >> > > and DNSSEC)? And, if combining, do we really need 1 to bind the >> method, >> > > versus something like account binding? >> > >> > Account binding might not be available for certain CAs. >> >> Then don't use those certain CAs, and restrict those CAs from issuing for >> your domain by not including them the domain's CAA records. >> > > That assumes that there are CAs that implement RFC8657, and that I trust > for my domains, and would issue certificates for my use cases. > > > I would like it if >> > e.g. CAA would also allow for restricting validation methods: >> >> RFC8657 defines the `validationmethods` parameter to the `issue` and >> `issuewild` CAA properties. Again, if a given CA doesn't support those >> parameters, you can avoid the problem by not including that CA in your CAA >> records. >> > > Of the roots in the Mozilla root store [0], only one CPS mentions RFC > 8657, and that one does not give me any guarantee that it will actually > limit issuance to only the verification methods in my CAA record: "Google > may choose to limit issuance according to RFC 8657" (i.e. non-conformance > to RFC 8657 does not violate their CPS). Additionally, the CPS does not > provide validation method identifiers to be used for BR validation methods; > so only ACME validation methods are usable (while at the same time useless > because there is no ACME endpoint that I could use). > > CA/B Forum Baseline Requiremets requiring compliance to RFC 8657 would be > a great improvement. > > - Matthias > > > [0] > https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport, > searched each root for CP/CPS queried for "CAA", stopping the search when I > find a CP/CPS for that root / CA that contains the Issuer Domain Name. > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b84287a6-94bd-450e-aa6b-49c629cae2ddn%40mozilla.org.
