Closed Bug 422180 Opened 16 years ago Closed 16 years ago

Adobe Flash IO Error 2038 when uploading in SSL with ANY certificate abnormality

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jeroldan, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre

We use a single SSL certificate that does not necessarily match the beta test domain we are currently using.  This is not the case in our production environment.  Even though we override and accept the abnormal certificate, Firefox will not accept the upload and causes Adobe Flash to report an IO error 2038.  Adobe does not recognize this to be their bug.  This issue is not reproducible in Internet Explorer.  This issue is reproducible in Firefox on Windows, Macintosh and Linux. 

Reproducible: Always

Steps to Reproduce:
1. Navigate to the URL listed in this bug
2. Follow the instructions on the page
3. Upload a file in both environments listed

No registration is required for this test.
Actual Results:  
Adobe Flash Error 2038 is reported by the flash movie.  I have included an JavaScript alert to make reading the error easier.  Follow the steps to reproduce at the URL listed and you can experience the issue first hand.

Expected Results:  
The software should have uploaded the file successfully and closed the modal upload showing the file uploaded in the data grid on the page.  You can experiment with Internet Explorer to see different results.
PSM or Plugins
Assignee: nobody → kengert
Component: General → Security: PSM
Product: Firefox → Core
QA Contact: general → psm
(In reply to comment #1)
> PSM or Plugins

I assume PSM
I am trying to reproduce this with the given URL. There is really an IO error 2038 when using SSL upload. But I am no sure if the cause is inside of firefox, because there are several errors while loading the page. It loads extremely long time and sometimes it hangs. SSL pipelining is off.

I cannot verify this works in IE because there is one missing item to load on the page and, when I stop the load, press File Upload button, enter some title for a file and finally click Brows button, status bar shows 'Error on page' and nothing else happens. I tested in IE6 and 7.

I suspect there is some problem in integration. Please, if you can fix the test page, I will do the tests again and look for solution.

Errors on the page:
Error: shortcutKey is not defined
Source File: https://beta.testlab.a2g.info/+sandbox/upload_test.aspx
Line: 293

when click on the File Upload button first time:
Error: [Exception... "'Sys.ParameterCountException: Sys.ParameterCountException: Parameter count mismatch.' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "JS frame :: <unknown filename> :: [5 frames skipped, stack too deep...] :: line 0"  data: no]
I cannot upload a file in IE (Error on page) and I have the same result as in Firefox when using Opera and Safari. This is not Firefox bug.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
The error you reported is unrelated to this bug, however, I fixed it by including the javascript file to the page that was causing the error.  The shortcutKey only allows the user to dismiss the modal upload popup by pressing the escape key.  You can now press the escape key to dismiss the upload modal when it pops up. (except in Safari)

I tested this issue on Opera v9.27 and Safari 3.11 and I get exactly the same results as Firefox.

If you try to upload in SSL, the browser stops the upload; without SSL and the file uploads normally.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Additionally, I tested this AGAIN in IE 7.0.6 on Vista Home and IE 6.0.29 on XP Home and they worked perfectly.

I find it very interesting that you reported that you could not get the upload to work on IE.  What version were you using and on what platform?

I need to know this.
I don't see any difference in behavior after your fix.

I test on IE 6.0.2900.2180.xpsp_sp2_gdr and IE 7.0.5730.11, both in Win XP, latest update. In both of them when I open the https version of the page IE waits indefinitely for 1 remaining item (couldn't find out which, FF doesn't have such problem). It is possible to open the File Upload dialog but clicking the Browse button produces "Error on page" message in the status bar. I always enter a Title for the file before it.

Error description is:
Line: 290
Char: 7
Error: Object doesn't support this property or method
Code: 0
URL: https://beta.testlab.a2g.info/+sandbox/upload_test.aspx

When I test with FF trunk build I get the Error 2038. Are you testing on the same page as reported in URL field of this bug? I don't understand why we get different results.

Please try to fix yet this one error and let me know when it is done. I will test again.
Assignee: kengert → honzab
Thank you for responding quickly and for working on this issue with me.

I found the issue on line 290.  It's JavaScript that is used by Adobe.  It may be related to the version of Flash.  I am using Flash v. 9.0.60.235.  The scripting is supposed to detect if a client version is too old for the upload player.

What version of Flash player do you have?

Thanks.
I installed the latest version 9.0.124.0. It still doesn't work in IE 6 but now it completely works in IE 7. No change in FF 3/Minefield. I suspect that IE is just more benevolent to errors mainly the security ones and there is actually still problem in the upload code or more likely in integration with Adobe software.
You're probably correct regarding the integration with Adobe.  Adobe says that if the SSL certificate exactly matches the domain and certificate is not expired or any other issues with the certificate, Flash works fine uploading with FF 3.  I found that to be true also.  However, if the certificate expires or the certificate is for www.domain.com and not domain.com, the URL must match www.domain.com or FF 3 will not upload the file with the same issue.

Do you see where this is a big issue?
I'm sorry I didn't realize it sooner but this will never work in any browser different from IE. The problem is really in the Flex because it's using its own secure connection for file upload not going through Firefox/Necko API where the cert exception is stored. It is probably using IE API (but I'm not sure what is being used on Mac) or some Win API that IE uses and stores the exception for it there within a single process/session.

This is IMHO definitely not bug in Firefox.

If everyone agrees I will close this bug as invalid.
OK.  Well, we have a definite issue here then.  You apparently did not read my previous comment.  However, you stated in the last comment, "this will never work in any browser different from IE."  This statement is absolutely incorrect and I can prove it.

The Firefox/Necko API is not processing SSL certificates that do not match the URL exactly, the same way.  If you wish that I prove this statement, I will.

It appears to me that NO research has been done to prove that this is not a Firefox bug by your statement, "It is probably using IE API," and the statement, "This is IMHO definitely not but in Firefox."  I can prove my claim.

You need to prove your claim and then demonstrate, in an example, that this is not a Firefox bug.

Please let me know what you find in your research.
Point one: I was monitoring the traffic using Wireshark. It is clearly visible that there is a new TCP connection to the server (71.33.241.2:443) established at the moment when I select the file to upload. This connection is reset by the client because the negotiation fails (bad cert CN).

Point two: I put a breakpoint on two places (only places) where a new connection can be established in Firefox: http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsSocketTransportService2.cpp#460 and http://lxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslsock.c#1176. The breakpoint stops when open connection to load the page. The breakpoint IS NOT hit when opening the connection to upload the file.

Point three: The list of supported cipher suits that the upload connection offers to the server is very different from the list that Firefox offers (and what more, while indicating TLS1 it offers SSL2 cipher suits - what AFAIK, maybe I am wrong, violates the TLS1 rules). Also if the connection would be open by Firefox (NSS) there would be no negotiation because the stored SSL session would be used.

Conclusion: Flex uses API different from Firefox (Safari, Opera) to open the upload connection. The API is probably IE API or WinNT API that also uses IE.

However, I still don't understand why this is such a problem. The primary issue here is that the server is using invalid certificate what is a security problem on its side.
And please, feel free to prove any of your claims. Maybe I look something over.
It's very simple.  If the web user accepts a certificate that is for www.domain.com and the URL is domain.com, the session is still encrypted successfully.  In Firefox, Safari, and Opera the user can accept the certificate and the session is still encrypted.  However, Firefox returns information to Flash indicating that the encrypted session has failed.  The failure only takes place after the Firefox/Gecko API returns information indicating that the session is no longer secure.  IE returns information indicating that the session is still secure so the upload continues.

Are you saying that Mozilla refuses to address this with Adobe?
Just to check your claim I changed the code that examines/verifies the certificate. I altered it to accept the cert (any cert) without any processing the certificate and accepting it in whatever state it is. I deleted exception for your server certificate. There were no cert error while opening the page. FF UI shows the page as fully encrypted and the certificate as correct, including the issuer (which is trusted, btw). As I expected nothing has changed. There were no further verification of the connection status nor properties (I put breakpoints to the right places to check). All what I represented in comment 13 and this comment prove Flex is using new connection to upload the file opened with API different from FF. It is not reusing the existing FF connection. Case closed.

I tried ones again with IE 7 (where upload previously worked) to check if Flex is using again new connection or reuses the current one. I discovered it is reusing one of the existing alive connections.

I observe (previously didn't see that) when I click the upload button (either on encrypted or unencrypted page) POST is sent to the server but the server stops responding (packets are not ACKed on the TCP level, I see retransmissions but no ACK from the server) - no dialog appears. When I click the File Upload button again (before the connection dies) next alive connection is choose to send the POST with the same result. When all connection are "used" this way then in reaction to another File Upload button click a new connection is open - the Flash dialog appears. This both happens in both FF and IE7, sometimes (50% approx). When I manage to open the flash dialog "on the first click", any new connection is not open, I can see a new connection is still used to upload the file in FF.

This bug is clearly not a security bug but integration one or third party one. I will change the component appropriately.

Jerold, please contact Adobe to have a feedback from them on this issue with reference to this bug. I am afraid I cannot step much forward w/o their help.
Assignee: honzab → nobody
Severity: major → normal
Component: Security: PSM → Networking: HTTP
QA Contact: psm → networking.http
Thank you.  I have contacted them and have not heard back yet.  I will update this bug issue as I find out more.

Thanks for your effort so far.
There is no feed back for a long time and this bug has not been confirmed.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → INVALID
hi, i understand the problem is at the flash side,
just wanted to let you know, that chrome has somehow found a way around this issue

on my osx safari 6.0.5 && firefox 23.0.1 both end up with a 2038 flash error
but chrome 29 somehow manages to workaround it and the upload goes nicely through
You need to log in before you can comment on or make changes to this bug.