[openssl-users] Increasing the server write buffer for handshakes in 1.1.0
matt at openssl.org
Mon Nov 14 10:04:34 UTC 2016
On 12/11/16 16:29, Brandon Black wrote:
> Hi all,
> I'm running into an issue where if the server handshake response
> exceeds some value a little over 4K (which is pretty easy these days
> with a typical public cert, intermediate, and stapled OCSP response),
> we're suffering an extra RTT in our SSL negotiations with
> OpenSSL-1.1.0 (vs 1.0.2). The server software is nginx. You can see
> our internal ticket with more detail at:
> https://phabricator.wikimedia.org/T150561 .
> This same issue was already raised and fixed with nginx years ago
> against older OpenSSL versions in
> https://trac.nginx.org/nginx/ticket/413 .
> I suspect the workaround implemented at the time (which is obviously
> not an ideal use of the APIs to begin with, with that wbio vs rbio
> pointer comparison...) no longer works for 1.1.0. I've tried
> unconditionally calling BIO_set_write_buffer_size() in the same
> callback as well, but it didn't improve the situation.
During the handshake phase OpenSSL adds a buffering BIO in front of the
wbio. However when you call SSL_get_wbio(), you get back the *real* wbio
(without the bbio on the front). This is a change of behaviour between
1.1.0 and 1.0.2, and was because it was considered a bug that you could
get back a different wbio from SSL_get_wbio() than the one that you
So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio()
is going to make no difference at all!
Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0.
I would certainly consider a pull request to add an accessor to get hold
of it (missing accessors are considered as bug-fixes and so would be
eligible for inclusion in a future 1.1.0d).
> Is there an appropriate way to use the API to work around the write
> buffer limit at handshake time for a server application with 1.1.0,
> that we could patch up nginx with?
> Another alternative would be to raise the default buffer size to 8K to
> be more reflective of modern conditions. I've made such a commit at
> , but I haven't filed a pull request yet as I'm unsure on a couple of
> fronts here:
> (1) Whether there's an easier answer for server software developers
> within the existing APIs (the main question in this post)
> (2) With the default also currently being reused as the minimum
> possible buffer size, I'm not sure whether it would be acceptable to
> raise the minimum to 8K as well when changing the default. Splitting
> the two would be a bit more invasive.
> -- Brandon
More information about the openssl-users