RE: Enumerating TLS protocol versions and ciphers supported by the peer

[Dr. Matthias St. Pierre]

> Look at 
> https://testssl.sh/

> That is an openssl wrapper which enumerates ciphers and protocols ( and a 
> whole lot more)

Nice tool, I didn’t know it yet. I was already recommended to me by Michael 
Wojcik in his  first reply, but thanks nevertheless for the link.
 
Matthias



smime.p7s
Description: S/MIME cryptographic signature

Re: Enumerating TLS protocol versions and ciphers supported by the peer

[Mark Hack]

Look at https://testssl.sh/
That is an openssl wrapper which enumerates ciphers and protocols ( and
a whole lot more)
Hexcode  Cipher Suite Name
(OpenSSL)   KeyExch.   Encryption  Bits Cipher Suite Name
(IANA/RFC)-

SSLv2  SSLv3  TLS 1  TLS 1.1  TLS 1.2   xc030   ECDHE-RSA-AES256-GCM-
SHA384   ECDH
521   AESGCM  256  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   
xc02f   ECDHE-RSA-AES128-GCM-SHA256   ECDH
521   AESGCM  128  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   
   TLS 1.3   x1302   TLS_AES_256_GCM_SHA384ECDH
521   AESGCM  256  TLS_AES_256_GCM_SHA384  
x1303   TLS_CHACHA20_POLY1305_SHA256  ECDH
521   ChaCha20256  TLS_CHACHA20_POLY1305_SHA256
x1301   TLS_AES_128_GCM_SHA256ECDH
521   AESGCM  128  TLS_AES_128_GCM_SHA256 

On Mon, 2021-12-06 at 15:06 +, Michael Wojcik wrote:
> > From: Dr. Matthias St. Pierre 
> > Sent: Monday, 6 December, 2021 07:53
> > To: Michael Wojcik ; openssl-
> > 
> > 
> > > "Comparable elegant" is underspecified.
> > 
> > (I guess, "Comparably elegant" would have been grammatically more
> > correct.)
> 
> I just meant that elegance is in the eye of the beholder.
> 
> Many people might agree that having a single command line return the
> list of what suites the server supports is elegant, at least for the
> user. Others prefer the original UNIX philosophy of simpler tools
> which are scripted to perform more complex operations; that's the
> testssl.sh approach, and it's more elegant in the sense of being
> composed in a visible (and modifiable) way from smaller pieces.
> 
> A command-line option to s_client to do this sort of server profiling
> is conceivable, but it would be a significant departure from what
> s_client does now, since it would conflict with some other options
> and would involve making multiple connections. That doesn't mean it
> shouldn't be implemented, necessarily, just that it's not parallel to
> most of the other things s_client options do.
> 
> -- 
> Michael Wojcik

Re: Enumerating TLS protocol versions and ciphers supported by the peer

[Hubert Kario]

On Monday, 6 December 2021 15:52:30 CET, Dr. Matthias St. Pierre wrote:



"Comparable elegant" is underspecified.


(I guess, "Comparably elegant" would have been grammatically more correct.)

Perhaps try testssl.sh (https://testssl.sh/)? It has various 
options for reducing the number and types of tests it runs. 
We've used it for

profiling internal TLS-enabled servers.


My question was mainly for educational purpose (since the 
'nmap' tool already satisfies my needs), but I wanted to know 
whether the openssl tool
can do same thing with a comparable effort. By this I mean a 
simple shell one-liner (or failing that just a few lines of 
shell script) utilizing `openssl s_client`.

Thanks for the weblink nevertheless.


No, it can't.

As what's necessary is to connect to server, note the used cipher,
exclude that cipher from ClientHello and see what is the next cipher that
server selects, repeat until connection rejected.
That's not simple to do in bash (for a way to do it look at 
mozilla/cipherscan)


The big problem is that this approach works only for ciphers supported and
enabled in openssl. If a cipher is unsupported by openssl, it will not be
detected as enabled on server side.
Given that there is no version of openssl that simultaneously supports 
SSLv2

and TLS 1.3, you can't reliably test arbitrary servers using openssl, even
if the server uses openssl too.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

RE: Enumerating TLS protocol versions and ciphers supported by the peer

[Michael Wojcik]

> From: Dr. Matthias St. Pierre 
> Sent: Monday, 6 December, 2021 07:53
> To: Michael Wojcik ; openssl-
> 
> 
> > "Comparable elegant" is underspecified.
> 
> (I guess, "Comparably elegant" would have been grammatically more
> correct.)

I just meant that elegance is in the eye of the beholder.

Many people might agree that having a single command line return the list of 
what suites the server supports is elegant, at least for the user. Others 
prefer the original UNIX philosophy of simpler tools which are scripted to 
perform more complex operations; that's the testssl.sh approach, and it's more 
elegant in the sense of being composed in a visible (and modifiable) way from 
smaller pieces.

A command-line option to s_client to do this sort of server profiling is 
conceivable, but it would be a significant departure from what s_client does 
now, since it would conflict with some other options and would involve making 
multiple connections. That doesn't mean it shouldn't be implemented, 
necessarily, just that it's not parallel to most of the other things s_client 
options do.

-- 
Michael Wojcik

RE: Enumerating TLS protocol versions and ciphers supported by the peer

[Dr. Matthias St. Pierre]

> "Comparable elegant" is underspecified.

(I guess, "Comparably elegant" would have been grammatically more correct.)

> Perhaps try testssl.sh (https://testssl.sh/)? It has various options for 
> reducing the number and types of tests it runs. We've used it for
> profiling internal TLS-enabled servers.

My question was mainly for educational purpose (since the 'nmap' tool already 
satisfies my needs), but I wanted to know whether the openssl tool
can do same thing with a comparable effort. By this I mean a simple shell 
one-liner (or failing that just a few lines of shell script) utilizing `openssl 
s_client`.
Thanks for the weblink nevertheless.


Matthias



smime.p7s
Description: S/MIME cryptographic signature

RE: Enumerating TLS protocol versions and ciphers supported by the peer

[Michael Wojcik]

From: openssl-users  On Behalf Of Dr. 
Matthias St. Pierre
Sent: Monday, 6 December, 2021 07:12


> today I learned that nmap has a nice feature to enumerate the protocol 
> versions and cipher
> suites supported by the peer (see below).
> Is there a comparable elegant way to obtain the same results using the 
> `openssl s_client`
> tool?

"Comparable elegant" is underspecified.

Perhaps try testssl.sh (https://testssl.sh/)? It has various options for 
reducing the number and types of tests it runs. We've used it for profiling 
internal TLS-enabled servers.

-- 
Michael Wojcik

Enumerating TLS protocol versions and ciphers supported by the peer

[Dr. Matthias St. Pierre]

Hi all,

today I learned that nmap has a nice feature to enumerate the protocol versions 
and cipher suites supported by the peer (see below).
Is there a comparable elegant way to obtain the same results using the `openssl 
s_client` tool?

Matthias


--

$ nmap -script ssl-enum-ciphers -p 443 www.openssl.org

Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-06 15:05 CET
Nmap scan report for www.openssl.org (96.16.136.61)
Host is up (0.0041s latency).
Other addresses for www.openssl.org (not scanned): 
2a02:26f0:1700:393::c1e 2a02:26f0:1700:380::c1e
rDNS record for 96.16.136.61: a96-16-136-61.deploy.static.akamaitechnologies.com

PORTSTATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|   TLSv1.1:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

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

smime.p7s
Description: S/MIME cryptographic signature