OpenSSL 1.1.1 Windows dependencies

[Matt Caswell]

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