SSL/TLS has been on stage for a while with deprecated protocols[1], free certificates for everybody[2]. The landscape is changing to force more and more people to switch to encrypted communications and this is good! Like Johannes explained yesterday[3], Chrome 90 will now append "https://" by default in the navigation bar. Yesterday diary covered the deployment of your own internal CA to generate certificates and switch everything to secure communications. This is a good point. Especially, by deploying your own root CA, you will add an extra string to your securitybow: SSL interception and inspection.
But sometimes, you could face other issues:
- If you have guests on your network, they won't have the root CA installed and will receive annoying messages
- If you have very old devices or "closed" devices (like all kind of IoT gadgets), it could be difficult to switch them to HTTPS.
On my network, I'm still using Let's Encrypt but to generate certificates for internal hostname. To bypass the reconfiguration of "old devices", I'm concentrating all the traffic behind a Traefik[4] reverse-proxy. Here is my setup:
.png)
My IoT devices and facilities (printers, cameras, lights) are connected to a dedicated VLAN with restricted capabilities. As you can see, URLs to access them can be on top of HTTP, HTTPS, use standard ports or exotic ports. A Traefik reverse-proxy is installed on the IoT VLAN and accessible from clients only through TCP/443. Access to the "services" is provided through easy to remember URLs (https://service-a.internal.mydomain.be, etc).
From an HTTP point of view, Traefik is deployed in a standard way (in a Docker in my case). The following configuration is added to let it handle the certificates:
# Enable ACME
certificatesResolvers:
le:
acme:
email: [email protected]<redacted>.be
storage: /etc/traefik/acme.json
dnsChallenge:
provider: ovh
delayBeforeCheck: 10
resolvers:
- "8.8.8.8:53"
- "8.8.4.4:53"
There is one major requirement for this setup: You need to use a valid domain name (read: a publicly registered domain) to generate internal URL (in my case, "mydomain.be") and the domain must be hosted at a provider that provides an API to manage the DNS zone (in my case, OVH). This is required by the DNS authentication mechanism that we will use. Every new certificate generation will requite a specific DNS record to be created through the API:
_acme-challenge.service-a.internal.mydomain.be
The subdomain is your preferred choice ("internal", "dmz", ...), be imaginative!
For all services running in Docker containers, Traefik is able to detect them and generate certificates on the fly. For other services like IoT devices, you just create a new config in Traefik, per service:
http:
services:
service_cam1:
loadBalancer:
servers:
- url: "https://172.16.0.155:8443/"
routers:
router_cam1:
rule: Host("cam1.internal.mydomain.be")
entryPoints: [ "websecure" ]
service: service_cam1
tls:
certResolver: le
You can instruct Traefik to monitor new configuration files and automatically load them:
# Enable automatic reload of the config
providers:
file:
directory: /etc/traefik/hosts/
watch: true
Now you are ready to deploy all your HTTPS internal URL and map them to your gadgets!
Of course, you have to maintain an internal DNS zone with records pointing to your Traefik instance.
Warning: Some services accessed through this kind of setup may require configuration tuning. By example, search for parameters like "base URL" and changed to reflex the URL that you're using with Traefik. More details about ACME support is available here[5] (with a list of all supported DNS providers).
[1] https://isc.sans.edu/forums/diary/Old+TLS+versions+gone+but+not+forgotten+well+not+really+gone+either/27260
[2] https://letsencrypt.org
[3] https://isc.sans.edu/forums/diary/Why+and+How+You+Should+be+Using+an+Internal+Certificate+Authority/27314/
[4] https://traefik.io
[5] https://doc.traefik.io/traefik/https/acme/
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key
