The reason why the player's URLLoader works OK with a proxy is that it relies on Flash's engine, which relies on the browser's engine to do these things. The browser will ultimately take direction from the OS if there is a proxy in play or not and route traffic correctly in that case. We would have to do this by hand, which is not impossible, but not a quick fix. The other issue is that a proper proxy would proxy the SSL/TLS requests. By all right they would issue their own certificate with the proxy listed as a "common name" on the certificate presented and use a locally generated, but trusted certificate. Again, we could do this, but it requires a large amount of work to reinvent what we pretty much already have.
The whole point of this exercise was to get around people's own misconfigurations -- namely still allowing really old encryption that some servers didn't support by default. If the number of failures is great enough, we can implement it, but I doubt it is. Adding a separate config screen to support proxies is doable, and then we are in proxy mode we would just accept all certificates would be the easiest option if we do want to move on it. -Nick On Tue, Jul 7, 2015 at 12:50 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 7/6/15, 8:42 PM, "Nicholas Kwiatkowski" <nicho...@spoon.as> wrote: > > >Unfortunately, by running our own HTTP client (and bypassing the built-in > >Flash/Browser client), we won't be able to automatically tunnel through a > >proxy. We can build a config screen to allow a proxy to be entered, but > >we > >won't be able to verify SSL certs then (we would have to allow everything > >through). Is that the direction we want to go? > > I remember you mentioning this before. I don’t have any background in the > underlying technology. What magic do the runtimes have that we can’t > execute with sockets? Could we make a URLLoader request to verify a cert? > > -Alex > >
