490442 - xulrunner-based browsers have problems sending large POST-Data to https-Websites running apache2/mod_gnutls

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P5)

Description

[Joerg.Friedrich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.9) Gecko/2009042221 Iceweasel/3.0.9 (Debian-3.0.9-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.9) Gecko/2009042221 Iceweasel/3.0.9 (Debian-3.0.9-1)

Hi!
I encountered the following problem:
I run a apache webserver with some https-sites. I use mod_gnutls because
I need ssl with named virtual hosts. mod_gnutls supports SNI.

When setting up the Horde-Framework on my server, Firefox suddenly
asked to save the PHP-Skritp instead of showing a modified page.
this bug is also mentioned at http://issues.outoforder.cc/view.php?id=95

I can confirm that with mod_ssl this bug does not occur.
But accessing the same page with firefox on Windows is no problem.

I downloaded Firefox for Linux from Mozilla.com and it also worked.

Works: - Apache2+mod_ssl: every browser/os I testet
       - Apache2+mod_gnutls: Windows: every Browser I tested
                             Linux (Debian(squezze/sid):
			        - every not xulrunner-based Browser
Does not work:
        - Apache2+mod_gnutls: Linux (Debian squezze/sid):
	                        - every xulrunner-based Browser I tested
				  (iceweasel, epiphany-gecko, galeon)
                                - fresh firefox downloaded from mozilla.com

I degraded my site's security level to sniff the ssl traffic with wireshark and I can see, that firefox does not send any POST-Data back to the server when mod_gnutls is activated.

Reproducible: Always

Steps to Reproduce:
1. use firefox on linux
2. access my testpage at https://startdust.frews.de/test.php
3. send a text message larger than 3kb



I can provide network dumps when accessing mod_gnutls and mod_ssl and ssl.key to decode them

Comment 1

[Steve England [:stevee]]

Your testpage doesn't work for me.

Comment 2

[Joerg.Friedrich]

(In reply to comment #1)
> Your testpage doesn't work for me.

sorry, typo:
https://stardust.frews.de/test.php

Comment 3

[zyanklee]

I can confirm this bug.
in addition there is a bug reported in mog_gnutls bugtracker:

http://issues.outoforder.cc/view.php?id=95

Comment 4

[Bart Cassady]

I can also confirm this bug, but it exists for me when using apache/mod_ssl, using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729).

It does, however, work properly with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9, which is the only other environment I have convenient access to.

I also notice that the test case works/breaks not just depending on the size, but on the actual value and the order the submits are done.

Try this:

copy this line 10 times, then copy all 10 lines (including final newline):
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Paste three of these (ie. ~3000 bytes) into the test case and submit it - it should work.

Paste a total of four of these (ie. ~4000 bytes) into the test case and submit - it should not work.

Paste a total of five of these (ie. ~5000 bytes) into the test case and submit - it should not work if you did it immediately after the 4000 byte test, but will work immediately after the 3000 byte test.

Hope this helps!

Comment 5

[Bart Cassady]

I have tested further and found that the test case works on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20

and fails on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

Comment 6

[Jean-Marc Desperrier]

I'll confirm this bug, given the number of reports, also on the gnutls tracker.
http://issues.outoforder.cc/view.php?id=95

Some notes though :
- For now, nothing proves that it's NSS that's broken and not GnuTLS. But even if it's 100% a GnuTLS problem, it better be analyzed and published as a known issue.
- Joerg, your network dump will probably be useful for the NSS dev, I hope you still have them. Your site is not accessible right now, the best would be to have instruction about how to set up a site that reproduces this, and put the source of the test page as an attachment. 
- The issue Bart Cassady reproduced is a different bug, and I'll open one for it. All other reporters report a problem that *disappears* when GnuTLS is replaced by Openssl.

Comment 7

[Jean-Marc Desperrier]

Bart's issue is now in bug 501653

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

I suggest you turn this into a PSM bug.  This is very reminiscent of 
Bug 356470: HTTPS File Upload results in partial and/or corrupted files on
server

which was a server bug, and 

Bug 378629: SSL file uploads settle into oscillating pattern with very small
packets

which was a bug in the browser's internal flow control (PSM and above, not
NSS).

I suggest you first look to see if this is merely a duplicate of bug 356470.
That was a bug in the server's processing of the received https response, 
and really had nothing to do with SSL.  It was a data pattern sensitivity
bug in the server.  See bug 356470 comment 82 for info about the actual 
resolution in the apache server software.

Perhaps bug 378629 has regressed.  See also  
  Bug 369414 -  Uploads to mod_perl 1.3 truncated 
which proved to be a server error.

Comment 9

[Jean-Marc Desperrier]

Thanks for the precisions, Nelson.

It does have a few similarities with bug 356470 for example the influence of carriage returns, but I doubt that people still use Apache 1.3. 
In fact, Yanklee has reproduced with apache 2.2.11.

There an interesting log excerpt in the debian bug about the problem :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513249

[Tue Jan 27 16:32:07 2009] [info] GnuTLS: Error reading data. (-9) 'A TLS packet with unexpected length was received.'
[Tue Jan 27 16:32:07 2009] [info] (20014)Internal error: GnuTLS: Error reading data. (-10) 'The specified session has been invalidated for some reason.'

The best would be that someone put on-line again a mod_gnutls test platform. Only Bart saw a problem with mod_ssl, but several different persons have independently reproduced a problem at around 3000 characters with mod_gnutls.

I hope you can understand I'm not very enthusiast at the idea of affecting this to the PSM black hole, except if it's when classifying it as invalid/needs to be solved by gnutls.
If needed, I'd prefer to affect to network/http with an SSL flag.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #9)
> [info] GnuTLS: Error reading data. (-9) 
>   'A TLS packet with unexpected length was received.'
> [info] (20014) Internal error: GnuTLS: Error reading data. (-10) 
>   'The specified session has been invalidated for some reason.'

I wonder what "unexpected length" means.  If it means a length not allowed 
by the specification for the relevant version of SSL/TLS (whatever that was),
then I'd very much like to see evidence of that error.  In any case, I would
expect this would be fatal to the connection and would cause the connection 
to terminate at that point (after sending a suitable alert message back).
I would NOT expect it to result in corruption of data nor loss of data from
the middle of a file transfer.  If it has either of those effects, that is 
a server bug.

Now that Honza is back working full time, I expect PSM to be less of a black 
hole.  :)