TLS1.2 problem with Flashplayer in Google Chrome

Question

Hi there,I'm working on a Flash-application which connects to a server using the TLS1.2 protocol, i've used the SecureSocket-class to setup the connection. According to the documentation, i've setup my certificate chain using the addBinaryChainBuildingCertificate() method.I tested my application with the standalone flashplayer and in 3 different browsers (Google Chrome / Internet Explorer / Mozilla Firefox) and it is working fine in the standalone flashplayer and in IE and Firefox, but the TLS1.2 connection isn't working in Chrome. According to the wireshark logs my application suddenly drops the connection after the TLS handshake is completed.The flash debug log says an IOErrorEvent occurred with code #2031 and the servercertificateStatus = Invalid. I'm assuming something went wrong with validating the certificate, but why? Is Chrome handling the validation differently than IE / Firefox?I'm using Flash player 30.0.0.154 and Google Chrome 68.0.3440.106.I'm hoping someone can help me out here..Thanks in advance!

bartv87537168 · Accepted Answer

Running content from the local filesystem introduces another level of complexity.

As a test, you might try running it from a local webserver (MAMP/XAMPP/etc offer super easy solutions). Do you see the policy file requests at that point?

Yes we are running it from a local webserver. We implemented the policy file on the same port as which the connection is made, but this fails in Chrome because the policy file request is also using a TLS connection, which fails ofcourse.

Can i get in contact via mail or PM? I want to distribute our chain of trust and the IP of our server which is handling the TLS-connection with the client.

Edit: Resolved! The SAN (Subject Alternative Name) in our certificate was configured to secure a certain Domain. For testing-purposes i was running the server locally on my PC. So i configured the windows-hosts file to resolve that Domain in to -> 127.0.0.1, and let our Flash-application connect to that domain.

Apparently Chrome doesn't accept this, because I configured the server on an other PC and editted the hosts-file to resolve the domain to the ip where the server is running now. It is connecting properly now

Thanks for your assistance!

jeromiec83223024 · Answer

Everything in Chrome is mediated, so where we would have used a native network stack to make those connections in NPAPI and ActiveX, we're asking PPAPI to make those connections on our behalf. Chrome also has it's own TLS library called BoringSSL, so you're not using the system's SSL support or OpenSSL under the hood.

Chrome changed the way that they do the TLS handshake on sockets a few years ago. I don't remember the exact specifics, but I remember there being an additional step. We ended up rewriting the test socket server to accommodate it, but we went from using a Java-based socket server that someone had written in the early 2000s to using Python. I think the change was really that Python was just using a more current SSL library than what was compiled into the Java applet.

I'm not sure if that's helpful. I don't have enough specifics to give you any precision recommendations beyond acknowledging that Chrome is a unique beast, and to maybe check out the Security tab in Chrome to see if you get anything useful. We don't have great logging for this, so we'd probably have to reproduce it under a C++ debugger to really understand where it's falling apart. I'm not sure that I'd put a whole lot of weight into the accuracy of that error.

If your certificate chain validates elsewhere, it *might* be that Chrome is more strict for some reason, but you should be able to confirm that it's not the chain by throwing up a trivial socket listener with Python or Node to see if you get different results.

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.