On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote: > > That was my initial thought too, except that if it were > > firewall-related, the initial port 587 connection would be blocked, > > and it isn't - the failure doesn't happen until after STARTTLS has > > been issued. > > Not necessarily. That's true for a first-generation port-blocking > firewall, but not for a packet-inspecting one. There are organizations > which use packet-inspecting firewalls to block STARTTLS because they > enforce their own TLS termination, in order to inspect all incoming > traffic for malicious content and outgoing traffic for exfiltration. 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. 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. > > Furthermore, the OpenSSL > > configuration is identical between the systems/combinations of > > OpenSSL that work and those that don't. > > Do you know that for certain? There's no openssl.cnf from some other > source being picked up on the non-working system? I'm pretty certain, but I'll get the customer to double-check. Cheers! -- David --
