On 22/10/2022 16:02, David Harris wrote:
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.
I'm not promising anything. But if you send me the captures I can take a
look at them.
Matt
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 --
