SLES11SP2 apache2 SSL renegotiation problem

SUSE Linux Enterprise Server SLES Networking
1

Hi folks,

this is about trouble-shooting a SSL renegotiation problem that seems somehow non-ordinary. Background is a web server used for SSL-secured web mail, with required client-side certificates for authentication.

Most things work - general access to the server, I can read e-mail, I can send e-mail, I can delete e-mail (Hi Jen :D). The certificates in question (server, client) are valid and seem to work nicely.

We had a problem uploading larger attachments (resulting in error log entries “request body exceeds maximum size”), which got fixed by adding the SSLRenegBufferSize parameter (for those interested: http://technik.blogs.nde.ag/2013/01/13/upload-limits-to-ssl-secured-sites/).

Now we again have problems with renegotiation, not only with uploading attachments, but that’s my current test case because it it easily reproducable.

In the Apache error log, the following two messages appear upon running the test case:
[Wed Jan 30 13:11:06 2013] [error] [client 192.168.x.y] Re-negotiation handshake failed: Not accepted by client!?, referer: https://mylonguri
[Wed Jan 30 13:11:06 2013] [error] [client 192.168.x.y] Re-negotiation request failed, referer: https://mylonguri

I’ve tracked this down as far as occuring during a POST request that is exceeding some size limit, and I see the following in the network trace of that https connection:

  • client and server successfully establish an https connection to exchange (some) preliminary http(s) request(s) (both POST and GET), which work fine (setting up the browser window to display the upload form)
  • the client sends the (encrypted) POST request with the form data, including the attached file. This spans two TCP packets.
  • the server responds via a “TLSv1 Hello request”
  • (there’s an according TCP ack from client to server)
  • the server sends a “TLSv1 fatal alert: unexpected message” (code decimal 10)
  • (there’s an according TCP ack from client to server)
  • the client sends an “TLSv1 client hello” including a renegotiation_info extension, length 12, and an empty SessionTicket extension
  • the client sends a “TLSv1 warning alert: close notify”
  • the client closes the TCP connection, the server agrees and the TCP session is gone

When I look at a functional upload, the only difference is that the sole TCP acks are not there - the client immediately responds to the server’s “hello request” with its “client hello” and everything is fine. In the working case, the POST request is 7214 bytes long (TCP len: 7148, http content length 6397) and contained in a single TCP frame. In the non-working case, the payload spans two TCP frames, TCP len 5792 and 2534 bytes, http content length 7536.

(The size difference in my test case results from having additional e-mail text in the http form, resulting in the larger message size.)

To me it seems that Apache httpd’s handling of multi-segment requests breaks the renegotiation handling. Installed version is from SLES11SP2:

Name : apache2 Relocations: (not relocatable)
Version : 2.2.12 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Release : 1.30.1 Build Date: Fri Feb 3 17:08:52 2012
Install Date: Mon Feb 20 04:00:24 2012 Build Host: gubaidulina
Group : Productivity/Networking/Web/Servers Source RPM: apache2-2.2.12-1.30.1.src.rpm
Size : 2422606 License: The Apache Software License
Signature : RSA/8, Fri Feb 3 17:09:16 2012, Key ID e3a5c360307e3d54
Packager : http://bugs.opensuse.org
URL : http://httpd.apache.org/
Summary : The Apache Web Server Version 2.2

Any thought on this? Or should I rather open a bug report :wink:

With regards,
Jens