1191513 - SSL transaction failures

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Rich]

Attachment: ff-ssl.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36

Steps to reproduce:

Access the following url directly in the Firefox (v39.0) address bar:
https://55b7cc368f17b.streamlock.net/clientaccesspolicy.xml
This request is handled by a Wowza Streaming Engine server running on an Amazon EC2 instance.


Actual results:

In the Developer console you can see the request going out but it sometimes appears to hang and/or time-out before completion.
On the Wowza server side you can see the initial SSL handshaking succeed, but then you see one of three behaviors:
1.	you never see the actual file request (clientaccesspolicy.xml) being received
2.	the file request is received after a "randomly" long wait
3.	the file request is received  immediately (after the handshaking completed)
The "long wait" scenario is rare, but it seems to vary between the other for periods of time.
Unsure whether the behavior it affected by network conditions and/or distance between client and server.  We have been unable to reproduce the problem when the Wowza server is running on the local network.  The fact that this server is running on an Amazon EC2 instance does not seem relevant since it's apparently also reproducible on host installs.
The issue is not reproducible with other tested browsers (IE11, Chrome, Safari).

In case it could be useful, I've attached a zip containing Wireshark captures of both good and bad transactions.
(I use display filter "ip.dst==54.176.114.39 || ip.src==54.176.114.39" to view the relevant entries)



Expected results:

The file should have been retrieved with little delay.

Comment 1

[Matthias Versen [:Matti]]

I loaded https://55b7cc368f17b.streamlock.net/clientaccesspolicy.xml with Firefox39  around 30x times (forced reload and normal reload) and it always loaded very fast.

Do I have to try it more often to see the issue ?
Does it work if you load the URL over http instead of https ? 

Do you use any antivirus software that does a MITM do intercept https connections ?

Comment 2

[Rich]

I do currently have Panda Free Antivirus installed, but I see the same issues with it disabled.

Other files to try accessing (I can intermittently reproduce the issue with any of these):
https://55b7cc368f17b.streamlock.net/crossdomain.xml
https://55b7cc368f17b.streamlock.net/vod/mp4:sample.mp4/manifest.f4m
https://55b7cc368f17b.streamlock.net/vod/mp4:sample.mp4/Manifest
https://55b7cc368f17b.streamlock.net/vod/mp4:sample.mp4/playlist.m3u8

Also I do have the Cached Web Content setting set to 0 MB.
Everything else is default settings.

Comment 3

[Rich]

The same files can be accessed unsecured through http://55b7cc368f17b.streamlock.net:1935/...

Comment 4

[Rich]

Sorry, the port specification is not required, so just the normal http://55b7cc368f17b.streamlock.net/...

I have never been able to reproduced the problem over unsecured/http after many many tries.
It usually does not take to very long for me over https.

(In reply to Rich from comment #3)
> The same files can be accessed unsecured through
> http://55b7cc368f17b.streamlock.net:1935/...

Comment 5

[Matthias Versen [:Matti]]

I tried the other links as well and could not reproduce the problem.
One last thing that we could try is that you create a new, additional Firefox profile for testing:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

how long is the random wait time that you mentioned in comment#0 2. ?
under 1s or more like 5s ?

Comment 6

[Rich]

The random waits (with an eventual success) seldom ever happen.  Usually it either works (response received in < 1s), or doesn't (times-out in 30-60s).
I tried both resetting my default Firefox profile and then also created a new profile, but see basically the same behavior.
I tried using Netlimiter with Up/Down rates cranked way down (5 KB/s) but it doesn't really seems to have any affect one way or another.

I guess I didn't notice before that the requests that time-out land on this error page:

---------
Secure Connection Failed
The connection to the server was reset while the page was loading.
    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.
---------

And it provides a link to: https://support.mozilla.org/en-US/kb/tls-error-reports

Wowza Streaming Engine is a Java app and I believe uses a relatively old version of Apache MINA, not sure if that's relevant.
If it's an SSL issue in the Wowza server, it just seems odd that we don't see similar issues with other browsers.

Comment 7

[Matthias Versen [:Matti]]

The main issue is that I can not reproduce the issue with Firefox39 or a Firefox42 nightly.
This usally means that is something on your system or network.
We had SSL errors in the past caused by security software but Panda Virus doesn't seem to "scan" ssl connections.

I do not know how to proceed in this case. Maybe another contributor shows up who can reproduce the issue....

Comment 8

[Nickolay_Ponomarev]

I think this report has a better chance of someone seeing it in Core:Networking...

What does Wireshark show? Were you unable to pinpoint this on browser not sending or sending an invalid request?

Were you able to reproduce from a different machine?

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging might or might not give additional information. Also perhaps attempting to run this through something like http://mitmproxy.org/ will shed some light on this.

Comment 9

[Rich]

So after much testing it appears that there was a bug on the Wowza Streaming Engine server side after all.  The server was not handling the encrypted request data correctly when it was received at the same time (tacked onto the end) of the handshaking transactions.
The Wireshark captures did show that the encrypted request was being sent properly by Firefox, so that was a clue that something was amiss on the server side.
Thanks for the assistance.
Feel free to close this ticket.

Comment 10

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Great - thanks for following-up.

(Closing as "INVALID", which is an unfortunate way of saying "not a bug in Firefox".)