There should be a way for a dns owner to limit the challenge methods to whatever the dns owner see fit. Currently I couldn’t find such support in the CCA dns record but I think such a mechanism must exists.
TL;DR;
And here is my real life almost scenario that is causing me the headaches.
So we have a web based software for bar and restaurants (or any other type of business for that mater). Since for some clients it is unacceptable to be Internet dependent we have an option (which most of our clients use) to install the software on a computer in the client premises. Since it is web based we make port forwarding on the on the router so the client can access the administration interface from home for example. Or he might have integration with an internet store where the Store should make a connection to the server an use API to make orders.
As security is a major concern we issue subdomain certificates under our domain for each of our clients. So the communication is secure. We have all the measures to secure the server in place from unauthorized access.
Recently however we discovered that the MikoTik router of the client has been hacked. The hacker but an http proxy and utilize it the following way:
On every first request to a site it returns 403 Forbidden responce, where in the Responce body it puts and HTML that includes a js file from another side that mines a cryptocurrency, then he launches the script and creates an frame that loads the originally requested site. On every other consecutive request to the same site the proxy just bypass the request to the original destination.
So every request from within or from the outside would utilize the same scenario and the result would be that in the clients browser they would have the wanted site but would also have code that is mining cryptos in the background.
We (or every other side) could combat this by setting X-Frame-Options deny header in the request, however the proxy could actually just strip those when serving to the client.
Even though the hacker didn’t get so far it got us thinking. Since our subdomain is pointing to the router IP address the hacker could just as well make a request to letsencrypt for issuing a certificate using HTTP01 challenge and would have no problem responding to the challenge since it controls the router. That way the hacker could event start returning a valid ssl responces with an appropriate certificate.
We already issue the certificates with DNS01, so the easiest way to protect ourselves and our clients would be to somehow forbit http01 challenge or limit it to https with a valid already issued certificate.
So there you have it. If there is a way to limit the acceptable validation challenges it would increase security and would allow for the domain owner to determine how can someone posse a challenge on his name.
If such a method already exists, please excuse my ignorance. I couldn’t find it.
Thanks so much for the suggestion! There’s an IETF draft specifying a way to do exactly that, by setting CAA records: https://tools.ietf.org/html/draft-ietf-acme-caa-05. We’ve even got an implementation in Boulder. Unfortunately, we’re hung up a little on some problems in the CAA spec. Fortunately, the revised CAA spec fixing those problems has just entered Last Call at IETF. So in some months from now, you’ll be able to do this. Please watch the API Announcements category for updates.
If you can successfully block your domain from issuing certificates to this IP via http authentication.
They can just use a different domain that is not blocking http authentication; as long as the name resolves to that IP they have the control to issue certs. Like with any of the free dynamic DNS services.
So I’m not sure you will get entirely what you are looking for - but you should be able to ensure they don’t spoof your domain with authenticated credentials.
Don’t quite understand your suggestion. Even if I use authentication the hacker has control of the router, so he would be performing the validation and just skip authentication.
I cannot use another domain since I need the certificate issued for this domain and it is not possible to issue a certificate for one domain for another.
My point in that post was: Even if you get what you are asking for (and disable HTTP IP validation for your domain), the hackers will still have the ability to use that IP to obtain certs from a countless list of other domains.
DNS validation could get you the cert at any other trusted location.
Then you could find a trusted way to deliver the cert.
But you would still be left with a very bad MITM situation.
My recommendation to overcome your main problem would be to deploy a trusted VPN solution that can completely traverse the untrusted segment and provide that remote site a way to bypass the hackers control.
Not correct. I’ve already have CCA records that authorize only LetsEncrypt to issue for my domain.
Also please note the reply Jsha where the spec for CCA records is to be expanded and in the new draft the validation method could also be restricted with a CCA record. So my problem will be resolved… The only question remaining is when
Account control seems like a very easy “fix” to implement.
Although, the more I think about it, the more I think it would require multiple accounts and a clear method of controlling which accounts to allow and which to no longer allow.
Since, in the event of a system being compromised, one should only need to stop that one account - not a single account and create a domain wide denial of service to yourself.
re: CAA I stand corrected !
But I don’t think they can get certificate for other domains. Lets get acme.com for example. Even though if you are accessing the validation request endpoint via the hacked router, the Lets Encrypt servers are still using their DNS servers so they won’t validate the request.
They can only issue for my domain since my domain points to the hacked IP already.
The router would be reset of course. By no means I would left it hacked. But I’m looking for a solution to protect my self even when I don’t know if the router is hacked on not.
My concern is actually valid for every dynamic dns provider out there.
I already have a VPN backup solution in place, but it brings a latency and a single point of failure that I would like to avoid.
Since I already know how to detected hacked routers, for now I’m content that solution would come eventually.
Re: account control.
Yes, currently every instance is on a different account, but If I go that path it would complicate the account management as rg305 stated.
It would also complicate the case where one domain is server by 2 instances or if I need to move the instance to a new location/server.
For that reason the allowing only methods I support and trust is the better approach for me.
That depends on entirely your VPN design.
If you use single hub design then yes, a single point of failure.
But there are many other designs that can overcome single points of failures.
Latency can become an issue; especially when sites are far from each other and/or network speeds are not sufficient for added remote sites bandwidth.
This is true, but I don't see how it is relevant to my issue/request. I don't even see how it relates to certificates at all. This exploid is purely human behaviour hack and it is valid with or without a certificate. If someone believes that whitehouse.gov.cname.other.domain.name.space.tld is the same whitehouse.gov there is nothing much you can do about it from a technical point of view. And certificates do not solve that problem and had never done so.
My described problem is that someone can make a man in the middle attack with a legitimate certificate to MY DOMAIN from an authority that I have authorized to do so. And the solution is to limit the validation method to DNS, so even if someone is in the middle (in the router) and currently controls the IP he would still won't be able to issue itself a certificate for my domain and pose as me.
