On Sun, Mar 17, 2019 at 2:00 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Wed, Mar 6, 2019 at 9:21 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Yeah, I've still been unable to reproduce even with the sleep idea, > > so eelpout is definitely looking like a special snowflake from here. > > In any case, there seems little doubt that getting past SSL_connect() > > when the cert check has failed is an OpenSSL bug; I don't feel a need > > to create a workaround for it. > > I was wrong: it breaks on an x86 system for me too (either with the > sleep, or with clunky scheduling, I was running psql under strace when > I saw it). Not sure what I did wrong last time I tried that. I > opened a bug report with OpenSSL, let's see what they say: > > https://github.com/openssl/openssl/issues/8500
This was an intentional change in TLS1.3, reducing round trips by verifying the client certificate later. I'm pretty sure the fix I mentioned earlier -- namely adding an ad-hoc call to pqHandleSendFailure() if we fail to send the start-up packet -- would fix eelpout's measles (though obviously wouldn't solve the problem for Windows given what we have learned about its TCP implementation). I should probably go and do that, unless you want to write the more general handling for send failure you described, and are prepared to back-patch it? -- Thomas Munro https://enterprisedb.com
