Mass registration on a single domain from a router vendor

I already considered becoming a sponsor - but would that change anything really? I would expect sponsorship and policy decisions not to be related.

@scamp You do realise that every issued Let’s Encrypt certificate is published on crt.sh ánd on multiple Certificate Transparency logs? I don’t know if your issued routers should be publicly known?

Yeah, we have a dedicated domain for this purpose - “router.management” (geez, don’t you just have to “love” these fancy new TLDs…?). Thanks for the hint, adding that to the public suffix list indeed sounds like a plan.

Our routers typically are reachable from the Internet, as they are … Internet routers :wink: - so the ACME challange typically won’t be a problem. There are circumstances where the routers might be inside some Intranet and not allowed to talk to the public Internet at all. In this case the user will have to install their cert manually, like they had to today.

1 Like

Security by obscurity is nothing you should bet on for a router on the public Internet. And you can find those devices using Shodan anyway. And if you would like to keep your router invisble, you’d just uncheck the Let’s Encrypt option inside the Installer…

1 Like

That sounds like it should work. So your general workflow would be something like:

  1. Push the router’s WAN address to your DNS so the A record for serialnumber.router.management gets set.
  2. Spawn a publicly-available web server on port 80 or 443 (which you probably already have for the management UI) and serve the challenge files/SNI challenge.
  3. Let your ACME client do its magic and install the resulting certificate.
  4. Repeat steps 2 and 3 automatically every 2-3 months.

Sounds like a nice use-case for Let’s Encrypt! :ok_hand:

1 Like

@scamp: We’re working on a rate limit override request form; it’s just a little slow right now around the holidays. Expect an announcement and instructions in early January, and it’ll be exactly what you need to accommodate all your devices.

6 Likes

Yep, that’s exactly the plan.

I’ve added a pull request for the public suffix list. Any clue on how often this is fetched by Let’s encrypt?

Usually a couple of weeks. You can follow the changelog on https://letsencrypt.status.io/, it’s usually mentioned when a new version is deployed.

Just FYI, the rate limit override form will be the faster route than adding to the PSL. It really is coming.

4 Likes

Just checking as not everyone is familiar with the ‘open’ nature of Let’s Encrypt :wink:

Nice, that’s good news, thanks. We’ll use the time for beta-testing our integration feature with the 5 tries we have :wink:

Thank you very much for this great job you are doing for the community.

2 Likes

pfg still has a point that the management domain should be on the PSL for cross-domain cookie security reasons. Let’s see which of the two ways turns out to be the quicker one :slight_smile:

You can do initial testing with the staging (test) server … it hasn’t got the same limits :wink:

Just curious: What exactly is the benefit of HTTPS here?

The same for any site I'd have thought - confidentiality, identity and integrity.
If I'm making changes on a router or similar device, I want to be able to log in using a secure method HTTPS / SSH, so that all communication is encrypted between the two (i.e the passed data is confidential) the identity of the device is confirmed, and the integrity of the system is maintained.

1 Like

Yeah, but that’s a totally different attack vector. If routers are under attack from the Internet, HTTPS actually increases the attack surface because it is massively more complex code. It doesn’t prevent anyone from connecting.

The major attack vector in the router business (I assume this is SOHO or private customers) has never been that passwords were leaked over unencrypted connections. “All sorts of blackhat organizations” that turn your router into a botnet or a Bitcoin miner usually don’t have MITM capability before they successfully breach the router.

Encrypting internal network traffic is a good mechanism of defense in depth (Just look up “SSL added and removed here” if you’re curious about why :smile:).

Agreed, in a typical setup, it’s game over once the attacker is in a position to MitM LAN traffic, but if you already have strict firewall rules, VLAN segmentation and what not, it’s definitely a step worth taking.

Sure, (open|boring|libre)ssl might introduce a whole new vector, but despite heartbleed and friends, the number of (realistically exploitable) RCEs or similar vulnerabilities that were found is quite low.

All true, but unrelated.

I just found it curious that HTTPS would help mitigate any of the trouble that routers face from the Internet. I don’t see why that would be the case.

If you actually use the webinterface from the outside of your network then it’s safer to serve it over https. If you don’t, you can firewall off both http and https.

1 Like

Great news! Any specific ETA on that request form?