Disabling cert checks: we have not learned much
daniel.haxx.se
Disabling cert checks: we have not learned much
1–10 of 24 posts
Re: Disabling cert checks: we have not learned much
#2Somewhat related is a recently discovered bug in the qBittorrent client where SSL checks had been disabled for a long time before someone noticed:
Re: Disabling cert checks: we have not learned much
#3I think that many instances are disabling checks in order to troubleshoot something and then never enabling it again. And we see this on all levels - development, devops and also sysops of course. Just quickly disabling something without leaving a TODO, disabling a MSDeploy certificate check because a proper PKI has never been set-up, just ignoring any certificate errors in LAN management tools because installing a certificate is so hard.
Re: Disabling cert checks: we have not learned much
#4I just today reviewed a PR with a default insecure option. But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address.
At least with HTTPS over the local network, it can frustrate attempts to break into it. That said we are sure to call it “https-insecure”.
Re: Disabling cert checks: we have not learned much
#5Except in airgap environments where there is no CA available to check against.
Re: Disabling cert checks: we have not learned much
#6Except in airgap environments where there is no CA available to check against.
Create a local root CA.
Re: Disabling cert checks: we have not learned much
#7Re: Disabling cert checks: we have not learned much
#8I just today reviewed a PR with a default insecure option. But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address. At least with HTTPS over the local network, it can frustrate attempts to break into it. That said we are sure to call it “https-insecure”.
> But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address.
There are options for this, that needn't cost.
In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build, point whatever domain you like (“real” or just a local-only DNS entry) at your host and sign a cert for that with the internal CA. Generating keys & certs for each workstation can be automated. You could sign a wildcard subdomain and key+cert for each machine or person, .pc101.devteam.internal/.johndoe.devteam.internal, so each user can setup multiple dev/test services on their box without requiring support from the infrastructure team.
Or get a wildcard from LE or similar for some [sub]domain, point *.[sub.]domain to 127.0.0.1 and let everyone have the keys for that. You need to renew every 3 months or less and redistribute the cert, but that isn't massive hardship and can be automated. Also make sure this is only for dev/test though, not internal tooling that might handle read data/controls, or having multiple (potentially many) people with access to the private key is a massive security issue.
Using proper names & certs and not encouraging disabling checks for local dev/test, reduces the risk of code that doesn't do proper verification getting let out into the wild later when someone forgets to switch checks back on.
Re: Disabling cert checks: we have not learned much
#9I just today reviewed a PR with a default insecure option. But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address. At least with HTTPS over the local network, it can frustrate attempts to break into it. That said we are sure to call it “https-insecure”.
> But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address. There are options for this, that needn't cost. In a company with controlled workstations, have your own CA and push the trust of that through GP or in your standard OS build, point whatever domain you like (“real” or just a local-only DNS entry) at your host and s…
Or you can do none of that razzle dazzle which, if you stop to actually think about it, doesn't really bring in any security. Yeah, "let everyone have the keys for that", that's sure much more secure against some vaguely imagined threat connected with people already running arbitrary stuff on your internal network.
Re: Disabling cert checks: we have not learned much
#10Earlier quoted context omitted.
Create a local root CA.
I can't be a CA for a root cert I don't own
There's nothing stopping you for creating your own root CA and using it to sign certificates for any other domain. You can create a certificate for google.com if you wanted and be signed with your own CA.
Now, obviously, you couldn't actually use that certificate publicly. If you were to try to MitM someone, their client wouldn't accept the certificate because your root CA's certificate won't be in their trusted list.
But add that root CA to your own system, and it'll work fine.