• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
Locked
0

TLS1.2 problem with Flashplayer in Google Chrome

Community Beginner ,
Aug 31, 2018 Aug 31, 2018

Copy link to clipboard

Copied

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!

Views

1.1K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Community Beginner , Sep 11, 2018 Sep 11, 2018

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 Do

...

Votes

Translate

Translate
Adobe Employee ,
Aug 31, 2018 Aug 31, 2018

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 03, 2018 Sep 03, 2018

Copy link to clipboard

Copied

The security tab isn't providing any information. I thought maybe chrome isn't detecting the TLS connection because it is executed in flash. So i've set up a webserver to make a https connection with the same certificate, to test if i can get some usefull information in the security tab. The security tab says the connection failed because the root certificate wasn't installed, so i installed it and the https connection is working fine now.

So i was hoping that was the solution but it didn't have any effect for the TLS connection in flash. Does the method addBinaryChainBuildingCertificate() actually work under Chrome? Or is Chrome just using the certificates which are installed under settings (the same that IE is using).

I'm pretty much at a dead end right now. The available logging is insufficient to give me enough info to find out what is going wrong..

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 04, 2018 Sep 04, 2018

Copy link to clipboard

Copied

In theory, it should work, but the browsers are constantly moving targets.  The addBinaryChainBuildingCertificate() method is in mature code, so I doubt that it broke, but the world may have moved on. 

I'd need to reproduce it under a debugger to fully understand the reality of the situation.

I assume you have a self-signed root certificate and/or one or more intermediate certificates?  Can you give me specifics on how to build a trust chain that mirrors your scenario?

Also, what version of Windows are you using?  It seems like Chrome uses the Windows certificate manager.

I'd also be curious to know if you had the same problem with the server configured to only accept TLS 1.0 or 1.1 connections.  If that resolves the problem, it gives me a really clear signal about why it's failing. 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 05, 2018 Sep 05, 2018

Copy link to clipboard

Copied

The situation is as followed:

Server certificate (supplied by) ---------> Intermediate CA (supplied by) ---------> Root CA (which is self-signed)

I've added the wireshark logging:

wireshark.jpg

It seems like, at the moment the server sends it's certificates, the client (my  application) drops the connection.  I've installed the certificates in the Windows certificate manager. The Root CA is installed in Trusted Root Certification Authorities, the Intermediate CA is installed in Intermediate Certification Authorities. But where to install the server certificate? I installed it in Personal.

I assume the certificate chain is installed correctly but it doesn't have any effect on the TLS connection in Flash. I also tried adding the certificate chain in the source via:

secureSocket.addBinaryChainBuildingCertificate(rootCA, true);

secureSocket.addBinaryChainBuildingCertificate(intermediateCA, false);

secureSocket.addBinaryChainBuildingCertificate(userCA, false);

But this also doesn't seem to have any effect at all, the handshake still fails.

I'm using Windows 7. I will configure our server to accept TLS only 1.0/1.1 connections and will post the testresults later.

Thanks for your help! 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 07, 2018 Sep 07, 2018

Copy link to clipboard

Copied

TLS1.0/1.1 doesn't work either.

Did you manage to reproduce the problem under a debugger? The application that i'm working on, is an existing GUI where we replaced the existing (non-secure) socket connection with the TLS-variant, due to security reasons. The GUI is used by various customers and not supporting Chrome would be a major issue. Some detailed information about the cause would therefore be really appreciated

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 07, 2018 Sep 07, 2018

Copy link to clipboard

Copied

I don't have enough information to reproduce it at this point.  What I *can* tell you is that our SecureSocket tests pass.  It's not that the feature is broken in a broad and obvious way in Flash Player on Chrome.  Whatever you're running into exists at a specific intersection of the browser, operating system, server and certificate configurations.

You're either going to have to give me super detailed instructions on exactly how to reproduce that top to bottom (the specific openssl commands all the way to the server configuration) *or* ideally, just point to a public instance of the service that already exists.

Knowing that it fails across TLS 1.0 - 1.2 rules out the possibility that we didn't compile support a particular feature specific to TLS 1.2 that you're dependent on.  That's the one place where I thought there might be some risk (i.e. you were using an esoteric feature that nobody had ever complained about before because the large enterprises might not aggressively adopt a TLS 1.2-only stance and fallbacks to other configurations were masking it broadly)

I believe that addBinaryChainBuildingCertificate() is redundant in your case and is generally a red herring.

The one that jumps out at me is that the intermediateCA that you added isn't added as trusted (you're passing 'false') and the user has it's own Certificate Authority certificate, which is also added as untrusted.  I don't really understand why the client has it's own Certificate Authority.  If it's just a client certificate, are you employing some kind of mutual authentication scheme that involves client certificate validation on the server side?

Both of those things seem weird, but the whole thing about the addBinaryChainBuildingCertificate() method is that it's supposed to add those keys temporarily to the system keystore.  Chrome is already using the regular Windows keystore, and if you've already added these certificates there, then they should be getting evaluated without needing to add them from ActionScript.  The fact that it doesn't help most likely bears this out.


My intuition, based on what I understand above, is that you're running into a scenario where Chrome is being more strict about something than the other browsers.  The only thing I expect to find under a debugger is a more precise answer about why the browser is rejecting the connection.

You *might* get something useful by running the Flash Player Debugger variant (if you haven't tried that already).

Also, are you serving a socket policy file already?  The server has to grant permission to Flash Player before we're going to allow a socket connection.  I don't see any calls to port 853 in your traffic capture.  Maybe your socket policy needs to be updated to allow the connection to the secure port(s)?

Setting up a socket policy file server | Adobe Developer Connection

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 10, 2018 Sep 10, 2018

Copy link to clipboard

Copied

jeromiec83223024  schreef

The one that jumps out at me is that the intermediateCA that you added isn't added as trusted (you're passing 'false') and the user has it's own Certificate Authority certificate, which is also added as untrusted. 

I'm not a TLS-expert, but i'm assuming that only the rootCA should be added as trusted, as it is the trust anchor:

"The certificate you add with this API must be a DER-encoded X.509 certificate. If the trusted parameter is true, the certificate you add with this API is considered a trusted anchor."

See:

Trust anchor - Wikipedia

jeromiec83223024  schreef

If it's just a client certificate, are you employing some kind of mutual authentication scheme that involves client certificate validation on the server side?

The name "userCA" is just poorly chosen, it is the certificate which is send by the server to the client. I added it to the chain because it is part of it, right? It is used for server certificate validation on the client side.

jeromiec83223024  schreef

Both of those things seem weird, but the whole thing about the addBinaryChainBuildingCertificate() method is that it's supposed to add those keys temporarily to the system keystore.  Chrome is already using the regular Windows keystore, and if you've already added these certificates there, then they should be getting evaluated without needing to add them from ActionScript.  The fact that it doesn't help most likely bears this out.

So according to you i can just remove  the calls to addBinaryChainBuildingCertificate() because they are unnecessary anyway?

jeromiec83223024  schreef

Also, are you serving a socket policy file already?  The server has to grant permission to Flash Player before we're going to allow a socket connection.  I don't see any calls to port 853 in your traffic capture.  Maybe your socket policy needs to be updated to allow the connection to the secure port(s)?

We are serving the sockey policy file. But it in this case Flash is not requesting a socket-policy file because i'm opening the .SWF local on my PC in chrome. (well actually the generated .html-file which opens the .swf-file.)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Sep 10, 2018 Sep 10, 2018

Copy link to clipboard

Copied

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?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 11, 2018 Sep 11, 2018

Copy link to clipboard

Copied

LATEST

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!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines