Increase performance by forcing a lower SSL encryption strength

[cphmichael]

Version: 3.0.0RC2 [aabb709]

In "Servers > SSL Ciphers" I have entered AES128-SHA, because I would like to:
* Increase performance by forcing a lower SSL encryption strength.

If I go to "Status and interface options > Connections" when SAB is downloading, it says under SSL:
* TLSv1.3 (TLS_AES_256_GCM_SHA384)

I have uploaded two screendump to Google Photo:

Servers > SSL Ciphers:
https://photos.app.goo.gl/xKSid1awPNiDEpm7A

Status and interface options > Connections:
https://photos.app.goo.gl/D8jM1qcBweyBJsNy8

[sander]

What if you fill out BLABLAXYZ as cipher, and try again?

BTW: I myself am not a fan of this feature

[cphmichael]

It still says "TLSv1.3 (TLS_AES_256_GCM_SHA384)"

The Test Server button says "Connection Successful!" with the BLABLAXYZ as cipher.

[sander]

So sab ignores that setting?

[cphmichael]

It seems so.

[sander]

When I fill out BLABLAXYZ as cipher, SAB tells me " ('No cipher can be selected.',)". So different than you

When I fill out AES128-SHA, SAB tells me "-[email protected]: Connected using TLSv1.3 (TLS_AES_256_GCM_SHA384)". So: I can reproduce that.

Weird.

[cphmichael]

As you can see on this screenshot I have setup NewsDemon and NewsgroupDirect:

https://photos.app.goo.gl/ejgYgGxkG4nra3HX9

I have setup both the US and the EU/NL server.

All 4 servers are setup equally and with AES128-SHA as SSL Ciphers.

As you can see the NewsDemon-EU shows:
* TLSv1.2 (AES128-SHA)

but the NewsDemon-US shows:
* TLSv1.3 (TLS_AES_256_GCM_SHA384)

When I change the SSL Ciphers to BLABLAXYZ for all 4 servers and click the "Test Server" button, the NewsDemon-EU says:
* [Errno 111] [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:852)

The 3 other servers (NewsDemon-US, NewsgroupDirect-NL, NewsgroupDirect-US) all says:
* Connection Successful!

It seems like it has something to do with the TLSv1.2 / TLSv1.3

[sander]

It seems like it has something to do with the TLSv1.2 / TLSv1.3

That was my thought too ... maybe with (python) TLS 1.3 you cannot specify the cipher ... ? Very long shot, but worth verifying. Or, less long shot: specifying the cipher must be done in a different way for TLS 1.3 and/or Python3?

Or: it works, but the reporting is incorrect ...

[sander]

I made a test program

Code: Select all

import socket, ssl
import pprint
import sys

context = ssl.create_default_context()
#cipher = 'DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-GCM-SHA256'
cipher = 'AES128-SHA'
context.set_ciphers(cipher)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
#domain = 'google.com'
domain = sys.argv[1]
try:
        port = int(sys.argv[2])
except:
        port = 443 # default HTTPS port

sslSocket = context.wrap_socket(s, server_hostname = domain)
sslSocket.connect((domain, port))
if False:
        pprint.pprint(context.get_ciphers())
for i in context.get_ciphers():
        print("\n",i)
print("\n\nsslSocket.cipher():", sslSocket.cipher())

sslSocket.close()
print('closed')

With google, AES128-SHA seems to be there, but the resulting connection is TLS_AES_256_GCM_SHA384

Code: Select all

