Failure to connect to RTMPS endpoints when using 29.0.0.xxx in IE11

[DominicC123]

Some of our clients have complained that since upgrading the flash player to 29.0.0.xxx (either .113 or .140), connections via RTMPS to our LCDS adaptors are failing to be established. Downgrading to 28.0.0.161 resolves the issue. The issue seems to affect users of IE11 on Windows. Switching to Chrome using v29 also seems to work.

What has changed in v29 for IE11 that might cause this? Could it be related to changes for handling TLS or cipher suites?

I can see 2 lines items in the release note, that might be related - Release Notes Flash Player 29 AIR 29 :

• SecureSocket and RTMPS with OpenSSL is not sending "server_name" SNI headers.
• Flash Player will not connect via SecureSocket to a server running only TLS1.2.

So far we've been unable to reproduce this ourselves or capture any error messages.

[jeromiec83223024]

This is the first complaint I've heard.  We're talking about a range of a few hundred changelists. 

Given that the impact is very limited (and I'm guessing isolated to specific clients' network environments), I'm thinking that we're more likely to have exposed a latent misconfiguration in their network environment.  (e.g. there's a proxy, security gateway, TLS configuration that wasn't getting used previous that's now in play.)

Some logs from a debugging proxy on a failing client would be really useful.

[jeromiec83223024]

Also, if you can determine any other patterns (e.g. the problem is exclusive to Win7 and below), that would be really helpful.

[DominicC123]

We have established that the issue is still present in v30 as well. It affects IE11 & Firefox, but not Chrome or Opera. This could indicate that there is a difference between the PPAPI and NPAPI implementations.

[jeromiec83223024]

We made a number of bugfixes on this front, so I'm surprised that it's still not working for you.  Also, yes, Flash Player implementations for ActiveX, NPAPI and PPAPI are significantly different.

That said, we've already shipped (and tested) the following changes:

• We now correctly send SNI headers on SecureSocket and RTMPS requests (Flash Player 29.0.0.99 and higher)
• The 64-bit Firefox bug preventing RTMPS and SecureSocket connections was resolved in Firefox 56 and higher
• The issue with connections to a server only running TLS 1.2 issue was resolved in Flash Player 29.0.0.45 and higher (and definitely in the 30 branch)

It might be worth taking a look to see why it's still failing.  I'm wondering if we're getting hung up on something new now, or if we need to figure out how to more accurately replicate your environment to capture some nuance about one of these existing issues...

[DominicC123]

A number of our clients are still experiencing problems. Around the time of the release of Flash Player 29, we also deployed a new TLS certificate signed by DigiCert. A number of of our clients block all http requests unless they have been whitelisted. I was wondering therefore if there have been any changes regarding Certificate Revocation List (CRL) checks. Clearly the CRL checks for a new certiicate issuer would be sent to a different http endpoint, that might be blocked by a firewall or proxy. Have there been any changes in v29 related to handling CRL checks that fail or time out. What happens for example if a proxy returns a 407 response or does not return a response? Do you delegate these checks to the browser, even for RTMPS connections? Could a recent Microsoft IE11 security patch have broken how the Flash Player makes CRL checks?

Thanks for your continuing help with this matter.

[jeromiec83223024]

The answers vary depending on the browser and operating system that we're talking about, and I'd want to go through it exhaustively if were going to get into specifics.

It's probably far more productive to just look at the ground truth (e.g. network capture) from affected clients to build an understanding of what's still failing.

In general, my understanding is that when CRL checks cannot be completed, the browser simply considers the certificate to be valid.  I think you're probably looking in the wrong place for an answer, but without a concrete understanding of what's happening at the affected client, we're just guessing about what it is.

[DominicC123]

From the Wireshark capture it looks like the TCP connection cannot be established. There is no ACK response.

I have asked the client for a capture using Flash Player 28.0.0.161 for comparison.

One observation I've made when I have seen it working is that the ECN & CWR flags are not set on the TCP packet. Can't be sure yet if this is related.