What is the current status of the implementation of multi-viewpoint validation?

I’m researching for countermeasures against BGP Attacks as discussed in this paper presented at USENIX: Bamboozling Certificate Authorities with BGP

So far I only found this post in the Let’s Engrypt Forum: Using BGP to Acquire Bogus TLS Certificates

I was also trying to find information in the GitHub repo of Boulder but couldn’t really find my way around.

2 Likes

This isn’t an authoritative answer, but from what I have observed recently, both staging and production now have multi-VA enabled, but production they are both configured to only require a single VA to get a successful response.

4 Likes

Does DNS challenge(or just DNS lookup) also do multi-VA thing?

@lipflip010 Thanks for the question,

We are nearing a production enforcing deployment of multi perspective validation but haven’t launched it yet. I’m hopeful we can do this in Q1 2020 but it’s primarily blocked on SRE time.

How did you test this? My understanding is that the staging environment is enforcing multiple perspective validation. It should require 2 of the 3 remote perspectives to agree with the primary perspective.

Production is making the remote perspective validation requests but we are only aggregating the results for analysis and not blocking issuance if they disagree with the primary perspective.

All of the challenge types as well as the associated DNS lookups (A, AAAA, CAA, etc) are done by the individual perspectives.

4 Likes

I’m hopeful for this too. From the SRE perspective (knee-slap), we’re developing capacity plans in preparation for a hardware refresh to support future growth.

3 Likes

Had a few more thoughts about this thread at the end of the day :slight_smile:

We’d love to hear about your research/findings. We try to keep an eye on this space and support academic research where we can. If you have a project relevant to us or security research you’re performing in this space please feel to reach out in forum DM or via e-mail if you think there’s something we can do to make Let’s Encrypt’s domain validation more secure.

If you have specific questions about what implementation details you’d be interested in reading I can provide some pointers. We haven’t done a great job of documenting the high level system design, sorry about that! I’ll try to land some documentation in the new year (Filed #4609 to keep myself honest).

If you follow the Development Instructions to set up a Boulder environment in Docker and then change your docker-compose.yml's BOULDER_CONFIG_DIR to test/config-next instead of test/config you’ll have a Boulder environment configured with two primary VA instances (validation requests are load balanced across the two) and two remote VA instances (each primary VA will ask both remote VAs to perform matching validations for each primary validation). Of course this is a dev env so both the primary and remote VAs are all running on one host.

The primary and remote VAs are both the same piece of software, the boulder-va service (cmd here, package here). The boulder-ra uses the same RPC interface to ask for a primary validation as the primary VA uses to ask a remote VA for a confirmation validation.

Primary VA instances know they are a primary based on the presence of the "remoteVAs" configuration element. If present it specifies gRPC service addresses for other VA instances to use as remotes. There’s also a handful of feature flags that control how the primary VAs handle the remote VAs.

In the dev env with config-next the two primary VAs are va1.boulder:9092 and va2.boulder:9092 and use test/config-next/va.json as their configuration. This config file specifies two "remoteVA"s, va1.boulder:9097 and va2.boulder:9098 and enforces that a maximum of 1 of the 2 remote VAs disagree with the primary VA for all validations. The remote VA instances use test/config-next/va-remote-a.json and test/config-next/va-remote-b.json as their config files.

There’s some integration tests that test this end to end. The most relevant is probably test_http_multiva_threshold_fail. It tests that a HTTP-01 challenge made to a webserver that only gives the correct key authorization to the primary VA and not the remotes will fail the multi-perspective validation.

Hope that helps give you a place to start. I’ll be out of the office for a ~week but will follow-up if you have more questions when I’m back.

7 Likes

First of all, thanks to all of you for your detailed responses!

I think I have to clarify the kind of research I did :sweat_smile: I’m in my undergrad now and had to prepare a presentation based on the paper I mentioned in my question. Towards the end of preparition I thought it might interest the audience which countermeasures are already implemented and to what degree. So I’m not really doing an extensive research.

Thank you for your effort to provide me instructions for running and testing it myself; I feel honored by that, though I think this goes beyond the scope of my presentation.

5 Likes

Happy to help!

Thanks for clarifying. I hope your presentation was successful :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

FYI we’ve announced the launch plan for multi-viewpoint validation: ACME v1/v2: Validating challenges from multiple network vantage points.

5 Likes