Would anyone know the reason why "SSL Inspection" feature prevents the actual https redirected stream (after commersial splash)?
Example videos: http://www.pelicans.fi/pelicans-tv?id=348379
I'm using version 22.214.171.124 with default policy and activated SSL Inspection within SSL Scanner's Content Inspection.
And I simply cannot find a way to log this failure reason.
Hope this explanation makes sense.
Thanks for the prompt reply Andre!
I received 0 for the above link.
I attached connection tracing files and Firebug screen shot.
When I disable SSL Inspection the videos can be seen and both FFand IE have the same issue.
If I copy-paste the redirected link https://dhq5.dreambroker.fi/com.php?action=getvid&inc=f3202f9cd14de7a75ff6d61ba39a6053da9ce4f4&usern...
then MWG screen starts processing the video download. So it's embedded Flash player that will not process the video, as seen in the capture.
Seems to be some kind of redirect-flash-ssl-scanner misbehavior, dunno.
The last entry in the Firebug output is interesting. You can see the "progress?id=" entry? It seems for me that MWG is trying to apply progress pages to the stream, which will cause it to break. If you look through your policy you should find somewhere in the common rules the rules that apply progress pages for bigger downloads.
The problem is that the Web Server is not telling us that the stream it sends is multimedia content. Instead it announces that it will send binary data, which we would usually want to download with progress indication enabled.
I would try to add a rule that skips the Progress Pages and Anti-Virus for this URL, since both will break the stream is it is announced as binary data, not as multimedia content. The server is not behaving very nice here :-(
I think the most easy way to get the stream to work is to add a whitelist entry for the URL the stream is coming from. If SSL Scanner is disabled then the stream will just be tunneled through MWG, so it won´t be touched - therefore it works fine in that case.
appreciate your collaboration. I agree that server side header correction should be investigated first, besides this site seems to be quite unique with this kind of behaviour regarding streaming media.
I'll further study administrative articles in case we are able to receive a notice in advance, rather that from the end users, for the interruptions like this.
in this specific case I think it is pretty hard to notice such behaviour before someone actually tries to watch the stream. We probably do not want to trigger an alert whenever binary data is transferred, and this stream is announces as binary :-)
Generally for streaming detection we rely on the media type of the file, which works for the majority of streaming URLs. I would assume that this streaming site in particular is different. I will forward the link to our streaming expert, just to show him whats "in the wild", since we do not test MWG with every streaming site out there - there are just too many of them.
If you find more sites like this, please let me know, it would be interesting for us to learn about this.