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

Forum|Forum|8 years ago
April 25, 2018
2 replies
1013 views

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.

flash player 29

This topic has been closed for replies.

jeromiec83223024

Inspiring

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

D

DominicC123Author

Participant

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

Inspiring

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...

jeromiec83223024

Inspiring

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.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.