PR_CONNECT_RESET_ERROR when sending POST multipart/form-data

Help
#1

For some unknown reason, there was a problem with uploading files (any) through the web form. After submitting form, the browser displays an error message with the code PR_CONNECT_RESET_ERROR. If I try to download a file over a normal connection (http), then everything is fine, no problem. Also no problem if, for example, I upload a picture (4Kb).

I hope for your help and thanks in advance!
.

My domain is: teboil.com.ua

I ran this command: POST HTTP-request multipart/form data

It produced this output: PR_CONNECT_RESET_ERROR

My web server is (include version): Apache/2.4.39

The operating system my web server runs on is (include version): CentOS 7.9.2009

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): CentOS Web Panel 0.9.8.1039 (free edition)

#2

Hi @andrej-tkachenko

that's not a Letsencrypt relevant question.

Please ask in another forum.

Thanks!

1 Like
#3

Hi @JuergenAuer,

I also think that this is a Letsencrypt relevant question.

My websites have been working fine for months, but all of a sudden stopped working yesterday, with the same error as @andrej-tkachenko.

Everything else works okay except file uploads.

I have checked everything from Apache to Nginx, upgraded my openssl version to the latest stable version, but nothing helped.

I also restarted my server several times, and restarted apache countless times.

I then deleted letsencrypt from one of the websites and the form posted successfully.

https://elimuza.com/testenc.php

This is a test form I created after narrowing down on the enctype="multipart/form-data" forms failing.

All other forms on the rest of the websites work fine except forms with enctype="multipart/form-data"

Firefox

Secure Connection Failed

An error occurred during a connection to elimuza.com. PR_CONNECT_RESET_ERROR

*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.

Chrome

The connection was reset.

Try:

ERR_CONNECTION_RESET

My server configurations are very similar to @andrej-tkachenko

I am also using
CentOS Web Panel
Centos
openssl-1.1.1i
Apache (I uninstalled Nginx thinking it could be the cause of the problem)

1 Like
#4

You are wrong.

There

https://elimuza.com/testenc.php

is a valid Letsencrypt certificate.

So your https configuration may be buggy. But that's not a certificate problem.

If you would buy a certificate, you would have the same problem.

PS: Uploaded a file dummy.txt, all worked.

Looks like that script had an update - and the update is buggy.

Or your hoster doesn't allow too large files, that interrupts started uploads.

Or your hoster configuration is buggy.

There are tons of problems possible.

1 Like
#5

PS: Yep, that script looks buggy, see the check of your ip address - https://check-your-website.server-daten.de/?q=elimuza.com%2Ftestenc.php

https://193.164.132.88/testenc.php

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AND a.country = "" ORDER BY institution_name asc ,id ASC LIMIT 20' at line 6 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AND a.country = ""' at line 6 Please try one of the following pages: Home Page

Such an error may interrupt / reset the connection.

PPS: And why are such errors public visible?

Looks like it is possible to hack your database with Sql injections.

Never, never, never publish such informations. And a script, that accepts Sql-injections -> throw it away.

2 Likes
#6

So your https configuration may be buggy. But that's not a certificate problem.

The script does not post to a php script.

It fails at the form's submission point.

It never gets to the server, never reaches any php script.

Ideally on submission of the test form it should just load a html page.

Any file upload for my live busy websites which used to work no longer work, the one I sent was just a staging website.

Ajax uploads behave in a similar way.

Thanks for the heads up on the SQL, :grinning: I fixed it.

Or your hoster doesn't allow too large files, that interrupts started uploads.

Or your hoster configuration is buggy.

The exact same form works when I delete letsencrypt.

#7

So you know the https handling of that script is buggy.

Fix it.

But a wrong https handling of a script isn't a certificate problem, it's a script problem.

1 Like
#8

Capture
Capture853×349 16.6 KB

So your https configuration may be buggy. But that's not a certificate problem.

My configuration is okay.

So you know the https handling of that script is buggy.

It's not just this one script. All forms with enctype="multipart/form-data" and which upload files of any size(even 1 kb), that used to work before, suddenly stopped working yesterday. I hadn't changed anything on my server. I am the only one with root access.

