The solution: 
http://superuser.com/questions/970130/cannot-install-npapi-flash-player-plug-in-in-google-chrome 
and 
https://support.google.com/chrome/answer/6213033?hl=en

but I'd like have flash_player_ppapi install in system that in all browser of all users ... this flash_player_ppapi also works in firefox.

r414249 / working as intended?

No , I want flash installed just one time in all system, be system wild and not install in every profile of every user. This r414249 is in new beta and do exactly what I don't want, that is "Unbundle Flash on Linux". 

Thanks.

@thestig: Hey, would you mind responding to comment#5 ?

I really appreciate your help. Removing bisect label for now, feel free to add if required.

Thank you!

For many reasons, I don't think the decision to separately update Flash and Chrome ("unbundling") will be reversed, so in a technical sense this is working as intended and I'm going to mark the bug as such.

That being said, we understand that this is sub-optimal for many use cases. At this time we don't have a mechanism to install components system-wide, but this is a feature we've been looking at for a while and would like to have soon.

With Wireshark I found that Google Chrome 54 downloads Flash 23.0.0.185 PPAPI for Linux from this URL:
http://redirector.gvt1.com/edgedl/release2/rpofl8ynzf9r05ca7iim67wdwf3t0zpuehwy3aswydc9g91q5c4iydolh9lt5toluyuq2phjg168mcvxxhntm3n79e4nw3mrx1j/23.0.0.185_linux_PepperFlashPlayer.crx
It would be fairly easy to catch the DNS requests for redirector.gvt1.com to return the IP of any server.

According to this page a CRX file is a ZIP file with the author public key and a SHA-1 signature of its payload:
https://developer.chrome.com/extensions/crx

I found this topic on Stack Exchange stating that SHA-1 is not considered collision resistant, so even if the public key of the author is known to Chrome beforehand and checked against the public key in the CRX file it would still be possible to manipulate the CRX file in a way that the signature matches the payload. Still, it would require a big computational effort:
https://crypto.stackexchange.com/questions/6506/is-sha-1-still-practically-secure-under-specific-scenarios/6510#6510

Is it possible that the update mechanism of Flash implemented in Google Chrome 54 could be vulnerable to MITM attacks? Or are they more safeguards I am missing here?

There are additional protections: prior to initiating the download, the update system learned the expected SHA-256 hash of the payload from the Omaha update-check (which is in turn protected by a signing protocol called CUP). We then verify that hash prior to doing anything else with the CRX file.

You can learn more at https://github.com/google/omaha/blob/master/doc/ServerProtocolV3.md if you are curious.