On 24/10/2022 10:17, Matt Caswell wrote:
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.
I've taken a look at the captures for the working and non-working scenarios.
Do I understand correctly that your application is acting as the server
in this setup?
I have compared the working and non-working captures. In both cases the
ClientHello is successfully received, and the server responds with a
ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message.
Aside from normal variations between one session and another, AFAICT,
the ClientHello and the server's response messages all look identical
other than the server obviously has a different Certificate. The
Certificates themselves also look identical to each other other than the
subject/subjectaltname being for a different server. The intermediate
certs are the same in both cases.
Following the server's ServerHelloDone the client continues with a
ClientKeyExchange message in the working case. In the non-working case
the the client immediately closes the TCP connection without sending any
kind of alert.
This really looks like a problem on the client side to me. Or at least
that's where attention will have to be focused for now to figure out
what went wrong. The client side has made the decision to close the
connection (or plausibly some middlebox has, but this seems unlikely
given that the handshakes up until that point look virtually identical).
Is there any possibility of getting any logs from the client side to see
why it has decided to abort the connection?
Matt
