user1247280's questions

I have dovecot imap server and exim4 running on Debian Buster. I am using exim4 for smtp, but at the Debian upgrade before last (early Jan 2021), Debian arbitrarily turned on submission in dovecot by adding the file /usr/share/dovecot/protocols.d/submissiond.protocol. That blocks exim from properly servicing smtp.

It took me ages to find this was the cause, but once I had, I renamed that file to submissiond.protocol.unused and all was well. However, I did a Debian upgrade again today (with apt) in response to a security alert in an unrelated package, and it put that file back again and broke smtp once more.

Clearly I am not turning this protocol off in the correct way. What should I do to turn it off in such a way it stays off over Debian upgrades?

I have just upgraded a server to Debian Jessie, which includes Apache 2.4.10 (was 2.2), and PHP 5.6.

Now, SSL sites won't submit forms in some circumstances on IE11 and iPad Safari (not sure about desktop Safari). Firefox and Chrome are both OK. When it fails it produces a IE error page "This page can’t be displayed" in IE. Just to stress: I can get to the site and see the form, it's the form submission that then fails.

This is related to KeepAlive and SSL in some way. If I turn KeepAlive off in the SSL VirtualHost, the problem goes away. (It's using SNI, though one of the sites showing the error is the first SSL one). I am using mpm-itk (and was before the upgrade).

In IE11 (on Windows 7), it happens with * SSL (HTTPS) * Apache KeepAlive On, KeepAliveTimeout 5 (the default) * forms with file uploads (so enctype=multipart/form-data), * only when a file is actually supplied (it's OK with no file with or with other fields; even a 1 byte file causes it to fail, not file size dependent). * only if the upload is started within 60 seconds of displaying the form (i.e. it's OK if you leave it 60 seconds before pressing Submit)

There are no clues as to what has failed. There's nothing in the server logs to show it contacted the server again. The error is immediate. There is nothing in the IE debugger other than that it says "(Aborted)" in the result column of the network page and "Navigation occurred: File: dnserror.htm" which I assume is just the page it is displaying, but despite the name there is no dns error as far as I can tell. Fiddler shows no network traffic when I press the submit button. There is nothing relevant in the Windows event viewer. This is the strangest thing about it - it doesn't even seem to try.

For Apache 2.4, I've set up SSL as recommended here: https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.10&openssl=1.0.1k&hsts=no&profile=intermediate . CiperSuite is unchanged from my 2.2 set up, but OCSP staping is now on. The main 2.4 change is TLS1.2 (but Fidler downgrades this I believe, so it's unlikely to be that). HSTS is turned on, but was previously. SSLLabs gives the site an A+ rating and does not indicate any errors.

I have tried changing KeepAliveTimeout to 60; and also putting back in the old BrowserMatch ".MSIE." nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 and BrowserMatch ".MSIE." ssl-unclean-shutdown as an experiment, and I think this does have some effect, namely that it then works after the first attempt. But the first access from a newly started browser still fails. Possibly this is because it can't determine browser until after the SSL negotiation by which time it is too late, but after that the browser has more information? It's also possible I can't go through this process in under 60 seconds so the second time is OK because of that anyway.

I have made a little test site that demonstrates the problem: https://iet.davidearl.uk . It has a self-signed certificate just for the test case, so there's a certificate warning on first going there, but that's not the case with the real sites that have the problem. All the server side does in the test case is echo the file name of the submitted file, otherwise the HTML source is all there is.

On iPad, the problem seems worse, if anything. It seems not to be able to submit forms at all (while displaying them fine; irrespective of whether they have file uploads). Sometimes it just hangs, sometimes it has an internally generated error page ("Safari cannot open the page because the network connection was lost"), depending how the form is constructed. Again, though, the common factor is if you wait 60 seconds and then press the submit button, it works. An old version of Safari for PC (5.1.7) works OK though.

IE9 on (a different copy of) Windows 7 behaves like iPad Safari - it just hangs unless you wait 60 seconds after displaying the form. Microsoft Edge on Windows 10 and IE on Surface RT tablet also seem to fail in the same way as IE11. I have also observed one case where a PHP "file_get_contents("https..." accessing the server consistently hangs for exactly 60 seconds before suceeding, which worked instantly previously.

I have tried http : // superuser.com/questions/516030/apache-2-4-on-windows-responds-slowly-hangs-when-serving-some-dynamic-pages - no change This perhaps is related, but in their case KeepAlive Off had no effect; and turning off server firewall temporarily makes no difference: http : // serverfault.com/questions/678009/windows-8-ie-10-tls-handshake-errors-to-apache-2-2-on-centos-6-6 I have tried re-ordering the SSLCipherSuite to put ECDHE-RSA-AES128-SHA256 higher up the list (e.g. as suggested here: http : // serverfault.com/questions/677338/why-is-internet-explorer-11-unable-to-connect-to-https-sites-when-tls-1-2-is-ena ) Clear SSL State on Internet Properties > Content makes no difference.

There's clearly a problem related to KeepAlive and SSL, that isn't common, but I'm mystified as to what it is, and there's no clues to help me find out. Extensive searching hasn't yielded anything helpful.