$ python3 testje1.py google.nl 443

 {'id': 50336514, 'name': 'TLS_AES_256_GCM_SHA384', 'protocol': 'TLSv1.3', 'description': 'TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD', 'strength_bits': 256, 'alg_bits': 256, 'aead': True, 'symmetric': 'aes-256-gcm', 'digest': None, 'kea': 'kx-any', 'auth': 'auth-any'}
 {'id': 50336515, 'name': 'TLS_CHACHA20_POLY1305_SHA256', 'protocol': 'TLSv1.3', 'description': 'TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD', 'strength_bits': 256, 'alg_bits': 256, 'aead': True, 'symmetric': 'chacha20-poly1305', 'digest': None, 'kea': 'kx-any', 'auth': 'auth-any'}
 {'id': 50336513, 'name': 'TLS_AES_128_GCM_SHA256', 'protocol': 'TLSv1.3', 'description': 'TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD', 'strength_bits': 128, 'alg_bits': 128, 'aead': True, 'symmetric': 'aes-128-gcm', 'digest': None, 'kea': 'kx-any', 'auth': 'auth-any'}
 {'id': 50331695, 'name': 'AES128-SHA', 'protocol': 'SSLv3', 'description': 'AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1', 'strength_bits': 128, 'alg_bits': 128, 'aead': False, 'symmetric': 'aes-128-cbc', 'digest': 'sha1', 'kea': 'kx-rsa', 'auth': 'auth-rsa'}
sslSocket.cipher(): ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
closed

With eweka, also TLS1.3 is there, but connection is AES128-SHA is achieved:

Code: Select all

$ python3 testje1.py newsreader.eweka.nl 563

 {'id': 50336514, 'name': 'TLS_AES_256_GCM_SHA384', 'protocol': 'TLSv1.3', 'description': 'TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD', 'strength_bits': 256, 'alg_bits': 256, 'aead': True, 'symmetric': 'aes-256-gcm', 'digest': None, 'kea': 'kx-any', 'auth': 'auth-any'}

 {'id': 50336515, 'name': 'TLS_CHACHA20_POLY1305_SHA256', 'protocol': 'TLSv1.3', 'description': 'TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD', 'strength_bits': 256, 'alg_bits': 256, 'aead': True, 'symmetric': 'chacha20-poly1305', 'digest': None, 'kea': 'kx-any', 'auth': 'auth-any'}

 {'id': 50336513, 'name': 'TLS_AES_128_GCM_SHA256', 'protocol': 'TLSv1.3', 'description': 'TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD', 'strength_bits': 128, 'alg_bits': 128, 'aead': True, 'symmetric': 'aes-128-gcm', 'digest': None, 'kea': 'kx-any', 'auth': 'auth-any'}

 {'id': 50331695, 'name': 'AES128-SHA', 'protocol': 'SSLv3', 'description': 'AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1', 'strength_bits': 128, 'alg_bits': 128, 'aead': False, 'symmetric': 'aes-128-cbc', 'digest': 'sha1', 'kea': 'kx-rsa', 'auth': 'auth-rsa'}

sslSocket.cipher(): ('AES128-SHA', 'SSLv3', 128)
closed

Oh wait: eweka does not offer TLS1.3 at all. So that the above test method is not relevant.

[sander]

Testing without SAB and without Python ... seems to confirm: with TLS1.3 you cannot specify the cipher. At least: with openssl.

With TLS1.2 specified, the specified cipher is obeyed:

Code: Select all

sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'AES256-SHA' -connect us.newsdemon.com:563 -tls1_2  2>&1 | grep -i cipher
New, SSLv3, Cipher is AES256-SHA
    Cipher    : AES256-SHA

sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'AES128-SHA' -connect us.newsdemon.com:563 -tls1_2  2>&1 | grep -i cipher
New, SSLv3, Cipher is AES128-SHA
    Cipher    : AES128-SHA

sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'AES256-CCM8' -connect us.newsdemon.com:563 -tls1_2  2>&1 | grep -i cipher
New, TLSv1.2, Cipher is AES256-CCM8
    Cipher    : AES256-CCM8

sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'CAMELLIA256-SHA' -connect us.newsdemon.com:563 -tls1_2  2>&1 | grep -i cipher
New, SSLv3, Cipher is CAMELLIA256-SHA
    Cipher    : CAMELLIA256-SHA

With TLS1.3, the specified cipher is ignored:

Code: Select all

sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'CAMELLIA256-SHA' -connect us.newsdemon.com:563 -tls1_3  2>&1 | grep -i cipher
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'AES128-SHA' -connect us.newsdemon.com:563 -tls1_3  2>&1 | grep -i cipher
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
sander@witte2004:~$ echo "QUIT" | openssl s_client -cipher 'AES256-SHA' -connect us.newsdemon.com:563 -tls1_3  2>&1 | grep -i cipher
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

