2019-11-08, 12:30–12:55, Blue Day
This talk introduces TLSMy.net, a new DNS-based service that allows home network devices to automatically request certificates that can be used with non-routable or dynamic IP addresses.
A slightly longer abstract:
Let's Encrypt has enabled rapid adoption of TLS across the long-tail of public-facing services. Unfortunately, there are still challenges in deploying TLS on home network devices, such as routers, TV tuners, and IoT hubs. These devices are commonly accessed by their non-routable, dynamically-assigned IP address, preventing traditional domain-validated certificates from being used. This talk introduces TLSMy.net, a new DNS-based service that allows home network devices to automatically request certificates that can be used with non-routable IP addresses.
- Why TLS is important for local network devices
- New web features (e.g., cross-origin resource sharing and requests) REQUIRE TLS to be used.
- Why TLS is hard to deploy locally
- Home users don't typically own a domain -- no DV certs
- Services aren't usually externally-facing, so certbot doesn't work
- How Plex solves the issue
- Requires cooperation with a CA
- What if we could use Plex's solution with Let's Encrypt?
- How Let's Encrypt issues certs
- Subdomain and wildcard rules
- ACME protocol
- HTTP challenge
- DNS challenge
- Let's Encrypt accounts
- Public/private key
- Public key is identity
- Private key is used to authenticate
- Creating a DNS responder for wildcard addresses
- Maps a.b.c.d.pubkey.tlsmy.net to IP address a.b.c.d
- Updating DNS records for wildcard subdomain validation
- Use challenge/response to verify permission to update *.pubkey.tlsmy.net
- Proof of possession of private key
- Trust model
- Need to somewhat trust domain owner
- If device manufacturer is domain owner, you may implicitly trust them anyway
- Can use certificate transparency logs to audit domain owner
- Getting adoption
- Overcoming Let's Encrypt rate limits
- Getting device vendors to support TLS