Unable to triage the issue from test team end. Hence adding TE-NeedsTriageHelp label for triaging of the issue.

Thanks!!

I could provide you with a test page to help you solve the problem. However, I would not make this publicly accessible. Is it possible to tell the Url about another way?

Folks who work on Flash: Does Flash use the net stack's SSL code or does it use ours? I don't think it uses ours but I may be wrong.

@comment 3: I believe ours, because of https://cs.chromium.org/chromium/src/content/browser/renderer_host/pepper/pepper_tcp_socket_message_filter.h?rcl=12ed41235b2ec901fc7a3512e2aa5fcacf7a6229&l=102

You can see the TLS/SSL socket setup in https://cs.chromium.org/chromium/src/content/browser/renderer_host/pepper/pepper_tcp_socket_message_filter.cc?rcl=d36daf872d9601f32503e3c1f101e8d1395a4aa5&l=332 FWIW

Ah, okay. And of course this thing doesn't hook up a NetLog. :-(

purpleviewgmbh: Could you capture a Wireshark trace of this happening? This won't be as useful as a NetLog but might give something in the meantime.

Also, +eroman, do you know what it'd take to hook these sockets up to NetLog?

Yes no problem. Here is the Wireshark file.

Deleted: capture.pcap 456 KB

capture.pcap 456 KB Download

Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks! Judging by TCP stream 2 in that file, we seem to be shutting off the connection shortly after receiving the handshake. My guess is we're rejecting the certificate verification. Adding the certificate label in case they can spot anything obvious. The certificates are in the pcap.

Also, sorry, I missed this note:

> I could provide you with a test page to help you solve the problem. However, I would not make this publicly accessible. Is it possible to tell the Url about another way?

That would be great! Feel free to email it to me privately at davidben AT chromium DOT org, and I'll share it with the relevant team members. Thanks!

(I've filed  issue #744662  to address the lack of logging here.)

Thanks for the quick analysis of the problem.

I sent you the e-mail with the URL.

Thanks for the link! I'm able to reproduce this problem. It's here:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/pepper/ssl_context_helper.cc?type=cs&sq=package:chromium&l=30

Configuring a net::MultiLogCTVerifier isn't very useful when we never add logs to it.

Nice to see you can reproduce the problem.
When will this bug be fixed or in which Chrome version can we expect a fix?

+rsleevi

OK. We're exploring fixing this in Chrome 62, although depending on complexity, it may slip. The root cause is that sockets initiated through Flash are not observing the same browser security policies (and enterprise configuration flags), thus causing disruption.

Can you also provide a test site that repros to rsleevi@chromium.org ? Thanks :)

Is there any news? Unfortunately, the bug in the current Chrome 62 still exists.

@Ryan - Should we be normalizing Flash's behavior relative to the rest of the platform.  It gives me pause that we aren't consistently implementing the same set of security policies.

It's concerning to me as well, but unfortunately, no one has been able to suggest a way to reliably add tests for this. That is, the Flash construction of sockets is (and has always been) distinct from the rest of the profile - this also applies to other policies (such as TLS versions).

I have a patch that normalizes these behaviours, but due to the testing side, cannot be tested.