upload limits to SSL-secured sites

We’re using a SSL-secured site to provide external access to some services via HTTP (which makes it “https”), and are using client-side certificates to address two-way authentication issues.

Then there was the famous “man-in-the-middle” problem during session renegotiation that was detected in 2009. Fixing it required architectural changes, and it took it’s time. But eventually, the changes made it into the httpd servers and the Openssl stack that many of them rely on.

Since then, we’ve experienced two practical problems: With the first updates, some of our server-side applications had trouble dealing with clients during SSL re-negotiations. That was many months ago and resulted in entries like “Re-negotiation  handshake failed: Not accepted by client!?” in the server error log. The “fix” was to set up the affected site in such a way that all directories had identical settings for the “SSLVerifyClient” option, thus avoiding the re-negotiation.

But lately we had to change a site that needed different settings per directory – part of the site had to have it’s traffic protected and the server authenticated to the client (by using a server-side certificate and setting “SSLVerifyClient optional”), while some areas needed to protect access by verifying the clients’ certificates, thus operating with “SSLVerifyClient require”. This was with SLES11SP2, so it’s up-to-date code, at least from the distribution’s point of view.

When we changed the server configuration, users that had to do larger uploads (i.e. when using a webmail application on that server and adding larger attachments) were struck by the old symptoms. Fortunately, the server log had a new and more obvious message to present: “request body exceeds maximum size (131072) for SSL buffer”.

Actually it’s the same root cause that’s behind this message: During a POST request, the client’s data is sent to the server and eventually the server will detect that a re-negotiation of the SSL session parameters is needed. That’s the moment when the POST data has to be stored somewhere – in the “SSL buffer” mentioned in the message. And in order to handle larger uploads, you’ll have to bump up that buffer size, which can easily be done by adding the “SSLRenegBufferSize” to the server configuration. Fortunately, this can be handled on a per-directory basis, as requests making use of that buffer need not necessarily be authenticated. Bumping up that limit for all areas of the server can leave the doors open for a denial-of-service attack.

Anyhow, once we’ve increased the value of that parameter to the actual demand of the application (or rather that of the users), everything was back to usable.