SABnzbd Forums

Posted: **August 27th, 2017, 10:50 pm**

Hi all,

I'm running 2.2.1 from source on Debian testing

I can connect to a non-Astraweb newsgroup server using SSL and it connects fine, but with Astraweb I get this error:

[Errno 111] [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661)

I've tried ssl-eu.astraweb.com, ssl-us.astraweb.com, and ssl.astraweb.com on both 443 and 563 but always get this same error.

Certificate verification is "minimal".

Version: 2.2.1 [bcc4dd7]
OpenSSL: OpenSSL 1.1.0f 25 May 2017 [TLS v1.2, TLS v1.1, TLS v1]
Python Version: 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118] [UTF-8]

Here's a bit more of the log:

Code: Select all

2017-08-27 20:43:25,320::INFO::[happyeyeballs:138] Quickest IP address for ssl-eu.astraweb.com (port 443, ssl 1, preferipv6 True) is 91.208.207.43
2017-08-27 20:43:25,321::DEBUG::[happyeyeballs:140] Happy Eyeballs lookup and port connect took 20 ms
2017-08-27 20:43:25,321::DEBUG::[downloader:136] ssl-eu.astraweb.com: Connecting to address 91.208.207.43
2017-08-27 20:43:25,322::INFO::[downloader:487] [email protected]: Initiating connection
2017-08-27 20:43:25,322::DEBUG::[downloader:117] ssl-eu.astraweb.com: Re-using address 91.208.207.43
2017-08-27 20:43:25,323::INFO::[downloader:487] [email protected]: Initiating connection
2017-08-27 20:43:25,323::DEBUG::[downloader:117] ssl-eu.astraweb.com: Re-using address 91.208.207.43
2017-08-27 20:43:25,324::INFO::[downloader:487] [email protected]: Initiating connection
2017-08-27 20:43:25,324::DEBUG::[downloader:117] ssl-eu.astraweb.com: Re-using address 91.208.207.43
2017-08-27 20:43:25,325::INFO::[downloader:487] [email protected]: Initiating connection
2017-08-27 20:43:25,325::DEBUG::[downloader:117] ssl-eu.astraweb.com: Re-using address 91.208.207.43
2017-08-27 20:43:25,692::INFO::[newswrapper:283] Failed to connect: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661) [email protected]:443
2017-08-27 20:43:25,700::INFO::[newswrapper:283] Failed to connect: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661) [email protected]:443
2017-08-27 20:43:25,704::INFO::[newswrapper:283] Failed to connect: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661) [email protected]:443
2017-08-27 20:43:25,713::INFO::[newswrapper:283] Failed to connect: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661) [email protected]:443
2017-08-27 20:43:25,718::INFO::[newswrapper:283] Failed to connect: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661) [email protected]:443

Thanks in advance for any troubleshooting recommendations!

Posted: **August 28th, 2017, 12:35 am**

There is no matching SSL/TLS protocol between Astraweb and Debian Testing ... $:-\$

See https://github.com/sabnzbd/sabnzbd/issues/994

Explanation:
- astraweb.com only supports TLS1. That's really bad; TLS1 was defined in 1999, and is not considered safe anymore.
- Debian *unstable* has disabled TLS1 and TLS1.1 (for the above reason), and only supports TLS1.2
- I'm assuming Debian unstable is/does the same as testing ...

Posted: **August 28th, 2017, 12:25 pm**

Hi sander, thanks for the tip. I did not find that bug report during my online searches. Astraweb SSL works with other, non-Python based newsreaders on Debian Testing. e.g. ClawsMail, "nzb". Do we expect a change in the next Debian Python package that will remedy the situation or do we need to make a workaround... I don't want to run everything through stunnel.

Posted: **August 28th, 2017, 4:44 pm**

We cannot change anything about this and TLSv1 is not coming back to Debian...

The only way to fix would be to bundle our own whole OpenSSL, instead of linking against the system one. You can imagine that's not something we want to get in to..

Astraweb needs to fix this, looking at the list of providers 90% supports TLSv1.2, so why not such a big provider like them?
https://www.appelboor.com/newsservers/n ... h-SSL.html

Posted: **August 28th, 2017, 5:17 pm**

Hi trinsnet,

Debian will probably not fix nor remedy this; It's Debian's clear (and maybe bold) decision to disable TLS1 and TLS1.1. See https://lists.debian.org/debian-devel-a ... 00004.html

IMHO Astraweb should solve this and introduce TLS1.2, just like almost other newsproviders did in the past. Can you contact them?

Posted: **August 28th, 2017, 5:30 pm**

PS:

What I don't understand: Testing is not Unstable according to https://www.debian.org/releases/

So ... are you sure you use Testing, and not Unstable?

Posted: **August 29th, 2017, 9:21 am**

Hey trinsnet, can you try out ssl-test.astraweb.com as newsserver?

I don't know if it is valid server, but it does support TLS1.2.

https://www.appelboor.com/cgi-bin/check ... traweb.com

Code: Select all

sander@haring:~/git/testssl.sh$ ./testssl.sh ssl-test.astraweb.com:563

