Let’s image a new TLS vulnerability is discovered, which also affects the TLS configuration used by the LE client. Alternatively it could also just have a new suggested TLS cipher list.
Can the LE client update these one? Either automatically or after asking the admin somehow?
Or how would you react in such a case? Send a mail to all Let’s Encrypt users?
But AFAIK you don’t have to specify a mail when using LE so it’s not clear whether such mails would reach everyone affected?
@rugk, we have not implemented functionality that does this. This would be a good policy question to look at in the future. My intuition is that in order to make these changes retroactively, we would want to disclose this behavior beforehand, and also give users a way to opt out of it if they don’t want it.
it is kind of technically feasible for people who are using an operating system package that would be updated by their operating system distributor. The client version could be replaced by a newer version that would be capable of making this change (if the user were using a server application that we have appropriate integration for). In other cases, we couldn’t do it – we don’t have anything in the network protocol or in the client software today that would be able to make these kinds of changes retroactively even if we believed it were appropriate to do so.
I completely agree. Such changes should never be made without consents of the web admin IMHO.
Yes I have never thought about this. Of course it's just a Phyton script that's executed so it has no self-update mechanism.
Basically what should at least be done in such a case is sending a mail to all LE cert users. However that's difficult is not it? Because the mail is not required for getting a cert.
Possibly you should (highly) recommend users to give at least one contact information to LE it is needed. Additionally: For now: Is it possible to enter a mail address in the LE client (in the "graphical" CLI mode) already?
this strikes me as the sort of thing a lot of packages deal with and at least from my experience if you factored out the cipher list into a configuration option it gives you some options, like a prompt when you update the package about switching or not, where it doesn’t conflict with any distribution guidelines I would probably prefer it see to default to changing the setting if you just click through (well, actually enter/return through given you are likely on the cli) but that way a user who knows what they are doing and knows those prompts should be looked at a bit more carefully can take the time to decide if it’s right for them and there is a notification that must be looked at and acted on prior to changing any configuration, while keeping the basic user that’s still root (perhaps a vps, etc) up to date by default. I also hesitate to like any move where new and old sites are treated differently by default, if I do a testing site dev.example.com I don’t want it to do something different when I later deploy it at www.example.com . It also creates differences across site’s configurations and that makes it harder to keep track of things or figure out why one site is fine and another isn’t or why the new site you just added doesn’t work when the one you did the exact same way a month ago does.
This sounds like it mostly fits your disclose and opt out belief though I’d like it to not be about retroactive changes but about changing the cipher suite on managed sites (the factoring out into a configuration option also would allow for a system wide override by the user of the list if they have special needs I guess as well). I’d want to make sure that any notify and opt out required an affirmative action prior to doing it as well, like the screen during package update so zero action (like not applying updates or only automatic updates which the system can do unattended) won’t change things.
I’m not sure about the nitty gritty details of packaging but it may be you would need it to be a special file for the cipher list rather than a configuration line to reliably change that in an update without overwriting the rest of the configuration.
Forming a plan here: https://github.com/letsencrypt/letsencrypt/issues/1123
(But in short, the answer is “we should automate by default, notify the user that that is happening, and give them full control to turn it off”)
Definitely need option to turn it off for folks wanting to specify their own config and cipher list 