[possible BUG] TLSv1.0/1.1 connection reported although not available about testssl.sh HOT 4 CLOSED

Those functions are pretty solid.

Looking at it, it seems a case of "works for me" but can't tell at a first glance why.

prompt> curl -Iiv --tlsv1.1 https://example.com   

*   Trying 2606:2800:220:1:248:1893:25c8:1946:443...
* Connected to example.com (2606:2800:220:1:248:1893:25c8:1946) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Los Angeles; O=Internet�Corporation�for�Assigned�Names�and�Numbers; CN=www.example.org
*  start date: Mar 14 00:00:00 2022 GMT
*  expire date: Mar 14 23:59:59 2023 GMT
*  subjectAltName: host "example.com" matched cert's "example.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55fd079eacc0)
> HEAD / HTTP/2
> Host: example.com
> user-agent: curl/7.74.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
HTTP/2 200
< accept-ranges: bytes
accept-ranges: bytes
< age: 484229
age: 484229
< cache-control: max-age=604800
cache-control: max-age=604800
< content-type: text/html; charset=UTF-8
content-type: text/html; charset=UTF-8
< date: Tue, 25 Oct 2022 17:37:24 GMT
date: Tue, 25 Oct 2022 17:37:24 GMT
< etag: "3147526947"
etag: "3147526947"
< expires: Tue, 01 Nov 2022 17:37:24 GMT
expires: Tue, 01 Nov 2022 17:37:24 GMT
< last-modified: Thu, 17 Oct 2019 07:18:26 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
< server: ECS (nyb/1D1E)
server: ECS (nyb/1D1E)
< x-cache: HIT
x-cache: HIT
< content-length: 1256
content-length: 1256
prompt> 

prompt> curl -4 -Ii --tlsv1 https://example.com                                                                                                                      19:40:15

HTTP/2 200
content-encoding: gzip
accept-ranges: bytes
age: 452488
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
date: Tue, 25 Oct 2022 17:42:42 GMT
etag: "3147526947"
expires: Tue, 01 Nov 2022 17:42:42 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (nyb/1D2A)
x-cache: HIT
content-length: 648
prompt > 

prompt>  host example.com 
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 0 .
prompt>

(Same IP fro Europe and North America)

I cannot access 192.168.205.11 from here.

Sure your openssl is configured to allow TLS < 1.2 like CipherString = DEFAULT@SECLEVEL=0 in /etc/ssl/openssl.conf?

from testssl.sh.

I also believe the results from testssl.sh are correct. Looking at the documentation for curl, it describes the --tls1.1 option as follows:

Forces curl to use TLS version 1.1 or later when connecting to a remote TLS server.

In old versions of curl this option was documented to allow only TLS 1.1, but behavior was inconsistent depending on the TLS library.

So, curl -Iiv --tlsv1.1 --tls-max 1.1 https://example.com just results in a TLS 1.3 connection.

I don't know what you mean when you say "the connection works – obviouly because the server negotiates an upgrade." If the client sends a TLS 1.1 ClientHello, the TLS protocol does not allow for negotiating an upgrade.

As Dirk noted with OpenSSL, the version that ships with Ubuntu 20.04 disables TLS 1.0 and TLS 1.1 by default, which is the reason for the failed connection. Setting the security level to 0 will enable these protocol versions. For example:

openssl s_client -connect example.com:443 -tls1 -cipher ALL:@SECLEVEL=0

This worked for me, suggesting that TLS 1.0 is enabled.

from testssl.sh.

Apologies for the confusion caused by my use of the domain example.com. Since I was testing against a server in my LAN, I used that domain in this report just as an example domain. I did not really test against that domain.

Looking at the documentation for curl, it describes the --tls1.1 option as follows:

Forces curl to use TLS version 1.1 or later when connecting to a remote TLS server.
In old versions of curl this option was documented to allow only TLS 1.1, but behavior was inconsistent depending on the TLS library.

So, curl -Iiv --tlsv1.1 --tls-max 1.1 https://example.com just results in a TLS 1.3 connection.

That's not quite right. The above description refers to option --tlsv1.1 only. However, that's why I was also using the --tls-max 1.1 option (which you quote but did not use in your example). The option --tls-max 1.1 forbids to accept TLS versions above 1.1.

I don't know what you mean when you say "the connection works – obviouly because the server negotiates an upgrade." If the client sends a TLS 1.1 ClientHello, the TLS protocol does not allow for negotiating an upgrade.

That was just an assumption. I don't know much about the SSL handshake.

So the client is probably presenting TLS 1.1, 1.2, and maybe 1.3 as available (if I test without --tls-max), then the server selects 1.2, right?

As Dirk noted with OpenSSL, the version that ships with Ubuntu 20.04 disables TLS 1.0 and TLS 1.1 by default, which is the reason for the failed connection. Setting the security level to 0 will enable these protocol versions. For example:

openssl s_client -connect example.com:443 -tls1 -cipher ALL:@SECLEVEL=0

This worked for me, suggesting that TLS 1.0 is enabled.

As I used the docker for testssl.sh, I suppose that the openssl on my Ubuntu is not used, but the openssl that is configured in the docker container, isn't it?

I cannot provide access to the server in our LAN, but if there is anything else I can test on it, please advise.

from testssl.sh.

openssl s_client -connect example.com:443 -tls1 -cipher ALL:@SECLEVEL=0

This worked for me, suggesting that TLS 1.0 is enabled.

I'm sorry, I just realized what you were referring to with this! I tested it, and you are right. openssl s_client can connect.

So my report seems invalid.

from testssl.sh.