search

linuxserver / docker-sabnzbd

GNU General Public License v3.0
272 stars 66 forks source link

[BUG] 3.7.2-ls95 and ls94 throw ssl.SSLZeroReturnError, ls93 still works #171

Closed furrnace closed 1 year ago

furrnace commented 1 year ago

Is there an existing issue for this?

Current Behavior

certificate is valid after upgrade to ls94 sabstarted throwing this error. ls95 also does it.

[14/Mar/2023:17:35:00] ENGINE Error in HTTPServer.serve Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/cheroot/server.py", line 1807, in serve self._connections.run(self.expiration_interval) File "/usr/lib/python3.10/site- packages/cheroot/connections.py", line 198, in run self._run(expiration_interval) File "/usr/lib/python3.10/site-packages/cheroot/connections.py", line 241, in _run new_conn = self._from_server_socket(self.server.socket) File "/usr/lib/python3.10/site-packages/cheroot/connections.py", line 295, in _from_server_socket s, ssl_env = self.server.ssl_adapter.wrap(s) File "/usr/lib/python3.10/site-packages/cheroot/ssl/builtin.py", line 270, in wrap s = self.context.wrap_socket( File "/usr/lib/python3.10/ssl.py", line 513, in wrap_socket return self.sslsocket_class._create( File "/usr/lib/python3.10/ssl.py", line 1071, in _create self.do_handshake() File "/usr/lib/python3.10/ssl.py", line 1342, in do_handshake self._sslobj.do_handshake() ssl.SSLZeroReturnError: TLS/SSL connection has been closed (EOF) (_ssl.c:997)

Expected Behavior

No response

Steps To Reproduce

start the container the error will be on the WUI and in the log

Environment

- OS: unraid
- How docker service was installed: container template used in unraid

CPU architecture

x86-64

Docker creation

docker run
  -d
  --name='sabnzbd'
  -e HOST_OS="Unraid"
  -e HOST_CONTAINERNAME="sabnzbd"
  -e 'PUID'='99'
  -e 'PGID'='100'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8070]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/sabnzbd-icon.png'
  -v '/mnt/user/appdata/sabnzbd/custom-cont-init.d':'/custom-cont-init.d':'ro'
  -v '/mnt/user/appdata/sabnzbd':'/config':'rw'
  --log-opt max-size=50M 'linuxserver/sabnzbd:3.7.2-ls95'

Container logs

User UID:    99
User GID:    100
───────────────────────────────────────

[custom-init] Files found, executing
[custom-init] README.txt: executing...
[custom-init] README.txt: exited 127
[custom-init] run-sabnzbd-without-fixed-port.sh: executing...
**** CUSTOM: copy start script to run SABnzbd without fixed port number ****
[custom-init] run-sabnzbd-without-fixed-port.sh: exited 1
[ls.io-init] done.
2023-03-14 18:27:34,596::ERROR::[_cplogging:213] [14/Mar/2023:18:27:34] ENGINE Error in HTTPServer.serve
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/cheroot/server.py", line 1807, in serve
    self._connections.run(self.expiration_interval)
  File "/usr/lib/python3.10/site-packages/cheroot/connections.py", line 198, in run
    self._run(expiration_interval)
  File "/usr/lib/python3.10/site-packages/cheroot/connections.py", line 241, in _run
    new_conn = self._from_server_socket(self.server.socket)
  File "/usr/lib/python3.10/site-packages/cheroot/connections.py", line 295, in _from_server_socket
    s, ssl_env = self.server.ssl_adapter.wrap(s)
  File "/usr/lib/python3.10/site-packages/cheroot/ssl/builtin.py", line 270, in wrap
    s = self.context.wrap_socket(
  File "/usr/lib/python3.10/ssl.py", line 513, in wrap_socket
    return self.sslsocket_class._create(
  File "/usr/lib/python3.10/ssl.py", line 1071, in _create
    self.do_handshake()
  File "/usr/lib/python3.10/ssl.py", line 1342, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLZeroReturnError: TLS/SSL connection has been closed (EOF) (_ssl.c:997)
github-actions[bot] commented 1 year ago

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

thespad commented 1 year ago

3.7.2-ls94 switched to a baseimage using openssl v3. If you're getting SSL errors it's likely your usenet provider is using obsolete SSL ciphers, which are no longer enabled by default in v3.

furrnace commented 1 year ago

and what is a solution? I cannot make the usenet provider change his ciphers.

thespad commented 1 year ago

You absolutely should ask your usenet provider to stop using obsolete ciphers but obviously you can't force them.

I believe this is an option, but we can't support it. Edit /etc/ssl/openssl.cnf add

# Configure as (add or uncomment as needed)

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1
thespad commented 1 year ago

Further digging suggests this might not be caused by the usenet provider but something else that Sab is connecting to (or is connecting to Sab) over HTTPS, such as RSS feeds or a 3rd party application that's interacting with it.

furrnace commented 1 year ago

ok, from my perspective that information is not yet actionable. any suggestions what to do to ether fix the container or what I would need to reconfig?

thespad commented 1 year ago

Bear with me about half an hour and I should have a PR image for you to test that I'm hoping will work around the exception.

thespad commented 1 year ago

Can you please try lsiodev/sabnzbd:3.7.2-pkg-18a67547-dev-7f40ff6f3cf054379d1d0b62986964f2883538a1 and see if it fixes the issue.

Safihre commented 1 year ago

SABnzbd developer here: it's the internal webserver of the application that throws this error when it's contacted by some browsers that check the validity of the server's ssl connection. So not usenet and not SABnzbd making any external connections.

Edit: seems you found that already 👍

thespad commented 1 year ago

Yeah, I just don't understand why openssl 3 has caused the exception to surface when it was fine under 1.x

furrnace commented 1 year ago

-ls97 did not fix this issue, it needs to be re-opened.

thespad commented 1 year ago

Then the cause of your problem is external to the container.

I extremely carefully replicated the issue using the service readiness check when HTTPS is enabled and caught every realistic combination of configuration options that could trigger it.

If you're still getting exceptions thrown then it's almost certainly something outside the container triggering them - and in any case it should not be a breaking issue, it's just something not properly establishing/terminating an SSL connection.

If you can definitively point to something inside the container that's causing the exception, then I'm happy to reopen the issue.

furrnace commented 1 year ago

Thanks for your effort, it is appreciated.