Closed
Bug 392440
Opened 17 years ago
Closed 8 years ago
Corrupted/lost POST data when sending >4072 byte via SSL (https)
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: swift, Unassigned)
References
()
Details
Attachments
(6 files, 6 obsolete files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070731 Ubuntu/dapper-security Firefox/1.5.0.12 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070731 Ubuntu/dapper-security Firefox/1.5.0.12 Hi there! Please visit the mentioned URL. There is a bloody simple script with 2 forms. When you press one of the submit-buttons, the script will output the content of POST. Ok, when sending form 1 (with 15 fields), all POST-data is received correctly by the PHP-Skript (Array has 16 fields: 15 + 1 for the submit button). But when I send form 2 (with 150 fields), the POST-data gets corrupted in a very strange way (array has only 86 fields)! And only when I use https! http seem to work fine. I tested it with FF 1.5.0.12, 2.0.0.6 and some other versions, both on Windows and Linux. My first thought was that the bug is caused by Apache2 or PHP4, but the strange thing is, when I use IE5, IE6, Opera or Konqueror, all of these browsers work fine with https! So I think this is a firefox-related bug - but I cannot believe that noone has experienced this bug before!? On the server-side there is an absolute standard installation of Debian 3.1 - no self compiled modules/programs, no special apache-config. And a Standard-SSL-cert from Thawte with 1024 bits. What the hell is going on here? Another interesting detail: When I append some data to the URL, like https://www.f-shop.de/Test.php?iojhoighdofghdfoiughiuh3wndsfvxvccxxcv and then sending the form, the data is corrupted in a slightly different way. I think that this has to do with a longer referer, so there might be a shift somewhere in the https-request-data. Thanks in advance ...TW Reproducible: Always Steps to Reproduce: 1. 2. 3.
Comment 1•17 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 http://livehttpheaders.mozdev.org/ Using extension Livehttpheaders I'm seeing all is transferred correctly, Content-Length: 6095 field 1 ... field 150, submit, sent Result seen on the website: array(99) { ["field_number_104"] string(24) "This is field number 104" ["field_number_105"] string(24) "This is field number 105" ... ["field_number_149"] string(24) "This is field number 149" ["field_number_150"] string(24) "This is field number 150" ["Submit"] string(4) "Send" ["field_number_52"] string(23) "This is field number 52" ["field_number_53"] string(23) "This is field number 53" ... ["field_number_100"] string(24) "This is field number 100" ["field_number_101"] string(24) "This is field number 101" ["field_number_102"] string(24) "This is field number 102" } Looks like you've got some sort of overflow. The line you are receiving is 6095 chars long.
Reporter | ||
Comment 2•17 years ago
|
||
I've modified the script, so it displays the content-length and the raw post data. The content-length is always correct, but the raw post data also shows corrupt data. If someone has an idea, what I can try to prevent this bug, please tell me. Maybe it has to do with Transfer-Encoding: chunked ? But why the hell it works with all other browsers? This is driving me mad.
Comment 3•17 years ago
|
||
I've modified reporter's testcase to have fields of same size, sent via http they are sent back correctly, sent via https if big enough Firefox/Seamonkey has a buffer overflow, LiveHTTPHeaders is showing the form data correctly, the website sees an input string from an overflowed buffer. testing the attachments: Load attachment, memorize title (#fields) and click button 'Send' The form is sent to reporter's server, the server sends back an Array showing the processed data, and a line showing the raw data. form 150 fields http -- ok
Comment 4•17 years ago
|
||
Same file, only difference is the protocol for action, not the url. The action-line sent seems to be ok, looking what has been seen in the extension LiveHTTPHeaders. Comparing to Opera, there must be a buffer-overflow in PSM or NSS,
Comment 5•17 years ago
|
||
string length of 96 fields is just a few bytes below the magical number of 4096, 2^12
Comment 6•17 years ago
|
||
At first glance array(97) seems to be o.k., but first field is overwritten by submit.
Comment 7•17 years ago
|
||
Array should be array(98), but still is array(97) 1st line overwritten by Submit & Value, last line mutilated: array(97) { ["Submit"] string(4) "Send" ["field_number_002"] string(24) "This is field number 002" ... ... ["field_number_095"] string(24) "This is field number 095" ["field_number_096"] string(24) "This is field number 096" ["field_number_097"] string(42) "This is field number 09is field number 098" }
Comment 8•17 years ago
|
||
SSL-POST-Test 100 fields -> Buffer overflow can't be overseen. array(97) { ["field_number_099"] string(24) "This is field number 099" ["field_number_100"] string(24) "This is field number 100" ["Submit"] string(4) "Send" ["field_number_004"] string(24) "This is field number 004" ["field_number_005"] string(24) "This is field number 005" ... ... ["field_number_096"] string(24) "This is field number 096" ["field_number_097"] string(42) "This is field number 09is field number 098" }
Updated•17 years ago
|
Attachment #277145 -
Attachment mime type: image/svg+xml → text/html
Comment 9•17 years ago
|
||
changing to Core, Security:PSM
Assignee: nobody → kengert
Component: General → Security: PSM
Product: Firefox → Core
QA Contact: general → psm
Comment 10•17 years ago
|
||
Overflow happens when the string sent back is > 4072 byte The reporter added output of the raw input he receives, the string sent looks ok in extension LiveHTTPHeaders.
Attachment #277139 -
Attachment is obsolete: true
Attachment #277145 -
Attachment is obsolete: true
Attachment #277147 -
Attachment is obsolete: true
Attachment #277149 -
Attachment is obsolete: true
Attachment #277155 -
Attachment is obsolete: true
Attachment #277157 -
Attachment is obsolete: true
Comment 11•17 years ago
|
||
Comment 12•17 years ago
|
||
Seems there must be errors on both sides, as other browsers don't show this bug, but the buffer overflows on reporters side. up to 4072 bytes the server's input buffer is filled correctly, as you can see looking at the array and the raw input below. Reporter, what's the configuration on your side?
Summary: Corrupted/lost POST data when sending a large amount of data via SSL (https) → Corrupted/lost POST data when sending >4072 byte via SSL (https)
Reporter | ||
Comment 13•17 years ago
|
||
Server configuration: - Standard Debian 3.1 (all packages latest version, via apt-get upgrade) - Apache 2.0.54 (std Debian) - PHP 4.3.10-22 (as cgi/fcgi, std Debian) - started via mod_fcgid 1.05-1/suexec (std Debian) - Plesk 8.0.1 (I checked the config-files written by Plesk: there are no special directives which could obviously cause this error) - not active: mod_gzip, mod_deflate - active: mod_rewrite (currently not used), mod_ssl - standard 1024 bit SSL-cert - no proxy, no special firewall-rules If there is anything else what I can try or check on my side, please tell me.
Comment 14•17 years ago
|
||
First, I'd like to mention a weird behavior of your server. On the initial attempt during a session, probably related to the fact that the client does not yet have a cookie, there is some sort of redirect happening. Although the post is going to your server using https, I end up getting the page displayed using plain http. So, in order to get useful testing done, it's necessary to ignore the results of the first test and try again...
Comment 15•17 years ago
|
||
I think the latest test case is attachment 277314 [details], so I'm updating the URL field of this test to https://bugzilla.mozilla.org/attachment.cgi?id=277314 (old was https://www.f-shop.de/Test.php )
Reporter | ||
Comment 16•17 years ago
|
||
I've set up another script which won't redirect: https://www.f-shop.de/Test2.php It's plain PHP without any preload code. The other script had preload-code of the shop-engine, so you might experience an initial redirect. Test2.php seems to show the same output as Test.php.
Reporter | ||
Comment 17•17 years ago
|
||
Changed Test2.php: All keys now have the same size (counting from 001 to 150, instead 1 to 150).
Comment 18•17 years ago
|
||
These are the results of my testing from attachment 277314 [details], second execution in the session.
I enabled tracing of the raw buffers that sent from the Mozilla networking code to the PSM layer, and also enabled tracing of the buffers that arrive in NSS in function ssl3_SendRecord.
At this point, the order of processing seems correct.
The send data is sent in multiple pieces. First the http protocol header data gets sent, I'll not paste that here.
The actual content is sent in two chunks.
First chunk, 3509 bytes:
Nbr001=ABCD&Nbr002=This+is+field+number+002 ....
.... Nbr110=This+is+field+number+110&Nbr111=Th
Second chunk, 566 bytes:
is+is+field+number+111&Nbr112=This+is+field+number+112 ....
.... field+number+127&Submit=Send+is+field+number+XYZ
I traced this further, going through Mozilla's SSL layer, to the input of the NSS SSL layer, and tracing the amounts of bytes that are sent to the network functions.
I can see the first chunk is passed to the network before the second chunk.
We send "chunk 1, then chunk 2", but the data that you process seems to be a concatenation in the reverse order. Your string starts with chunk 2, then chunk 1.
At this time I have difficulties to believe the bug is in Firefox. All tracing so far tells me we are sending the data in the correct order.
Comment 19•17 years ago
|
||
This is the 4075 bytes testcase updated to post to the non-redirecting Test2
Comment 20•17 years ago
|
||
In another test your script reported the following input string: field+number+114&Nbr115=This+is+field+number+115&Nbr116=This+is+field+number+116&Nbr117=This+is+field+number+117&Nbr118=This+is+field+number+118&Nbr119=This+is+field+number+119&Nbr120=This+is+field+number+120&Nbr121=This+is+field+number+121&Nbr122=This+is+field+number+122&Nbr123=This+is+field+number+123&Nbr124=This+is+field+number+124&Nbr125=This+is+field+number+125&Nbr126=This+is+field+number+126&Nbr127=This+is+field+number+127&Submit=Send+is+field+number+XYZ16=This+is+field+number+016&Nbr017=This+is+field+number+017&Nbr018=This+is+field+number+018&Nbr019=This+is+field+number+019&Nbr020=This+is+field+number+020&Nbr021=This+is+field+number+021&Nbr022=This+is+field+number+022&Nbr023=This+is+field+number+023&Nbr024=This+is+field+number+024&Nbr025=This+is+field+number+025&Nbr026=This+is+field+number+026&Nbr027=This+is+field+number+027&Nbr028=This+is+field+number+028&Nbr029=This+is+field+number+029&Nbr030=This+is+field+number+030&Nbr031=This+is+field+number+031&Nbr032=This+is+field+number+032&Nbr033=This+is+field+number+033&Nbr034=This+is+field+number+034&Nbr035=This+is+field+number+035&Nbr036=This+is+field+number+036&Nbr037=This+is+field+number+037&Nbr038=This+is+field+number+038&Nbr039=This+is+field+number+039&Nbr040=This+is+field+number+040&Nbr041=This+is+field+number+041&Nbr042=This+is+field+number+042&Nbr043=This+is+field+number+043&Nbr044=This+is+field+number+044&Nbr045=This+is+field+number+045&Nbr046=This+is+field+number+046&Nbr047=This+is+field+number+047&Nbr048=This+is+field+number+048&Nbr049=This+is+field+number+049&Nbr050=This+is+field+number+050&Nbr051=This+is+field+number+051&Nbr052=This+is+field+number+052&Nbr053=This+is+field+number+053&Nbr054=This+is+field+number+054&Nbr055=This+is+field+number+055&Nbr056=This+is+field+number+056&Nbr057=This+is+field+number+057&Nbr058=This+is+field+number+058&Nbr059=This+is+field+number+059&Nbr060=This+is+field+number+060&Nbr061=This+is+field+number+061&Nbr062=This+is+field+number+062&Nbr063=This+is+field+number+063&Nbr064=This+is+field+number+064&Nbr065=This+is+field+number+065&Nbr066=This+is+field+number+066&Nbr067=This+is+field+number+067&Nbr068=This+is+field+number+068&Nbr069=This+is+field+number+069&Nbr070=This+is+field+number+070&Nbr071=This+is+field+number+071&Nbr072=This+is+field+number+072&Nbr073=This+is+field+number+073&Nbr074=This+is+field+number+074&Nbr075=This+is+field+number+075&Nbr076=This+is+field+number+076&Nbr077=This+is+field+number+077&Nbr078=This+is+field+number+078&Nbr079=This+is+field+number+079&Nbr080=This+is+field+number+080&Nbr081=This+is+field+number+081&Nbr082=This+is+field+number+082&Nbr083=This+is+field+number+083&Nbr084=This+is+field+number+084&Nbr085=This+is+field+number+085&Nbr086=This+is+field+number+086&Nbr087=This+is+field+number+087&Nbr088=This+is+field+number+088&Nbr089=This+is+field+number+089&Nbr090=This+is+field+number+090&Nbr091=This+is+field+number+091&Nbr092=This+is+field+number+092&Nbr093=This+is+field+number+093&Nbr094=This+is+field+number+094&Nbr095=This+is+field+number+095&Nbr096=This+is+field+number+096&Nbr097=This+is+field+number+097&Nbr098=This+is+field+number+098&Nbr099=This+is+field+number+099&Nbr100=This+is+field+number+100&Nbr101=This+is+field+number+101&Nbr102=This+is+field+number+102&Nbr103=This+is+field+number+103&Nbr104=This+is+field+number+104&Nbr105=This+is+field+number+105&Nbr106=This+is+field+number+106&Nbr107=This+is+field+number+107&Nbr108=This+is+field+number+108&Nbr109=This+is+field+number+109&Nbr110=This+is+field+number+110&Nbr111=This+is+field+number+111&Nbr112=This+is+field+number+112&Nbr113=This+is+field+number+113&Nbr114=This+is+field+number+114&Nbr115=This+is+field+number+115&Nbr116=This+is+field+number+116&Nbr117=This+is+field+number+117&Nbr118=This+is+field+number+118&Nbr119=This+is+field+number+119&Nbr120=This+is+field+number+120&Nbr121=This+is+field+number+121&Nbr122=This+is+field+number+122&Nbr123=This+is+field+number+123&Nbr124=This+is+field+number+124&Nbr125=This+is+field+number+125&Nbr126=This+is+field+number+126&Nbr127=This+is+field+number+127&Submit=Send+is+field+number+XYZ The plaintext application data of http protocol header and post content is sent in chunks of the following sizes: 412 (post) 49 (content-type) 24 (content-length) 3611 (chunk 1 starting with: Nbr001=ABCD) 464 (chunk 2 starting with: field+number+114 the SSL protocol code turns this into packets with the following sizes: 453 85 3637 501 I used a modified testcase. As the post target, I used an external ssltap application process, that acts as a transparent proxy, which forwards the data to your server, and prints debugging output. Using that tool, I can see that packets of the following sizes (after the ssl protocol handshake) are sent by firefox to the network: 448 80 48 3632 496 The minor difference in packet sizes is probably caused by some optimization and minimal buffering. I don't see any evidence for re-ordering of the last 2 chunks. I think either your script or your SSL server or your web server is reordering the incoming packets.
Reporter | ||
Comment 21•17 years ago
|
||
The script reads directly the input-stream of PHP, so it is impossible that the script is reordering the incoming packets (I can post the short script, if you wish). Ok, maybe the bug is in Apache. But then the main question remains: Why all the browsers work and only FF and Seamonkey don't work? What makes FF different than the other browsers? If we can find an answer to this question, this may be the solution for the bug.
Comment 22•17 years ago
|
||
SSL offers to use "null ciphers" that are usually disabled. If you find a way to enable the null cipher on your SSL server for testing purposes, we can use a packet sniffer like tcpdump to further debug the order of data sent and received. In Firefox you can enable the null cipher by using "about:config", type "null" and you'll see two prefs. In addition all other cipher prefs with "ssl" in their name should be disabled, so we force the use of the null ciphers.
Reporter | ||
Comment 23•17 years ago
|
||
Ok, I think NULL cipher is now allowed in my Apache: SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL:+NULL Please test it.
Comment 24•17 years ago
|
||
It doesn't work for me, I don't know why. Not sure if I'm doing something wrong. But from the trace below, it looks like the client is attempting a handshake, only offering the NULL ciphers, and your servers rejects that with an alert. Connection #8 [Mon Aug 20 15:27:07 2007] Connected to www.f-shop.de:443 --> [ alloclen = 33 bytes (33 bytes of 33) [Mon Aug 20 15:27:07 2007] [ssl2] ClientHelloV2 { version = {0x03, 0x00} cipher-specs-length = 6 (0x06) sid-length = 0 (0x00) challenge-length = 16 (0x10) cipher-suites = { (0x000002) SSL3/RSA/NULL/SHA (0x000001) SSL3/RSA/NULL/MD5 } session-id = { } challenge = { 0x26d0 0xa9f6 0x049c 0x1fb5 0xe024 0xf640 0x558f 0x4d01 } } ] <-- [ (7 bytes of 2) SSLRecord { [Mon Aug 20 15:27:07 2007] type = 21 (alert) version = { 3,0 } length = 2 (0x2) fatal: handshake_failure } ]
Comment 25•17 years ago
|
||
changing URL: to attachment 277376 [details] Kai, besides tracing, do you see the bug just running the testcases, on branch or on trunk? I stopped testing trunk nightlies when win98 was abolished. Bug was created between Mozilla 1.0.1rc2 and 1.4rc3 and considerably changed between 1.4rc3 and today. Should I do some more regression testing? working: Opera/9.23 (Windows 98; U; en) Build 8805 http://archive.mozilla.org/pub/mozilla/releases/mozilla1.0.1rc2/mozilla-win32-1.0.1rc2-talkback.zip Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 buggy: http://archive.mozilla.org/pub/mozilla/releases/mozilla1.4rc3/mozilla-win32-1.4rc3-talkback.zip Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 array(111) { [12]=> string(24) "This is field number 112" ["Nbr113"]=> string(24) "This is field number 113" ["Nbr114"]=> ... ["Nbr127"]=> string(24) "This is field number 127" ["Submit"]=> string(24) "Send is field number XYZ" ["Nbr019"]=> string(24) "This is field number 019" ["Nbr020"]=> ... string(24) "This is field number 111" ["Nbr112"]=> string(24) "This is field number 112" } Raw POST data (via file_get_contents('php://input')): 12=This+is+field+number+112&Nbr113= .... ... ber+127&Submit=Send+is+field+number+XYZ So the bug here is very different from today. I#m only showing the start and the end of Raw POST data, but start, middle and end of the array. The array is running from a broken start 112 to 127, XYZ, 19 to 112 current branch browsers are showing only 3 byte of Overflow using thos testcase Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Content-Length: 4075 Content of $_POST: array(128) { ["XYZ001"]=> string(4) "ABCD" ["Nbr002"]=> string(24) "This is field number 002" ... string(24) "This is field number 127" ["Submit"]=> string(24) "Send is field number XYZ" } Raw POST data (via file_get_contents('php://input')): XYZ001=ABCD&Nbr002=This+is+field+number+002&Nbr003= ... ... number+126&Nbr127=This+is+field+number+127&Submit=Send+is+field+number+XYZ
Comment 26•17 years ago
|
||
This seems a lot like bug 356470 (which was finally proven to be a server problem) and the workaround for that server problem, which was bug 378629 (which has been committed on the trunk).
Comment 27•17 years ago
|
||
Is the form with all the fields a necessary part of this bug? Can the problem be seen with file uploads? If it can be seen with file uploads, then it would be much easier to test for data pattern sensitivity. That's how we finally proved the issue in bug 356470. We found the data pattern that triggered the bug, and showed that that pattern, by itself, was enough to make the server unhappy.
Comment 28•17 years ago
|
||
(In reply to comment #27) > Is the form with all the fields a necessary part of this bug? > Can the problem be seen with file uploads? > > If it can be seen with file uploads, then it would be much easier to test > for data pattern sensitivity. That's how we finally proved the issue in > bug 356470. We found the data pattern that triggered the bug, and showed > that that pattern, by itself, was enough to make the server unhappy. I don't think it is pattern sensitive, I made a lot more testcases than uploaded, using wider or smaller fields, then making the submit field same width, going down from length 4096 until I found 4072 by some multiple fields at startof the array by small but different numbers of chars, seeing that adding one or three chars overflows the last one or three chars to the start. Then made the two last testcases, all but the first record have same length. I did check a lot of lenghts down from 4097 to 4070 chars in different ways, but I didnt test if there are bugs below 4072, or some good numbers above 4097, besides the very few testcases showing the bug.
Reporter | ||
Comment 29•17 years ago
|
||
I also don't think it is pattern sensitive, because I had the problems with all forms that send more than a few KB of data via https. I can fill a large textarea with "X"-chars, and the bug also shows up (again, only via FireFox).
Comment 30•17 years ago
|
||
regression windows using testcase attachment 277376 [details] 1.01 ok, 1.4 rc3 ... 2006062603 buggy, 2006062803 ... 3 byte overflow Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 ok Nbr001=ABCD&Nbr002=This+is+field+number+002&Nbr003=This+is+field+number+003 ================================================================================= Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 1.4rc3 12=This+is+field+number+112&Nbr113=This+is+field+number+113 .... amount of overflow changing ... Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060626 BonEcho/2.0a3 12=This+is+field+number+112&Nbr113=This+is+field+number+113 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-06-26+16%3A01&maxdate=2006-06-26+16%3A01&cvsroot=%2Fcvsroot http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-06-26+16%3A01&maxdate=2006-06-26+16%3A01&cvsroot=%2Fcvsroot https://bugzilla.mozilla.org/show_bug.cgi?id=235773 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060628 BonEcho/2.0a3 XYZ001=ABCD&Nbr002=This+is+field+number+002& ... amount of overflow constant 3 byte (for testcase using 4072+3 byte)
Comment 31•17 years ago
|
||
Guys, I have done some testing at the level of monitoring the bytes sent and received in the SSL records between the client and the server. I have repeated the test several times, with 100% repeatable results, which I consider to be 100% conclusive. I will attach some files to this bug to support the conclusions. Here is a very boiled down summary. I started with a copy of test2.php.html in a local file, which I accessed through a file URL. Then while recording all activity of the SSL library in excruciating detail, I clicked the button to submit the large test form. I received a new page in return, one that demonstrated the misordering of data. Here is what is seen in the SSL logs (which I will attach in a zip file). The client sends the https POST request as a series of SSL records. Record 1: 383 bytes: partial http POST request header Record 2: 49 bytes: more request header, containing the Content-Type line. Record 3: 24 bytes: last of request header, Content-Length: 6311 and an empty line. Record 4: 4072 bytes: The first part of the post data, beginning with this: field_number_001=This+is+field+number+001&... and ending with field_number_097=This+is+field+number+09 Record 5: 24 bytes: Contained exactly this: 7&field_number_098=This+ Record 6: 2215 bytes: The rest of the request, beginning with : is+field+number+098&field_number_099=This+is+fiel ... and ending with field_number_150=This+is+field+number+150&Submit=Send The response web page is attached (will be shortly). It reports that it received the entire 6311 byte length, and indeed the last bytes of the request are seen in that page. The "raw contents" of the buffer known as $POST appear to have this explanation. Record 5 was received into $POST. It's length was 4072 bytes. The contents of Record 6 is not seen. It may have been put into $POST immediately after Record 5, or it may have been put into $POST from the beginning, overwriting the first 24 bytes of Record 5 in $POST. But either way, the contents of Record 6 were subsequently overwritten by the contents of record 7. Record 7 was copied into $POST immediately following record 5, but it was also copied into $POST at the beginning, overwriting the first 2215 bytes of record 5. So the contents of Record 7 appear twice in their entirety in $POST, as the first 2215 bytes of $POST, and then again immediately following the contents of Record 5, beginning 4072 bytes into $POST. The log clearly shows that each of the SSL records was sent once, in order. The misordering of their data in $POST appears to have happened at the receiving end. Given that the client only sent record 7 one time, the fact that all the data from record 7 appears TWICE in $POST means that it was apparently copied twice after it was received. Why does the server have this problem only with FireFox? Probably because of the lengths of the records being sent by FireFox. FireFox does not send all the data in records of equal length. The standards do not require it to do so. The record sizes sent by FireFox may seem odd, but they are correct, not violating any standard. That is essentially the same problem that was seen in bug 356470, although the specifics of the exact record sizes differ somewhat. Assuming that record size can be shown to be the cause of this issue, and that FireFox developers want to work around this latest issue, as they did for bug 356470, I suggest that sending data in records of equal size is probably the only method that will avoid any recurrences.
Comment 32•17 years ago
|
||
Comment 33•17 years ago
|
||
Comment 34•17 years ago
|
||
The full SSL log file is too big to be attached to this bug, even when compressed with zip -9. So I am attaching only extracts from it here.
Comment 35•17 years ago
|
||
I assume that starting with Record 5 was received into $POST. It's length was 4072 bytes. in comment 31 all record numbers are 1 too big? > Assuming that record size can be shown to be the cause of this issue, Well... The patch for bug 383976 should make us send the data with a 4096 byte packet followed by a 2215 byte packet for the big data chunk... but my build with that patch is still showing this problem.
Updated•17 years ago
|
Flags: blocking1.9?
Comment 36•17 years ago
|
||
(In reply to comment #35) > I assume that starting with > Record 5 was received into $POST. It's length was 4072 bytes. > in comment 31 all record numbers are 1 too big? Yes, sorry. :(
Comment 37•17 years ago
|
||
Sounds like someone needs to look into this on the server end (with logging enabled).... In particular, is the issue PHP-specific? Does a simple shellscript that echoes back the POST data run into the same problems?
Comment 38•17 years ago
|
||
Can't block on this without verifying that it's a client issue (seems like it's not). We'd really like to get server-side networking logs to corroborate.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Updated•16 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Comment 39•14 years ago
|
||
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•