Let me continue looking for a solution, but I have a feeling you will hear about this more in the coming days.

:slight_smile:

#9

Your configuration is buggy, see your screenshot. Or see https://check-your-website.server-daten.de/?q=elimuza.com/testenc.php#connections if you want an explantation.

But that buggy configuration doesn't explain the PR_RESET.

PS: Why do you hide public visible informations? Your certificate and your wrong chain are worldwide visible. Hiding such informations is a little bit curious.

1 Like
#10

Maybe you recommend configuration SSL? My configuration now (ssl.conf):

SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA!RC4:EECDH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
#11

I don't see how those SSL/TLS settings could cause such an error.

Does this error occur for every client? Or just a few? On the internet, I saw a few threads mentioning anti virus software like Avast or others causing this error.

It also might be some kind of MTU problem. Not an issue when the packets are small, but causing issues when the TCP packets are fully loaded.

#12

PS: There are some GZIP options possible.

File size greater 1 kb -> use GZIP. May be that's buggy.

Or the script throws an unhandled exception, so the Content-length in the header and the content-length of the page don't match.

PPS: If it would be a real SSL / certificate problem, an upload of a 5 byte file would be affected. But that works -> so it's a script- or configuration problem.

1 Like
#13

Does this error occur for every client?

It occurs on every client.

I tested on Chrome, Firefox, Chrome for Android.

@andrej-tkachenko also

I ran this command: POST HTTP-request multipart/form data

And he got a similar error.

On the internet, I saw a few threads mentioning anti virus software like Avast or others causing this error.

I saw that too but tested on several computers and mobile, still the same.

#14

Or the script throws an unhandled exception, so the Content-length in the header and the content-length of the page don't match.

The form's data doesn't get to the server. As soon as you hit submit it fails with the error above, doesn't even try to upload the file.

An empty script with an 'exit', no bugs will display the same error.

#15

It actually does. Try using Wireshark, I just did that. When sending a file (1 MB in my case), the server accepts the HTTPS connection and it even acknowledges (through TCP "ACK" packets) multiple parts of the file being send. However, after 17 ACK packets, your server just suddenly, during the transfer of the file, sends a TCP RST packet!

Also something I noticed what is different between the HTTP and HTTPS packet dump: with the HTTP packets, your server actually acknowledges the received TCP packets in order. I.e., my host sends packets 1, 2, 3 and 4, your server correctly acknowledges packets 1, followed by packet 2, followed by packet 3 and so on. However, when using HTTPS, your server skips packets when acknowledging the received packets! It jumps from packet 1 to 3 to 6 to 8 to 10. Very strange behaviour.

In any case, it's your server causing the disconnect after a few kilobytes of received data.

#16

That's

wrong.

Created a small test code with the resources of "check-your-website".

It's possible to upload a dummy file with 6 KB.

But: That's not gzipped (additional: Browsers are using GZIP typically if the file is larger then 1024 Bytes).

Hah: 41kb crashes with the same error:

ReceiveFailure - The underlying connection was closed: An unexpected error occurred on a receive.

That's the PR_END error.

Haha: 8192 Bytes are ok. 8193 -> crash.

1 Like
#17

If I send a small file, Wireshark tells me the server will again acknowledge in the strange way, skipping one packet every time, but now it actually does "recognise" the last received packet as being the last, as it closes the TCP connection server-side with a correct FIN/ACK packet. It however "forgets" to send any HTTP response what so ever, so CURL complains about an "Empty reply from server".

In any case, something is terribly wrong with the server side network stack on port 443. Perhaps the TLS library used, perhaps something OS-related, I don't know.

I think however it's almost certainly not something certificate related.

#18

PS:

Every webserver has a configuration option that limits the size of uploaded files.

If there are 8kb allowed, that's 8192 bytes.

So if the http version has no (or a higher) limit and the https version has such a limit (OS / webserver update), that result is expected.

1 Like
#19

Usually the webserver would reply with a meaningfull error message though.

#20

Maybe CWP creates incorrect certificate? Need to check it somehow