<snip>


 Start 2017-08-29 16:22:05        -->> 193.202.122.156:563 (ssl-test.astraweb.com) <<--

<snip>


 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered
 TLS 1.1    offered
 TLS 1.2    offered (OK)
 SPDY/NPN   (SPDY is an HTTP protocol and thus not tested here)
 HTTP2/ALPN (HTTP/2 is a HTTP protocol and thus not tested here)

and with nmap

Code: Select all

sander@haring:~$ nmap --script ssl-enum-ciphers  ssl-test.astraweb.com

Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-29 16:27 CEST
Nmap scan report for ssl-test.astraweb.com (193.202.122.156)
Host is up (0.0050s latency).
rDNS record for 193.202.122.156: unknown.ams.astraweb.com
Not shown: 996 closed ports
PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
| ssl-enum-ciphers:
|   SSLv3: No supported ciphers found
|   TLSv1.0:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_IDEA_CBC_SHA - weak
|       TLS_RSA_WITH_RC4_128_MD5 - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.1:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_IDEA_CBC_SHA - weak
|       TLS_RSA_WITH_RC4_128_MD5 - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - strong
|     compressors:
|       NULL
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_IDEA_CBC_SHA - weak
|       TLS_RSA_WITH_RC4_128_MD5 - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|       TLS_RSA_WITH_SEED_CBC_SHA - strong
|     compressors:
|       NULL
|_  least strength: weak
563/tcp  open  snews
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.62 seconds

Posted: **August 29th, 2017, 9:50 am**

Oh, this looks bad as in: what a mess with Astraweb:

ssl.astraweb.com resolves to 8 different IP addresses. So far I've scanned 5 IP addresses for their TLS/SSL setup on port 563, and all of them have a different setup... and only one of them supports TLS1.2

@OP ... as a debian user you probably know how to hard lock ssl.astraweb.com to that IP address 216.151.153.13 ... Can you do that and try again?

Start 2017-08-29 16:32:17 -->> 207.246.207.131:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:36:24 -->> 207.246.207.127:563 (ssl.astraweb.com) <<--
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:39:17 -->> 216.151.153.13:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
--
Start 2017-08-29 16:44:00 -->> 8.17.249.103:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered

--
Start 2017-08-29 16:47:41 -->> 216.151.153.132:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered

Posted: **August 29th, 2017, 1:21 pm**

Hi Sander, I am running testing, not unstable (Linux 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux):
deb http://mirror/debian/ testing main non-free #sanitized mirror
deb-src http://mirror/debian/ testing main non-free #sanitized mirror
deb http://security.debian.org/debian-security testing/updates main non-free
deb-src http://security.debian.org/debian-security testing/updates main non-free

I ran my own DNS lookup against the domain names, which results in some different IP's as compared to yours (I don't get 216.151.153.13):
;; ANSWER SECTION:
ssl.astraweb.com. 3 IN A 8.17.249.103
ssl.astraweb.com. 3 IN A 207.246.207.123
ssl.astraweb.com. 3 IN A 207.246.207.11
ssl.astraweb.com. 3 IN A 216.151.153.123
ssl.astraweb.com. 3 IN A 216.151.153.132
ssl.astraweb.com. 3 IN A 216.151.153.124
ssl.astraweb.com. 3 IN A 207.246.207.127
ssl.astraweb.com. 3 IN A 216.151.153.191

;; ANSWER SECTION:
ssl-eu.astraweb.com. 4 IN A 193.202.122.24
ssl-eu.astraweb.com. 4 IN A 193.202.122.140
ssl-eu.astraweb.com. 4 IN A 91.208.207.152
ssl-eu.astraweb.com. 4 IN A 193.202.122.138
ssl-eu.astraweb.com. 4 IN A 193.202.122.119
ssl-eu.astraweb.com. 4 IN A 193.202.122.170
ssl-eu.astraweb.com. 4 IN A 193.202.122.167
ssl-eu.astraweb.com. 4 IN A 193.202.122.135

;; ANSWER SECTION:
ssl-us.astraweb.com. 1 IN A 216.151.153.129
ssl-us.astraweb.com. 1 IN A 216.151.153.124
ssl-us.astraweb.com. 1 IN A 216.151.153.191
ssl-us.astraweb.com. 1 IN A 216.151.153.76
ssl-us.astraweb.com. 1 IN A 8.17.249.103
ssl-us.astraweb.com. 1 IN A 216.151.153.132
ssl-us.astraweb.com. 1 IN A 207.246.207.127
ssl-us.astraweb.com. 1 IN A 207.246.207.14

I ran SSL enumeration against all the IP's. Only 207.246.207.11 on 443 and 563 supports TLSv1.2. SABnzbd connection test is successful with this IP, however I will not run SABnzbd like this since it bypasses the provider's DNS-based load balancing.

Looks like OpenSSL is the culprit?
OpenSSL> list -disabled
Disabled algorithms:
HEARTBEATS
IDEA
MD2
MDC2
RC5
SCTP
SSL3
TLS1
TLS1_1
ZLIB

But I still do not fully understand why some other newsreaders on my system still work... I can't tell if they use something other than OpenSSL.

