> From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of David > Harris > Sent: Saturday, 22 October, 2022 09:02 > > I now have wireshark captures showing the exchanges between the working > instance and the non-working instance respectively; the problem is definitely > happening after STARTTLS has been issued and during the TLS handshake.
A packet-inspecting firewall can monitor a TLS handshake (for TLS prior to 1.3) and terminate the conversation if it sees something in the unencrypted messages - ClientHello, ServerHello, ServerCertificate, etc - that it doesn't like. It's not beyond imagining that an organization would have a packet-inspecting firewall that terminates conversations using particular cipher suites, for example. > I'm not high-level enough to be able to make any sense of the negotiation > data though. The wireshark capture is quite short (22 items in the list) > and I don't mind making it available if it would be useful to anyone. Someone might be able to tell something from it. Not much else is coming to mind, I'm afraid. It would help to know what system call is failing, with what errno value, but that's going to be a bit tough to determine on Windows. ProcMon, maybe? And it's curious that the OpenSSL error stack is empty, but without being able to debug you probably couldn't track that down, short of instrumenting a bunch of the OpenSSL code. -- Michael Wojcik
