Re: Increasing the server write buffer for handshakes in 1.1.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
originally set!

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

Matt




> 
> 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
> https://github.com/blblack/openssl/commit/5c3f1e46b61db591ea61d560ee51535286afa1a4
> , 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.
> 
> 
> Thanks,
> -- Brandon
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux