Public IP logging

I got this warning from certbot when using the manual plugin to request a certificate.

NOTE: The IP of this machine will be publicly logged as having requested this certificate. If you're running certbot in manual mode on a machine that is not your server, please ensure you're okay with that.

Are you OK with your IP being logged?

I understand what it's saying, but where exactly are these "publicly logged" IPs listed? I can't seem to find this list anywhere.

2 Likes

Never seen that message before. I checked on https://crt.sh/ on some of my certs and do not see any requesting IP listed. Sure am also interested to know the answer to this.

The IP addresses are currently not published anywhere. There are plans to publish logs containing those IPs, domain validation records and things like that in the future, but there’s no schedule (or any technical details on how the logs will be published) available yet.

2 Likes

Erm, why would you publish the requesting IP address? What purpose does this (too much) transparency serve?

I concur with TCM. In my opinion, publishing all certificates publicly is already kind of overstepping the line between transparency and privacy. I see no benefit whatsoever in publishing IP addresses, only the drawback of exposing origin server addresses to the public which cannot be trusted. I’m currently using LE certs to secure my connection to CloudFlare with strict SSL mode, and I’m not entirely keen on having my IP leaked to whomever might want to DDoS me (which is why I use CloudFlare).

Hi @McKay,

We’ll have to agree to disagree on publishing certificates. That’s a core part of Let’s Encrypt’s commitment to transparency, and by next October it will be required of all CAs by Chrome policy.

I will note that you do not need a Let’s Encrypt certificate to use CloudFlare’s strict SSL mode, and in general it is probably not the best choice. Cloudflare operates an internal CA, from which they will issue you a certificate for use with strict mode. That way you don’t have to validate with Let’s Encrypt every 60 days, which can be particularly tricky when you are behind a CDN.

@pfg is correct that we originally planned to publish all ACME authorization objects, along with accompanying data like IP addresses that can help third-party researchers determine patterns and develop anomaly detection algorithms. As an example, when the ACME client IP isn’t one of the validation IP, that can be a useful signal to look deeper at an authorization. We haven’t implemented the publishing yet, but it is still something we would still like to get to eventually, and it is provided for in our privacy policy.

We’ll definitely take your feedback that this is over-sharing into account.

1 Like

For DNS-01 this is almost guaranteed to be a different IP address. Why would you need anomaly detection algorithms if we have certificate transparency? Why isn't it enough for the CA to log for itself and access those logs only in case of malice?

This may legally legitimize it but it certainly doesn't do so morally. You're only setting further bad precedents to not give a sh*t about privacy policies because they usually mean the service provider is just doing whatever out-of-proportion data hoarding it wants anyway and you just get to nod and bend over.

Is there any actual effort to develop such anomaly patterns right now that would absolutely need this data? What would those patterns look like and how would they differ from every CA misuse that has been uncovered to date without the use of this data? What could you uncover that certificate transparency can't? Has anyone actually thought this through? Because right now it just sounds like a plan for the sake of a plan, without any actual need and with complete disregard for user privacy. Is there any rationale that is supported by other CAs that explains the details of this?

You could deal a severe blow to LE with this.

1 Like

There is not, which is part of why we haven't prioritized the work.

The developers of Certbot clearly thought it was worth explicitly calling out, despite being covered in the privacy policy. Isn’t there a risk that someone using a less informative client might unwittingly expose an IP address that identifies them?

In general, we don’t consider the IP addresses of publicly accessible servers to be private information. The IP address of people browsing the web, on the other hand, we do consider to be private, which is why our privacy policy specifically treats OCSP requests as more sensitive than ACME traffic.

There’s a tricky middle ground where someone might choose to run an ACME client on the same machine they do their web browsing from, but place the challenges on a public server. It’s to handle that use case that the warning was added to Certbot’s manual mode, which is sometimes used in that situation. It’s true that other clients don’t make a similar warning. Most likely if we in the future prioritize publishing more detailed validation records, we would do so with preannouncement and for forward-going validations.

3 Likes

Of course I completely agree with you about publicly accessible servers, and OCSP requests. The tricky middle ground is precisely the concern here.

So the hope would be that client developers would take note and add a similar warning to Certbot's, if appropriate? I guess that would help, at least for actively developed clients.

1 Like

I understand why certificates are published and I do agree to disagree, I just personally feel that it’s an overreach. For example, the company I work for is decentralized and we don’t have any offices, nor are our employees particularly tech-savvy. Getting everyone to install a root isn’t a very feasible idea, and leaving our backend tools unsecured is not an option. Getting everyone to set up a VPN is also not terrible feasible (not everyone is very tech savvy), so our backend systems need to be publicly accessible. Of course, we have access controls in place, but keeping addresses private is a good measure in security as well. Having a wildcard certificate would solve the problem, but unfortunately LE doesn’t seem to want to offer those.

I originally set up LE for CF strict because the CF CA didn’t exist at that time. I may want to revisit it now that I’m aware of how LE feels about the privacy of my IP addresses.

I do have another use-case for Let’s Encrypt that I plan to be integrating somewhat soon. I will be setting up a server for internal communication with other servers I control (which I’ll call the secured server here), which will be communicating over the Internet. Therefore, TLS is a must. I could set up my own root but that’s tricky to do properly and securely. I’d rather rely on something that’s already trusted by the OS and that I trust is following best security practices (Let’s Encrypt). Due to certificate transparency I won’t be able to actually use public DNS for the certs I’ll be issuing, so this is now what I’ll need to do:

  1. Set up a dedicated LE client server
  2. Use that client server to provision certs using either DNS challenge or by pointing the domain to that server
  3. Somehow get those certificates securely from the LE client server to the secured server automatically (the entire point of LE is automation, no?)
  4. In the clients that will be connecting to my secured server, spoof DNS so that the domain points to the actual secured server

I apologize for the rambling, but my situation could be made quite a bit less complex if LE didn’t decide that my IP shouldn’t be private.

There is a difference between public information and publicly indexable information. Just because my DNS server answers for all names that it knows, it doesn't allow AXFR, i.e. anyone just dumping the list of names. This is good practice.

Even if something is public information, that doesn't mean you have to actively aggregate it and shout it to the world. Is the concept of data austerity really that hard to understand? Not everything that can be done should be done.

If there isn't a use case yet, why bother even considering it? And again, what does it solve that certificate transparency doesn't?

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.