Skip Menu |
 

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

Report information
The Basics
Id: 129463
Status: open
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.


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.