Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Le sam. 20 juil. 2019 à 20:54, Daniel Shahaf a écrit : > > Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00: > > But as a user I find it infuriating when software I use contains > > artificial restrictions like this. We should assume our users know > > what they are doing. Subversion is not a web browser. > > I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for > example: > > [[[ > % ed .ssh/known_hosts > g/^hermes/d > s/^[^ ]*/hermes.apache.org/ > w > q > % ssh hermes.apache.org > @@@ > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A. > Please contact your system administrator. > Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this > message. > Offending ECDSA key in /home/daniel/.ssh/known_hosts:26 > remove with: > ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org > ECDSA host key for hermes.apache.org has changed and you have requested > strict checking. > Host key verification failed. > zsh: exit 255 ssh hermes.apache.org > ]]] > > The error message does not give a way to continue the operation, but it > does tell you what command to run if you would like to proceed anyway. > This way, the buck stops with the user, but the program makes it quite > clear that this is an abnormal situation and caution should be > exercised. > > Should we do something similar (but without the all-caps? That's why > I proposed writing a command that takes a certificate on stdin and marks > it as trusted. > > Daniel >From a user perspective, I would also appreciate to be able to take my responsibilities to accept unsafe operations. Having the choice to can accept permanently the certificate, and then getting a special warning message to confirm I really know what I do, because there is unknown errors reported, would definitively help to report the responsibilities on the users while let him/her chose to take (or not) the said responsibilities. Best Regards, Pierre.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Le sam. 20 juil. 2019 à 16:55, Nico Kadel-Garcia a écrit : > > On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès wrote: > > > > Hi all, > > > > I have a script accessing an old svn server whom SSL certificate have > > expired a long time ago. Up to now, I was permanently accepting the > > certificate on the first run of the script and then everything was > > sailling smooth. I reinstalled a couple of months ago a new box where > > this script was intented to run and the (p)ermanently option seems not > > provided anymore. > > Negotiating certificate trust can be fun. Can you sidestep the whole > issue by switching to svn+sh? Or get new, signed certificates? > > > Thankfully, I still have the "old" running box to double-check, and > > the (p)ermanently option is still present. Both boxes are Debian > > Buster (but was installed as unstable, before the official release). > > The (p)ermanently option was also present in svn on previous versions > > of Debian. > > > > I can notice that the versions of svn changed between my old and new > > box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the > > change-log [1] and it doesn't seem specified this option has been > > removed. I also gave a look on openssl version and it went upgraded > > from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal > > of the (p)ermanently option is linked or not the openssl upgrade. > > > > If some of you have an hint and an half to explain how and why this > > option disapeared, that would be really nice. I wonder if it was meant > > or not, to see where I'm headed. > > > > More over, I would really appreciate if someone could share a solution > > to still permanently accept the certificate on the new box, as for > > now, I can't use this box and the old one should soon be > > decommissioned. > > Stefan has correctly pointed out ways to get your client, at run-time, > to accept failed certificates. But what is stopping you from replacing > the certificate? It's on the todo-list for quite a long time but never find it ways to get to prime time. We decided to migrate this server to a new infrastructure and it will benefits from automatically renewed Let's Encrypt certificates. That will eventually address all points. But as things works well and wouldn't add significant benefits, we didn't haven't scheduled the operation so far. The server is running smooth and used only for internal use, so by the time Let's Encrypt wasn't here, we didn't felt to spent some money on buying a certificate from a trusted authority. As self certificates (rightly) reported an error, we already had to « accept permanently » the certificate when we was re-configuring a new client instance. Then the certificate expired. This added one line in the warnings, but didn't really change a thing for us, so we didn't felt the urge to renew the certificate. We knew which it was and we trusted it. More over, the encountered problem seems that the self-signed certificate switched from being reported as "not trusted" to "unknown error". The cause then seems rooted in the self certification, so I'm not sure issuing a new self-signed certificate would solve the problem ? Best Regards, Pierre.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Le ven. 19 juil. 2019 à 20:44, Stefan Sperling a écrit : > > On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote: > > On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourčs wrote: > > > Hi all, > > > > > > I have a script accessing an old svn server whom SSL certificate have > > > expired a long time ago. Up to now, I was permanently accepting the > > > certificate on the first run of the script and then everything was > > > sailling smooth. I reinstalled a couple of months ago a new box where > > > this script was intented to run and the (p)ermanently option seems not > > > provided anymore. > > > > If you're scripting 'svn' you should be using the --non-interactive option. > > > > In which case your script can use the --trust-server-cert-failures > > option to accept a cert in pre-determined failure cases. > > > > 'svn help update', for example, displays the following information > > section about the --trust-server-cert-failures option: > > > > --trust-server-cert-failures ARG : with --non-interactive, accept SSL > > server > > certificates with failures; ARG is > > comma-separated > > list of 'unknown-ca' (Unknown Authority), > > 'cn-mismatch' (Hostname mismatch), 'expired' > > (Expired certificate), 'not-yet-valid' (Not yet > > valid certificate) and 'other' (all other not > > separately classified certificate errors). > > > > Once your script uses this option it should work out of the box against > > your problematic server and there should be no need to save the cert. > > Follow-up regarding your actual question: > > It looks like the interactive prompt omits an option to save the cert > if it sees a certificate failure of class 'other' from the above list. > I am not sure why this decision was made but that's what the current > code seems to do. So I suspect your SSL cert is failing for some reason > other than unknown-ca, cn-mismatch, expired, not-yet-valid. > > Additionally, the ability to save a cert is also disabled if the > --no-auth-cache option is used. Hi, Sorry for the delay and thanks a lot for the answers. In fact, I did read about the non-interactive option but this question [1] made me thought it wouldn't work. Having tried with --trust-server-cert and got errors, I thought this was it. I didn't saw there also was a --trust-server-cert-failures. I should have better read the docs and see one can specify the nature of the error to silent in order to consider the certificate as trustable ! I'm now able to proceed in non-interactive mode on the new instance accessing the svn-server. Thanks. However, I couldn't find a way to store the password. Of course, this is non-interactive mode. Nonetheless, could it be a way to store the credentials ? If so this would save me some time to tweak the scripts (and the need to export credentials variables before running the scripts). About the interactive prompt omitting the (p)ermanently save in case of 'other' errors, you're right on spot, the class 'other' appeared as reported errors in the instance running 1.10.4. I did a little more investigation now that I better understand the inner functioning of the certificate validation. What's really strange is that the error nature changed from svn 1.10.2 to 1.10.4 while accessing the same svn server, and thus, the same certificate. It's a self signed certificate, and is rightly considered so in 1.10.2, as not trustable, but is reported as an unknown certificate error in 1.10.4 (as the logs attests). This would clearly explain why the (p)ermanently option disappeared. Nonetheless, I wonder why « unknown authority error » is now reported as « other error » in 1.10.4. Was it meant or is it a regression ? pierre@edtv-01-pierre:~$ svn --version svn, version 1.10.2 (r1835932) compiled Aug 4 2018, 16:28:03 on x86_64-pc-linux-gnu pierre@edtv-01-pierre:~$ LANG=C svn co https://svn.---.fr/--- --- Error validating server certificate for 'https://svn.---.fr:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! - The certificate hostname does not match. - The certificate has expired. (R)eject, accept (t)emporarily or accept (p)ermanently? pierre@edtv-08-pierre:~$ svn --version svn, version 1.10.4 (r1850624) compiled Jan 23 2019, 03:41:34 on x86_64-pc-linux-gnu pierre@edtv-08-pierre:~$ LANG=C svn co https://svn.---.fr/--- --- Error validating server certificate for 'https://svn.---.fr:443': - The certificate hostname does not match. - The certificate has expired. - The certificate has an unknown error. Certificate information: (R)eject or accept (t)emporarily? Best Regards, Pierre. [1] https://unix.stackexchange.com/questions/318169/svn-automatically-accept-server-certificate
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
On Sat, Jul 20, 2019 at 2:54 PM Daniel Shahaf wrote: > > Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00: > > But as a user I find it infuriating when software I use contains > > artificial restrictions like this. We should assume our users know > > what they are doing. Subversion is not a web browser. > > I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for > example: > > [[[ > % ed .ssh/known_hosts > g/^hermes/d > s/^[^ ]*/hermes.apache.org/ > w > q > % ssh hermes.apache.org > @@@ > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A. > Please contact your system administrator. > Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this > message. > Offending ECDSA key in /home/daniel/.ssh/known_hosts:26 > remove with: > ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org > ECDSA host key for hermes.apache.org has changed and you have requested > strict checking. > Host key verification failed. > zsh: exit 255 ssh hermes.apache.org > ]]] > > The error message does not give a way to continue the operation, but it > does tell you what command to run if you would like to proceed anyway. > This way, the buck stops with the user, but the program makes it quite > clear that this is an abnormal situation and caution should be > exercised. > > Should we do something similar (but without the all-caps? That's why > I proposed writing a command that takes a certificate on stdin and marks > it as trusted. OpenSSH is an interesting example. The "known_hosts" file has been an active detriment to DHCP based environments, where the same machine may be rebuilt with the same hostname but a different IP address or different hostkeys, for decades. The easy solution is to discard the use of known_hosts, as documented all over the web, but summed up best by these entries in /etc/ssh/ssh_config or in $HOME/.ssh/config Host * StrictHostKeyChecking no UserKnownHostsFile /dev/null LogLevel ERROR This trick is most useful in environments where people use svn+ssh and the IP address of the Subversion server may change at unpredictable times. It's also very useful for Jenkins, and Ansible, tasks that may reach out to a Subversion server and don't want to have the known_hosts fuss on a regular basis. known_hosts, like SSL certificat signatures, has its security uses. But it has often proven a burden rather than a blessing.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00: > But as a user I find it infuriating when software I use contains > artificial restrictions like this. We should assume our users know > what they are doing. Subversion is not a web browser. I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for example: [[[ % ed .ssh/known_hosts g/^hermes/d s/^[^ ]*/hermes.apache.org/ w q % ssh hermes.apache.org @@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A. Please contact your system administrator. Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/daniel/.ssh/known_hosts:26 remove with: ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org ECDSA host key for hermes.apache.org has changed and you have requested strict checking. Host key verification failed. zsh: exit 255 ssh hermes.apache.org ]]] The error message does not give a way to continue the operation, but it does tell you what command to run if you would like to proceed anyway. This way, the buck stops with the user, but the program makes it quite clear that this is an abnormal situation and caution should be exercised. Should we do something similar (but without the all-caps? That's why I proposed writing a command that takes a certificate on stdin and marks it as trusted. Daniel
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès wrote: > > Hi all, > > I have a script accessing an old svn server whom SSL certificate have > expired a long time ago. Up to now, I was permanently accepting the > certificate on the first run of the script and then everything was > sailling smooth. I reinstalled a couple of months ago a new box where > this script was intented to run and the (p)ermanently option seems not > provided anymore. Negotiating certificate trust can be fun. Can you sidestep the whole issue by switching to svn+sh? Or get new, signed certificates? > Thankfully, I still have the "old" running box to double-check, and > the (p)ermanently option is still present. Both boxes are Debian > Buster (but was installed as unstable, before the official release). > The (p)ermanently option was also present in svn on previous versions > of Debian. > > I can notice that the versions of svn changed between my old and new > box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the > change-log [1] and it doesn't seem specified this option has been > removed. I also gave a look on openssl version and it went upgraded > from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal > of the (p)ermanently option is linked or not the openssl upgrade. > > If some of you have an hint and an half to explain how and why this > option disapeared, that would be really nice. I wonder if it was meant > or not, to see where I'm headed. > > More over, I would really appreciate if someone could share a solution > to still permanently accept the certificate on the new box, as for > now, I can't use this box and the old one should soon be > decommissioned. Stefan has correctly pointed out ways to get your client, at run-time, to accept failed certificates. But what is stopping you from replacing the certificate? > Best Regards, > Pierre > > [1] https://svn.apache.org/repos/asf/subversion/tags/1.10.4/CHANGES
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
On Sat, 20 Jul 2019, 11:51 Stefan Sperling, wrote: > > But as a user I find it infuriating when software I use contains > artificial restrictions like this. We recently disabled plaintext password storage (by default) in the build configuration, making it effectively unavailable to users who don't build from source. The rationale for that decision was the same as for not permanently trusting certs with unknown failures. We should assume our users know > what they are doing. Subversion is not a web browser. > I will refrain from spelling out the snide remark that immediately comes to mind. :) What we *should* do is use any platform APIs available for cert validation, as I already mentioned on the other thread in my response to Evgeny's commit. One might wish that OpenSSL through Serf took care of that, but unfortunately it does not, so it's up to us. Given the growing popularity of Let's Encrypt's server certs with 3 months validity, the potential for user infuriation may be growing quite quickly. -- Brane >
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
On Fri, Jul 19, 2019 at 09:52:32PM +, Daniel Shahaf wrote: > Stefan Sperling wrote on Fri, 19 Jul 2019 18:45 +00:00: > > It looks like the interactive prompt omits an option to save the cert > > if it sees a certificate failure of class 'other' from the above list. > > I am not sure why this decision was made but that's what the current > > code seems to do. > > The rationale is that if we don't know what the failure reason _is_, we > don't know whether it's safe to ignore it permanently. In other words, > it only offers "permanently" if the failure bits are all whitelisted. > > The downside is that there's no easy way for a user to say "I know what > I'm doing, and I _do_ want to ignore this permanently; make it so", such > as a utility that takes a PEM form certificate (on, say, stdin) and > marks it as permanently trusted. At the point where we're already asking the user, we might as well let the user decide what to do, in any case. Yes, some people might then save a bad cert without knowing any better. But as a user I find it infuriating when software I use contains artificial restrictions like this. We should assume our users know what they are doing. Subversion is not a web browser.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Stefan Sperling wrote on Fri, 19 Jul 2019 18:45 +00:00: > It looks like the interactive prompt omits an option to save the cert > if it sees a certificate failure of class 'other' from the above list. > I am not sure why this decision was made but that's what the current > code seems to do. The rationale is that if we don't know what the failure reason _is_, we don't know whether it's safe to ignore it permanently. In other words, it only offers "permanently" if the failure bits are all whitelisted. The downside is that there's no easy way for a user to say "I know what I'm doing, and I _do_ want to ignore this permanently; make it so", such as a utility that takes a PEM form certificate (on, say, stdin) and marks it as permanently trusted. > So I suspect your SSL cert is failing for some reason > other than unknown-ca, cn-mismatch, expired, not-yet-valid.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote: > On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourès wrote: > > Hi all, > > > > I have a script accessing an old svn server whom SSL certificate have > > expired a long time ago. Up to now, I was permanently accepting the > > certificate on the first run of the script and then everything was > > sailling smooth. I reinstalled a couple of months ago a new box where > > this script was intented to run and the (p)ermanently option seems not > > provided anymore. > > If you're scripting 'svn' you should be using the --non-interactive option. > > In which case your script can use the --trust-server-cert-failures > option to accept a cert in pre-determined failure cases. > > 'svn help update', for example, displays the following information > section about the --trust-server-cert-failures option: > > --trust-server-cert-failures ARG : with --non-interactive, accept SSL server > certificates with failures; ARG is > comma-separated > list of 'unknown-ca' (Unknown Authority), > 'cn-mismatch' (Hostname mismatch), 'expired' > (Expired certificate), 'not-yet-valid' (Not yet > valid certificate) and 'other' (all other not > separately classified certificate errors). > > Once your script uses this option it should work out of the box against > your problematic server and there should be no need to save the cert. Follow-up regarding your actual question: It looks like the interactive prompt omits an option to save the cert if it sees a certificate failure of class 'other' from the above list. I am not sure why this decision was made but that's what the current code seems to do. So I suspect your SSL cert is failing for some reason other than unknown-ca, cn-mismatch, expired, not-yet-valid. Additionally, the ability to save a cert is also disabled if the --no-auth-cache option is used.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourès wrote: > Hi all, > > I have a script accessing an old svn server whom SSL certificate have > expired a long time ago. Up to now, I was permanently accepting the > certificate on the first run of the script and then everything was > sailling smooth. I reinstalled a couple of months ago a new box where > this script was intented to run and the (p)ermanently option seems not > provided anymore. If you're scripting 'svn' you should be using the --non-interactive option. In which case your script can use the --trust-server-cert-failures option to accept a cert in pre-determined failure cases. 'svn help update', for example, displays the following information section about the --trust-server-cert-failures option: --trust-server-cert-failures ARG : with --non-interactive, accept SSL server certificates with failures; ARG is comma-separated list of 'unknown-ca' (Unknown Authority), 'cn-mismatch' (Hostname mismatch), 'expired' (Expired certificate), 'not-yet-valid' (Not yet valid certificate) and 'other' (all other not separately classified certificate errors). Once your script uses this option it should work out of the box against your problematic server and there should be no need to save the cert. Regards, Stefan