Christos Zoulas <christos%zoulas.com@localhost> writes: >> On Sep 2, 2022, at 3:57 PM, Greg Troxel <gdt%lexort.com@localhost> wrote: >> >> Did I miss discussion on this? I am getting the impression that we now >> have defaults: >> no trust anchors installed >> require verification >> >> which really doesn't make sense. If I am following correctly this is a >> major behavior change in a controversial area, which isn't ok without >> discussion/consensus. > > I did not realize it was controversial, but let's have the discussion. There's been a large amount of discussion about having the base system provide a pre-configured set of trust anchors. Without that already agreed on and in place, it seems clear that changing ftp(1)'s behavior is going to be a breaking change for a lot of people, and thus well over the the needing-discussion line. >> Plus, this is a negative option, usually frowned upon. > > grep NO_ /usr/src/usr.bin/ftp/*.c I guess, and I didn't really say this earlier, but this is not really about ftp. pkix more or less says TLS should do certificate validation, but it's longstanding practice in many client programs not to validate. For the most part this is about a sysadmin/user either configuring a set of trust anchors, and deciding that that all SSL/TLS and other uses of pkix (x509) certificates should be subject to validation deciding not to play the configured trust anchor game and not turning on the "fail if not validated" switch. >> So (absent confusion on my part, as always), it sounds like one of the >> following should happen: >> >> 1) just revert this until we have discussion >> 2) change the environment variable to CERTIFICATE_VALIDATION to use the term >> from the RFC >> https://www.rfc-editor.org/rfc/rfc5280#section-6 >> and default to FALSE, enabling if set and TRUE. > > I don't care much about the environment variable name, and yes calling > it what the RFC suggests is probably better. Do you think it matters if it's an environment variable? Do you think this needs to be a user option, or system? Why environment vs comand-line like wget? >> If at some point the system installs trust anchors by default, the >> default can change. > > I think we should be installing the anchors by default. I also think > that people think that https gets validated by default. That is a separate discussion, which is totally fine to have in a new thread. This discussion is about changing the behavior of ftp to fail without validation while the system does not install trust anchors. Right now, this change acts like "disable https in ftp" for people that do not have configured trust anchors. >> Plus, I think it's reasonable to have some config file in /etc/openssl >> that signals "user has configured trust anchors and wishes to routinely >> validate certificates". The existence of /etc/openssl/VALIDATE might be >> a good trigger for validation, or some other color file. That would >> mean that the code, running on a system with old config, would not be >> surprising. Using this file now in option 2 instead of an environment >> variable seems fine. > > That is a good idea. So are you ok with: 1) Right now, in ftp(1), enable certificate validation if /etc/openssl/VALIDATE exists (and remove the env var). Tell people who want this to touch /etc/openssl/VALIDATE? 2) Sort of have a plan that if/when we configure trust anchors by default and perhaps if a package configures them (mozilla-rootcerts-openssl) that this file be created, to turn on validation for all pkix users, as the system default? This would be the interface from all trust anchor configuration schemes to all validators.
Attachment:
signature.asc
Description: PGP signature