Skip Menu |
 

This queue is for tickets about the IO-Socket-SSL CPAN distribution.

Report information
The Basics
Id: 129463
Status: resolved
Priority: 0/
Queue: IO-Socket-SSL

People
Owner: Nobody in particular
Requestors: e [...] 80x24.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments
0001-enable-SSL_MODE_RELEASE_BUFFERS-by-default.patch



Subject: [PATCH] enable SSL_MODE_RELEASE_BUFFERS by default
Date: Sun, 5 May 2019 21:26:11 +0000
To: bug-IO-Socket-SSL [...] rt.cpan.org
From: Eric Wong <e [...] 80x24.org>
Download (untitled) / with headers
text/plain 293b
SSL_CTX_set_mode(3ssl) manpage states this can save around 34k per idle connection. Contributed to OpenSSL by the Tor project, this feature has been available since OpenSSL 1.0.0a and enabled by default in popular projects such as: curl, nginx, Ruby, and (of course) tor. Patch is attached.

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 1.5k
Am So 05. Mai 2019, 17:33:50, e@80x24.org schrieb: Show quoted text
> SSL_CTX_set_mode(3ssl) manpage states this can save around 34k > per idle connection. > > Contributed to OpenSSL by the Tor project, this feature has been > available since OpenSSL 1.0.0a and enabled by default in popular > projects such as: curl, nginx, Ruby, and (of course) tor. > > Patch is attached.
Thanks for the patch - but I'm not completely sure if I should apply it. First, while Python has this too it comes with specific restrictions there of when to apply it, since some versions of OpenSSL had CVE in this area, see https://github.com/python/cpython/blob/master/Modules/_ssl.c#L3072 Also, if this would be completely free of side effects then why would this option not be enabled by default in OpenSSL? From my understanding of the code in OpenSSL this option should be useful only if nothing will be read/write for a long time but the SSL object is still allocated. If instead lots of reads and writes are done on the SSL object it will instead continously free memory and allocate new memory, which actually might slow down the application. This is especially true if memory management itself has a large overhead: on some systems unused memory is actually returned to the system which means that syscalls are involved which can slow down everything a lot. Do you have any real-world experience which suggests that this option should be enabled by default even though OpenSSL has it disabled by default? And which describes the actual use cases where this option is useful and where it is harmful?
CC: behroozi [...] www.pls.uni.edu
Subject: Re: [rt.cpan.org #129463] [PATCH] enable SSL_MODE_RELEASE_BUFFERS by default
Date: Mon, 6 May 2019 07:12:48 +0000
To: Steffen Ullrich via RT <bug-IO-Socket-SSL [...] rt.cpan.org>
From: Eric Wong <e [...] 80x24.org>
Download (untitled) / with headers
text/plain 3.6k
Steffen Ullrich via RT <bug-IO-Socket-SSL@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=129463 > > > Am So 05. Mai 2019, 17:33:50, e@80x24.org schrieb:
> > SSL_CTX_set_mode(3ssl) manpage states this can save around 34k > > per idle connection. > > > > Contributed to OpenSSL by the Tor project, this feature has been > > available since OpenSSL 1.0.0a and enabled by default in popular > > projects such as: curl, nginx, Ruby, and (of course) tor. > > > > Patch is attached.
Show quoted text
> Thanks for the patch - but I'm not completely sure if I should > apply it. First, while Python has this too it comes with > specific restrictions there of when to apply it, since some > versions of OpenSSL had CVE in this area, see > https://github.com/python/cpython/blob/master/Modules/_ssl.c#L3072
Thanks for the quick response. Interesting, I wasn't aware of CVE-2014-0198 specifically (too many OpenSSL CVEs to keep track of), but it seemed to only affect SSLv3 on ancient OpenSSL versions. I figure those users have bigger problems and would've fallen over by now, and not keeping IO::Socket::SSL up-to-date :) Show quoted text
> Also, if this would be completely free of side effects then > why would this option not be enabled by default in OpenSSL?
Good question, I would guess inertia. Show quoted text
> From my understanding of the code in OpenSSL this option > should be useful only if nothing will be read/write for a long > time but the SSL object is still allocated. If instead lots of > reads and writes are done on the SSL object it will instead > continously free memory and allocate new memory, which > actually might slow down the application. This is especially > true if memory management itself has a large overhead: on some > systems unused memory is actually returned to the system which > means that syscalls are involved which can slow down > everything a lot.
In my experience, traffic and throughput on a single socket is rarely (if ever) significant in terms of CPU usage. Various malloc implementations have also improved in throughput over the years; and they tend to avoid making syscalls to release memory to the kernel. So, having memory idle for a "long time" could be milliseconds, even, which is an eternity for buffers to sit idle. What adds up is memory usage from multiple sockets, and being able to reuse idle memory across different sockets means better overall locality and fewer calls to mmap/brk to request memory from the kernel. Perhaps that memory reuse can increase the chance of a data leak if there's other bugs in the code; but it may also reduce that chance as data is frequently clobbered and not sitting idle in buffers. Show quoted text
> Do you have any real-world experience which suggests that this > option should be enabled by default even though OpenSSL has it > disabled by default? And which describes the actual use cases > where this option is useful and where it is harmful?
I've used nginx for TLS for many years; and now run another C10K server, yahns (which I wrote in Ruby) on my own sites. I may replace yahns with another C10K HTTPS/NNTP+TLS server I write in Perl5. I've yet to encounter a point on a public HTTPS server where TLS traffic from a single socket caused performance problems. Maybe it can happen in extremely high bandwidth situations and giant files, but that's not most TLS users. I'm not sure why OpenSSL does not enable it by default, probably an abundance of caution since it was "new" at some point. But it is enabled on security-sensitive projects, such as Tor, which also has many concurrent connections to manage. Along the same lines, I'm glad you enabled SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default. Ruby didn't enable it until I added it, so I had to resort to a nasty workaround in yahns.
CC: behroozi [...] www.pls.uni.edu
Subject: Re: [rt.cpan.org #129463] [PATCH] enable SSL_MODE_RELEASE_BUFFERS by default
Date: Mon, 24 Jun 2019 19:13:59 +0000
To: Steffen Ullrich via RT <bug-IO-Socket-SSL [...] rt.cpan.org>
From: Eric Wong <e [...] 80x24.org>
Download (untitled) / with headers
text/plain 565b
Steffen Ullrich via RT <bug-IO-Socket-SSL@rt.cpan.org> wrote: Show quoted text
Btw, is reaching into $foo->{context} of a IO::Socket::SSL::SSL_Context ref something that we can expect to remain supported? I'm currently doing that to enable SSL_MODE_RELEASE_BUFFERS in public-inbox-nntpd: https://public-inbox.org/meta/20190624025258.25592-44-e@80x24.org/ The 346MB => 171MB reduction with 10K clients is a significant savings (but 171MB is still too much for my liking). Anyways, thanks for all your work on this!
Download (untitled) / with headers
text/plain 1.2k
Am Mo 24. Jun 2019, 15:20:19, e@80x24.org schrieb: Show quoted text
> Steffen Ullrich via RT <bug-IO-Socket-SSL@rt.cpan.org> wrote: > > Btw, is reaching into $foo->{context} of a IO::Socket::SSL::SSL_Context > ref something that we can expect to remain supported? > > I'm currently doing that to enable SSL_MODE_RELEASE_BUFFERS in > public-inbox-nntpd: > > https://public-inbox.org/meta/20190624025258.25592-44-e@80x24.org/ > > The 346MB => 171MB reduction with 10K clients is a significant savings > (but 171MB is still too much for my liking). > > Anyways, thanks for all your work on this!
I've enabled now easy support to set this option by using SSL_mode_release_buffers on the context, see https://github.com/noxxi/p5-io-socket-ssl/commit/47ad659a706ec19a966f2f62fb64f6493d6d1741 I did not enable this option by default though since I'm due to a lack of actual performance measurements still not convinced that enabling it makes universally sense. The documentation states that the saving is only for idle connections and from the code it can be seen that if this option is enabled it will need to reallocate and initialize a new read buffer on each call to SSL_read.
CC: behroozi [...] www.pls.uni.edu
Subject: Re: [rt.cpan.org #129463] [PATCH] enable SSL_MODE_RELEASE_BUFFERS by default
Date: Wed, 15 Jan 2020 09:26:52 +0000
To: Steffen Ullrich via RT <bug-IO-Socket-SSL [...] rt.cpan.org>
From: Eric Wong <e [...] 80x24.org>
Download (untitled) / with headers
text/plain 1.8k
Steffen Ullrich via RT <bug-IO-Socket-SSL@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=129463 > > > Am Mo 24. Jun 2019, 15:20:19, e@80x24.org schrieb:
> > Steffen Ullrich via RT <bug-IO-Socket-SSL@rt.cpan.org> wrote: > > > > Btw, is reaching into $foo->{context} of a IO::Socket::SSL::SSL_Context > > ref something that we can expect to remain supported? > > > > I'm currently doing that to enable SSL_MODE_RELEASE_BUFFERS in > > public-inbox-nntpd: > > > > https://public-inbox.org/meta/20190624025258.25592-44-e@80x24.org/ > > > > The 346MB => 171MB reduction with 10K clients is a significant savings > > (but 171MB is still too much for my liking). > > > > Anyways, thanks for all your work on this!
Show quoted text
> I've enabled now easy support to set this option by using > SSL_mode_release_buffers on the context, see > https://github.com/noxxi/p5-io-socket-ssl/commit/47ad659a706ec19a966f2f62fb64f6493d6d1741
Thanks, seems like a good compromise. Show quoted text
> I did not enable this option by default though since I'm due > to a lack of actual performance measurements still not > convinced that enabling it makes universally sense. The > documentation states that the saving is only for idle > connections and from the code it can be seen that if this > option is enabled it will need to reallocate and initialize a > new read buffer on each call to SSL_read.
Fair enough. My main concern is memory usage. For few/single connections that are always hot, I do expect realising buffers to be slower. However, I expect real-world HTTPS, NNTPS, IMAPS connections to be mostly idle because of persistent connections (driven by TLS negotiation time) and any overhead of malloc/free to be inconsequential compared to having to thrash swap as a result of high memory use.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.