Posted: **August 29th, 2017, 2:37 pm**

They compile openssl themselves within the binary.
This prevents issues like this, but in case there's a fatal bug in openssl only updating the program would fix it. While in the case of python and others that use the system openssl (which is mostly patched faster) they are safer.

Posted: **August 29th, 2017, 2:47 pm**

FYI I just tested out ssl-test.astraweb.com and it seems to work.

thanks to both of you for your assistance!

Posted: **August 29th, 2017, 5:01 pm**

FWIW:

Debian Unstable (in a docker container) gives a different output for "openssl list -disabled" (different from your Debian Testing output)

Code: Select all

root@347c63d9cc4c:/# openssl  list -disabled
Disabled algorithms:
HEARTBEATS
IDEA
MD2
MDC2
RC5
SCTP
SSL3
ZLIB
root@347c63d9cc4c:/#

Posted: **August 30th, 2017, 2:17 am**

Debian testing is basically unstable-with-a-5-day-delay. New package versions go into unstable first, then migrate into testing unless blocked (usually by some serious bug being filed in the meantime). Openssl currently has different versions in unstable (1.1.0f-5) vs testing (1.1.0f-4) that handle the tls1.0/1.1 situation differently:

openssl (1.1.0f-5) unstable; urgency=medium

* Instead of completly disabling TLS 1.0 and 1.1, just set the minimum
version to TLS 1.2 by default. TLS 1.0 and 1.1 can be enabled again by
calling SSL_CTX_set_min_proto_version() or SSL_set_min_proto_version().

-- Kurt Roeckx <[email protected]> Tue, 08 Aug 2017 16:13:54 +0200

openssl (1.1.0f-4) unstable; urgency=medium

[ Sebastian Andrzej Siewior ]
* Add support for arm64ilp32, patch by Wookey (Closes: #867240)

[ Kurt Roeckx ]
* Disable TLS 1.0 and 1.1, leaving 1.2 as the only supported SSL/TLS
version. This will likely break things, but the hope is that by
the release of Buster everything will speak at least TLS 1.2. This will be
reconsidered before the Buster release.
* Fix a race condition in the test suite (Closes: #869856)

-- Kurt Roeckx <[email protected]> Mon, 07 Aug 2017 01:08:45 +0200

Still, the real problem to fix is at astraweb. Once enough of their customers complain, they'll fix their prehistoric cert - especially since they already have a working one for tls1.2 on hand anyway.

Posted: **August 30th, 2017, 6:15 am**

@jcfp ... thank you for the clarification and confirmation.

FWIW:

The full output of testssl.sh on ssl.astraweb.com, which takes about 30 minutes, and which shows a mishmash of SSL/TLS setup for the different ssl.astraweb.com machines ... :-(

sander@haring:~/git/testssl.sh$ ./testssl.sh ssl.astraweb.com:563 > result-of-ssl.astraweb.com.txt

sander@haring:~/git/testssl.sh$ cat result-of-ssl.astraweb.com.txt | grep -i -A7 -e "testing protocols" -e Start | grep -vi -e further -e rDNS -e skipping -e SPDY | grep -vi "^$"
Start 2017-08-29 16:32:17 -->> 207.246.207.131:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:36:24 -->> 207.246.207.127:563 (ssl.astraweb.com) <<--
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:39:17 -->> 216.151.153.13:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
--
Start 2017-08-29 16:44:00 -->> 8.17.249.103:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:47:41 -->> 216.151.153.132:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:50:57 -->> 216.151.153.76:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 not offered
TLS 1.2 not offered
--
Start 2017-08-29 16:54:42 -->> 216.151.153.11:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
--
Start 2017-08-29 16:59:33 -->> 207.246.207.13:563 (ssl.astraweb.com) <<--
SSLv2 offered (NOT ok), also VULNERABLE to DROWN attack -- 7 ciphers
SSLv3 offered (NOT ok)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
sander@haring:~/git/testssl.sh$

Posted: **August 30th, 2017, 8:46 am**

... and ssl-test.astraweb.com indeed looks much better and cleaner: no SSL, all TLS version, including TLS1.2:

Code: Select all

sander@haring:~/git/testssl.sh$ ./testssl.sh -p --color 0 ssl-test.astraweb.com:563   | grep -e Start -e " SSL" -e " TLS"

 Start 2017-08-30 15:45:16        -->> 193.202.122.156:563 (ssl-test.astraweb.com) <<--

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered
 TLS 1.1    offered
 TLS 1.2    offered (OK)

and sabnzbd.log confirms TLS1.2:

Code: Select all

2017-08-30 17:41:20,471::INFO::[newswrapper:228] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,701::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,717::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,731::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,745::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,764::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,778::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,811::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)
2017-08-30 17:42:34,820::INFO::[newswrapper:122] [email protected]: Connected using TLSv1.2 (ECDHE-RSA-AES256-GCM-SHA384)

HTH

SABnzbd Forums

SSL unsupported protocol (Astraweb, Debian Testing)

SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)

Re: SSL unsupported protocol (Astraweb, Debian Testing)