Re: buildfarm server suddenly not talking to old SSL stacks? - Mailing list pgsql-www

Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Jul 17, 2018 at 7:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> The old config rejected sslv2 and sslv3, but allowed tlsv1.
>>> The new one refuses both tlsv1 and tlsv1.1, allowing only tlsv1.2.
>>> As a check if this might be it, I have at least temporarily removed that
>>> restriction. Can you try again now?

>> Same results, both via curl and via perl.

> Ha. I changed the client config instead of the server :/ Sorry about that,
> once more?

Better.  On prairiedog, I now get

$ curl https://buildfarm.postgresql.org/branches_of_interest.txt
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). The default
 bundle is named curl-ca-bundle.crt; you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

and with -k it actually works:

$ curl -k https://buildfarm.postgresql.org/branches_of_interest.txt
REL9_3_STABLE
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
HEAD

and what's more useful for the purpose at hand, so does perl:

$ perl -MLWP::Simple -MLWP::Protocol::https -e
'LWP::Simple::getprint("https://buildfarm.postgresql.org/branches_of_interest.txt");'
REL9_3_STABLE
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
HEAD

The fact that Perl is happy may have something to do with my having just
updated Mozilla::CA on these machines, which so far as I can find is Perl's
only source of root certs.  But curl is using the OS' keystore which of
course is horribly behind the times.

The results on dromedary are even more interesting:

$ curl https://buildfarm.postgresql.org/branches_of_interest.txt
REL9_3_STABLE
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
HEAD

(So, system keystore less out of date here...)

$ perl -MLWP::Simple -MLWP::Protocol::https -e
'LWP::Simple::getprint("http://buildfarm.postgresql.org/branches_of_interest.txt");'
500 Can't connect to buildfarm.postgresql.org:80 (No route to host)
<URL:http://buildfarm.postgresql.org/branches_of_interest.txt>

$ perl -MLWP::Simple -MLWP::Protocol::https -e
'LWP::Simple::getprint("https://buildfarm.postgresql.org/branches_of_interest.txt");'
REL9_3_STABLE
REL9_4_STABLE
REL9_5_STABLE
REL9_6_STABLE
REL_10_STABLE
REL_11_STABLE
HEAD

I have no idea what to make of the fact that http: still fails with this
perl version.  But I think we've conclusively proven that the problem with
https: is down to these machines trying to use tlsv1.

So the next question is what to do about it.  Is tls < 1.2 officially
deprecated these days, or was that configuration change just accidental?

I can probably restore these machines to functionality by updating
whichever Perl module knows about TLS (anyone know which that is?),
so if you want to undo the config change, it's OK by me.  But other
owners of ancient buildfarm critters might be less happy about it.

            regards, tom lane