So: not a python / SABnzbd thing.

I don't know if it's a TLS1.3 thing, or a openssl thing.

[sander]

Using gnutls, it seems you can influence the cipher with TLS1.3. If so and if my method is correct, the problem is in openssl

Code: Select all

$ echo "quit" | gnutls-cli --verbose --priority SECURE128:-AES-256-GCM us.newsdemon.com:563 | grep -i -e cipher -e tls
			Key encipherment.
			TLS WWW Server.
			TLS WWW Client.
- Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(CHACHA20-POLY1305)
- Version: TLS1.3
- Cipher: CHACHA20-POLY1305
- Channel binding 'tls-unique': 
- Peer has closed the GnuTLS connection

[sander]

Interesting info on https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites

OpenSSL has implemented support for five TLSv1.3 ciphersuites as follows:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
Due to the major differences between the way that ciphersuites for TLSv1.2 and below and ciphersuites for TLSv1.3 work, they are configured in OpenSSL differently too.

By default the first three of the above ciphersuites are enabled by default. This means that if you have no explicit ciphersuite configuration then you will automatically use those three and will be able to negotiate TLSv1.3. Note that changing the TLSv1.2 and below cipher list has no impact on the TLSv1.3 ciphersuite configuration.

Applications should use the SSL_CTX_set_ciphersuites() or SSL_set_ciphersuites() functions to configure TLSv1.3 ciphersuites. Note that the functions SSL_CTX_get_ciphers() and SSL_get_ciphers() will return the full list of ciphersuites that have been configured for both TLSv1.2 and below and TLSv1.3.

For the OpenSSL command line applications there is a new "-ciphersuites" option to configure the TLSv1.3 ciphersuite list. This is just a simple colon (":") separated list of TLSv1.3 ciphersuite names in preference order. Note that you cannot use the special characters such as "+", "!", "-" etc, that you can for defining TLSv1.2 ciphersuites. In practice this is not likely to be a problem because there are only a very small number of TLSv1.3 ciphersuites.

For example:

$ openssl s_server -cert mycert.pem -key mykey.pem -cipher ECDHE -ciphersuites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

This will configure OpenSSL to use any ECDHE based ciphersuites for TLSv1.2 and below. For TLSv1.3 the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 ciphersuites will be available.

Note that all of the above applies to the "ciphers" command line application as well. This can sometimes lead to surprising results. For example this command:

$ openssl ciphers -s -v ECDHE

Will list all the ciphersuites for TLSv1.2 and below that support ECDHE and additionally all of the default TLSv1.3 ciphersuites. Use the "-ciphersuites" option to further configure the TLSv1.3 ciphersuites.

[sander]

Based on that info:

$ echo "QUIT" | openssl s_client -connect us.newsdemon.com:563 -tls1_3 2>&1 | grep -i cipher
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

$ echo "QUIT" | openssl s_client -ciphersuites "TLS_CHACHA20_POLY1305_SHA256" -connect us.newsdemon.com:563 -tls1_3 2>&1 | grep -i cipherNew, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256

That works! ... so for TLS1.3, openssl CLI version wants a different CLI option.



OK, now back to python:

At first glance at https://docs.python.org/3/library/ssl.html https://docs.python.org/3/library/ssl.html#tls-1-3 I found this:

TLS 1.3¶
New in version 3.7.

Python has provisional and experimental support for TLS 1.3 with OpenSSL 1.1.1. The new protocol behaves slightly differently than previous version of TLS/SSL. Some new TLS 1.3 features are not yet available.

TLS 1.3 uses a disjunct set of cipher suites. All AES-GCM and ChaCha20 cipher suites are enabled by default. The method SSLContext.set_ciphers() cannot enable or disable any TLS 1.3 ciphers yet, but SSLContext.get_ciphers() returns them.

Ah.... That explains all, doesn't it?

[sander]

TL;DR; with python openssl, you can not (yet) specifly the cipher for TLS1.3 connections.

[sander]

... and added to the wiki: https://sabnzbd.org/wiki/advanced/ssl-ciphers