I don't think you fully understand how port knocking works.
No, I am just trying to understand your reasoning.
There is no such thing as absolute security. At some point, you need to make choices (other people might call those 'compromises')
2 Likes
That is why this is a feature request. I see a way to make it better.
Secret handshakes (that must be publicly published)... [ I love the whole attempt at extreme security ]
But it isn't practical for any non-three letter agency.
Much easier to setup a VPN with LE where they must use a well-known trusted cert in order to enter.
[which, of course, will also never happen]
3 Likes
Yes, and no.
Your dns and http server should be patched, they should be as safe as they can be. They usually are, lots of them are exposed on the internet and there's a lot of script kiddies around.
It's not your firewall's job to protect a broken webserver: that's the job of the power cord.
2 Likes
Just to be clear, I don't work for Let's Encrypt or speak for them. 
4 Likes
Fair enough, interesting idea. But, I think it belongs as a request to the CA/B forum. That is where the industry-wide specs are set upon which Let's Encrypt and other public CA adhere.
See here
and here:
3 Likes
Huh? I don't understand. Why would port-nocking as a service before actually starting the validation, be restricted by the BR?
4 Likes
Exactly where I don't know. I was thinking more generally about modifying how challenges work and how particular they are in the specs. Such as the recent issues to TLS-ALPN certs being revoked because they used an older TLS version than stated in the spec.
I was thinking if the knock said, "expect a challenge from this IP of this type within X seconds" that someone might have concern it affected the security of that challenge.
Perhaps you are right and it would not matter. It feels to me just across the other side of boundary of what would be allowed by discretion to LE.
4 Likes
The last sentence you wrote is key. It was a CA/B Forum issue, because the LE implementation violated the spec with regards to minimum TLS, and the OID had changed between the original deployment and RFC finalization.
As long as the proposal doesn't violate something in the RFC or Baseline Requirements, the CA/B Forum is probably irrelevant. Someone more knowledgable with the Baseline Requirements and RFCs might see something that makes it relevant, but IMHO the right first course of action for something like this would be to either: (i) petition LetsEncrypt to make an improvement, or (ii) develop a new RFC draft and then petition LetsEncrypt/CAB for support.
That being said, LetsEncrypt has officially opposed publishing a list of IP Addresses they use for verification for a variety of reasons, and the majority - if not all - of those reasons clearly apply to this feature request.
3 Likes
"That being said, LetsEncrypt has officially opposed publishing a list of IP Addresses they use for verification for a variety of reasons, and the majority - if not all - of those reasons clearly apply to this feature request."
This request doesn't require LetsEncrypt to publish their addresses. Do you have a link to the reasons you are referring to? I'd like to take a look at what they have said, and maybe I will agree with what you've said here.
2 Likes
Fair comment.
My opinion is that it would need to be in the specs for LE to commit to doing it. And, same for the ACME client providers. Which clients would bother to support an LE-specific augment to the traffic flow for DNS challenges? If outside the specs, would LE be happy with vendor specific fragmentation among ACME clients and providers? I think not given all the effort they put in to the ACME spec.
But, we definitely agree this is something for LE staff to comment on rather than all of us in the peanut gallery
3 Likes
Did you actually read what I wrote above?
In numerous (constant) requests for ISRG to publish a list of verification IPs, ISRG staff have made it clear they will only support publicly available DNS information, and view systems that can shield DNS records as antithetical to their mission and core values of transparency.
The implementation of Port Knocking would be fundamentally identical to using a published list of LetsEncrypt IP addresses to limit which IPs can access DNS records. Your proposal simply wraps a pattern ISRG has expressly opposed numerous times (shielded, non-public DNS records, designed for only LetsEncrypt to see) in a different piece of engineering.
The ip address topic has been discussed on this forum at length in the past. You can easily search for it and read the responses and official statements from LetsEncrypt staff.
Myself, and others, have been kind enough to take time out of our day to try and help you not waste your time on this. We've all given you more than enough information to conduct a simple search on this forum to confirm why your request is DOA and will fall on deaf ears to LetsEncrypt staff.
3 Likes
I see, thank you for a well thought out response and for your time.
Hopefully this puts and end to this thread.
2 Likes
Probably a good idea to also wait for an official reply from a Let's Encrypt staff member
4 Likes
As this is just for internal domains then you should run an internal ACME CA (e.g. Run Your Own Private Certificate Authority & ACME Server | Smallstep Blog) and add it's root certificate to your hosts.
That way there there is never any public involvement (Let's Encrypt being a public CA, naturally using public domain validation). Many organisation run their own internal CA (e.g. Windows Server has this feature built in, it's just not ACME).
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.