Closed Bug 1139479 Opened 9 years ago Closed 9 years ago

SSL Error during file upload by POST in HTTPS

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
36 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: support, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150220131007

Steps to reproduce:

- Go to https://gesica.comalia.com/test.php
- Upload a random file larger than 8kB

-------
The URL point to a simple PHP script which displays file metadata: 
<!DOCTYPE html>
<html>
        <body>
                <?php if (!empty($_FILES)) { echo 'File sent:<pre>'; var_dump($_FILES); echo '</pre>'; } ?>
                <form method="post" enctype="multipart/form-data">
                        <input type="file" name="test">
                        <input type="submit">
                </form>
        <body>
</html>

-------
Tested on :
 - Chrome 38+ : working
 - Firefox 35.0 and before (Linux, Windows) : working
 - Firefox 36.0 stable (Linux, Windows) : buggy
 - Firefox 38.0a1 Dev Edition (Linux) : buggy
 - Firefox 38.0a2 Dev Edition (Linux) : buggy
with SHA1 certificate and SHA256 certificate.

Our servers are located behind a load-balancer : Cisco ACE30 with software version A5(2.2). The problem doesn't happen without it.


Actual results:

If the file is large enough (around 7.8kB), there is an SSL Error


Expected results:

The page should return a HTTP 200.
Confirmed with Firefox 39.0a1 (2015-03-04) on OS X 10.10.2. Going to try to hunt down a regression range.
Status: UNCONFIRMED → NEW
Component: Untriaged → HTML: Form Submission
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
I seem to be getting Connection Reset errors on even the earliest builds of Firefox, when the file is over 7.8 KB. Are you sure this is a regression? Or do you define "working" as showing "The connection was reset" instead of "Secure Connection Failed?"
Flags: needinfo?(support)
Hi Logan,

Thank you for your interest for this ticket.


Actually, we changed some settings on the load-balancer when trying to fix the problem. It seems we only managed to break compatibility with all Firefox versions. We'll try to reset this (if possible) tomorrow. Sorry about that.

I think the main change is our certificate which is now signed with SHA-256 instead of SHA-1.


So, by "working", I meant "I got an HTTP 200 code with expected debug info" (as in Chromium/e).
Flags: needinfo?(support)
The message change ("The connection was reset" to "Secure Connection Failed") was introduced by 1112399, but it didn't actually detect the intolerance because it is impossible to detect it reliably. So the message will be changed even if no SSL error is involved at all.
Blocks: 1112399
This morning we updated the load-balancer with its old configuration.

Now, with Firefox 35 and before I can upload any file but with Firefox 36 and later my upload fail if the file is larger than 8kB (as in my original description).
This is probably because Firefox 36 disable RC4 in the first handshake. Although the server supports 3DES, looks like the support is broken. But 1139778 might fix the issue.
See Also: → 1139778
You are right about RC4. If I disable it in Firefox 35.0, it falls back to 3DES and fails to establish secure connection. If we enable only RC4 and nothing else on our load-balancer, it works for all versions of Firefox.

"Although the server supports 3DES, looks like the support is broken."
You mean the support seems broken on firefox or on our load-balancer ?

We changed the configuration to disable RC4 and 3DES on the load-balancer. The upload is still broken.
Actually, I don't understand why the secure connection is correctly established with a small request but not with a larger one (and only in Firefox).
Flags: needinfo?(VYV03354)
The server uses IIS 6. I vaguely recall IIS 6 has some bugs in the 3DES implementation.
Other problems regarding IIS 6 + 3DES are bug 1139756 and bug 1116893.
I strongly recommend to replace it something newer. (see bug 1116893 comment #12 and #13 for details)
Flags: needinfo?(VYV03354)
Sorry but I don't understand. We use a Cisco ACE30 version A5(2.2) in front of Apache web servers. So, there is no IIS involved.

As far as I can see about 3DES, the algorithm is not used. When the upload fails, I can see TLS_RSA_WITH_AES_256_CBC_SHA, 256bits, TLS 1.0 in details shown by Firefox.
Sorry for the wrong speculation. But I could not upload >8KB file even with Firefox 35 after AES is enabled.
Can you enable TLS 1.1 or later?
See Also: 1139778 → 
$ NSS_SSL_CBC_RANDOM_IV=0 firefox.exe
Worked for me. This server is incompatible with 1/n-1 record splitting (the BEAST mitigation).
So enabling TLS 1.1 should fix the problem.
You are right, it works (I have just tested under Linux).

We will try to upgrade to TLS 1.1 or 1.2 but it needs a firmware upgrade. It will probably be simpler than explaining our users how to bypass it.

Thank you for your time on this topic.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.