Missing support for HTTP/2 ?
list Ingeborg Hellemo
I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ? /#curl --head https://<servername>/ HTTP/2 200 cache-control: private content-length: 4423 content-type: text/html strict-transport-security: max-age=31536000 date: Wed, 01 Nov 2023 13:15:44 GMT --Ingeborg -- Ingeborg ?strem Hellemo -- user-10370b7b8dde@xymon.invalid Dep. of Information Technology --- Univ. of Troms?
list Tom Schmidt
Ingeborg,
HTTP/2 support is currently not in xymon, including in the 4.4alpha1
development tree. I did a little testing, and sites like google that
support HTTP/2 still pass the xymonnet checks as seen below:
$ curl --head https://www.google.com | head -1
HTTP/2 200
$ grep google ~/server/etc/hosts.cfg
0.0.0.0 www.google.com # conn https://www.google.com/
$ ~/server/bin/xymonnet --no-update www.google.com |grep -B2 HTTP
&green https://www.google.com/ - OK
HTTP/1.1 200 OK
$ ~/server/bin/xymonnet --no-update www.google.com |grep -i ssl
status+30 www,google,com.sslcert green Wed Nov 1 08:38:21 2023
&green SSL certificate for https://www.google.com/ expires in 2252 days
Perhaps the website you are testing is configured to support HTTP/2 and not
support HTTP/1? Try running the xymonnet command manually similar to what
I did here.
Tom Schmidt
On Wed, Nov 1, 2023 at 7:28?AM Ingeborg Hellemo via Xymon <xymon at xymon.com>
wrote:
---------- Forwarded message ---------- From: Ingeborg Hellemo <user-10370b7b8dde@xymon.invalid> To: xymon at xymon.com Cc: Bcc: Date: Wed, 01 Nov 2023 14:21:04 +0100 Subject: Missing support for HTTP/2 ?
▸
I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ? /#curl --head https://<servername>/ HTTP/2 200 cache-control: private content-length: 4423 content-type: text/html strict-transport-security: max-age=31536000 date: Wed, 01 Nov 2023 13:15:44 GMT --Ingeborg -- Ingeborg ?strem Hellemo -- user-10370b7b8dde@xymon.invalid Dep. of Information Technology --- Univ. of Troms?
---------- Forwarded message ----------
From: Ingeborg Hellemo via Xymon <xymon at xymon.com>
To: xymon at xymon.com
Cc:
Bcc:
Date: Wed, 01 Nov 2023 14:21:04 +0100
Subject: [Xymon] Missing support for HTTP/2 ?
list Axel Beckert
Hi,
▸
On Wed, Nov 01, 2023 at 02:21:04PM +0100, Ingeborg Hellemo via Xymon wrote:I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ?
I don't think so. It's probably more an issue of incompatible ciphers or so. Or is that an HTTP/2-only server? So far I'm also not aware of any HTTP/2 only (production) web server. Maybe this will come in the future. But yeah, as far as I know, xymonnet does not support HTTP/2 ? nor HTTP/3. Then again, it might be possible to implement a minimal client via protocols.cfg hex syntax like with e.g. ajp13 or rdp. But if the handshake needs anything outside the standard TLS handshake (and I'm not that versed in HTTP/2), it will not work. And indeed, builtin xymonnet support for HTTP/2 and HTTP/3 would be nice, especially if you could monitor the availability of protocol versions separately (like for HTTPS and HTTP). But I suspect this would need an 3rd party library like curl or nghttp2 to be used. Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Rod
It could be the SSL cert. Or it could be the intermediate certificates. Try running openssl verify -CAfile <location_of_intermediate_cert> /etc/apache2/<server.crt> (or whatever you named it)
▸
On Wed, Nov 1, 2023 at 10:53?AM Axel Beckert <user-bc188e45dae4@xymon.invalid> wrote:
Hi, On Wed, Nov 01, 2023 at 02:21:04PM +0100, Ingeborg Hellemo via Xymon wrote:I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ?I don't think so. It's probably more an issue of incompatible ciphers or so. Or is that an HTTP/2-only server? So far I'm also not aware of any HTTP/2 only (production) web server. Maybe this will come in the future. But yeah, as far as I know, xymonnet does not support HTTP/2 ? nor HTTP/3. Then again, it might be possible to implement a minimal client via protocols.cfg hex syntax like with e.g. ajp13 or rdp. But if the handshake needs anything outside the standard TLS handshake (and I'm not that versed in HTTP/2), it will not work. And indeed, builtin xymonnet support for HTTP/2 and HTTP/3 would be nice, especially if you could monitor the availability of protocol versions separately (like for HTTPS and HTTP). But I suspect this would need an 3rd party library like curl or nghttp2 to be used. Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Axel Beckert
Hi Rod,
▸
On Wed, Nov 01, 2023 at 11:47:37AM -0400, Rod wrote:On Wed, Nov 01, 2023 at 02:21:04PM +0100, Ingeborg Hellemo via Xymon wrote:I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ?It could be the SSL cert. Or it could be the intermediate certificates.
No. Xymon's SSL checks only check functionality over SSL and expiry dates. They do not verify the certificate chain.
▸
Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Japheth Cleaver
▸
On Wed, November 1, 2023 07:53, Axel Beckert wrote:
Hi, On Wed, Nov 01, 2023 at 02:21:04PM +0100, Ingeborg Hellemo via Xymon wrote:I have a webserver which works ok when you visit it in a browser or when you use curl, but Xymon http test shows "SSL error". Tests with "openssl s_client" from the command line works as expected. Could the culprit be that xymonnet does not support HTTP/2 ?I don't think so. It's probably more an issue of incompatible ciphers or so. Or is that an HTTP/2-only server? So far I'm also not aware of any HTTP/2 only (production) web server. Maybe this will come in the future. But yeah, as far as I know, xymonnet does not support HTTP/2 ??? nor HTTP/3. Then again, it might be possible to implement a minimal client via protocols.cfg hex syntax like with e.g. ajp13 or rdp. But if the handshake needs anything outside the standard TLS handshake (and I'm not that versed in HTTP/2), it will not work. And indeed, builtin xymonnet support for HTTP/2 and HTTP/3 would be nice, especially if you could monitor the availability of protocol versions separately (like for HTTPS and HTTP). But I suspect this would need an 3rd party library like curl or nghttp2 to be used.
A basic http/2 check really would be useful, but agreed I wouldn't want to add in another library unless, like with openldap, it's just too complex to do otherwise. I haven't looked into the binary header packing involved too much. This was another backburnered item on the list, but if there's demand for /2 testing specifically then it should be bumped up. -jc
list Ingeborg Hellemo
user-d34f6118b459@xymon.invalid said:
▸
HTTP/2 support is currently not in xymon, including in the 4.4alpha1 development tree. I did a little testing, and sites like google that support HTTP/2 still pass the xymonnet checks as seen below:
As you pointed out HTTP/2 is not part of the equation. (We turned it off completely on the server just to be sure). But I'm not any closer to resolving the issue. As I said, webpage in browser - no errors, curl - no errors, 'openssl s_client' no errors. ~/server/bin/xymonnet --debug --no-update <servername> 35422 2023-11-08 13:06:06.168385 1 status messages merged into 1 transmissions Address=[IP]:443, open=1, res=0, err=5, connecttime=0.000303, totaltime=0.002631, httpstatus = -5, open=1, errcode=5, parsestatus=0 Response: (no headers) URL : https://<servername>/ HTTP status : -5 HTTP headers (NULL) HTTP output (NULL) Any ideas?
▸
--Ingeborg
--
Ingeborg ?strem Hellemo -- user-10370b7b8dde@xymon.invalid
Dep. of Information Technology --- Univ. of Troms?
list Jeremy Laidman
On Wed, 8 Nov 2023 at 23:14, Ingeborg Hellemo via Xymon <xymon at xymon.com>
▸
wrote:
~/server/bin/xymonnet --debug --no-update <servername> 35422 2023-11-08 13:06:06.168385 1 status messages merged into 1 transmissions Address=[IP]:443, open=1, res=0, err=5, connecttime=0.000303, totaltime=0.002631, httpstatus = -5, open=1, errcode=5, parsestatus=0 Response: (no headers) URL : https://<servername>/ HTTP status : -5
I'm surprised there isn't some kind of error message being displayed. err=5
is "CONTEST_ESSL" meaning something went wrong in the SSL comms, or setup.
In most cases where the error code is set to CONTEST_ESSL, there's an
"errprintf()" that describes the error. I'd have thought "--debug" would
show these on STDERR.
The missing error message is likely going to help narrow down the problem.
These are all of the error messages in contest.c where err is set to
CONTEST_ESSL:
errprintf("SSL test, but xymonnet was built without SSL support\n");
errprintf("Failed to find enough entropy on your system");
errprintf("Cannot create SSL context - IP %s, service %s: %s\n",
inet_ntoa(item->addr.sin_addr),
item->svcinfo->svcname, sslerrmsg);
errprintf("Cannot load SSL client certificate/key %s: %s\n",
item->ssloptions->clientcert, sslerrmsg);
errprintf("SSL_new failed - IP %s, service %s: %s\n",
inet_ntoa(item->addr.sin_addr),
item->svcinfo->svcname, sslerrmsg);
errprintf("Private/public key mismatch for certificate %s\n",
item->ssloptions->clientcert);
errprintf("Could not initiate SSL on connection - IP %s, service %s: %s\n",
inet_ntoa(item->addr.sin_addr),
item->svcinfo->svcname, sslerrmsg);
errprintf("IO error in SSL_connect to %s on host %s: %s\n",
portinfo, inet_ntoa(item->addr.sin_addr),
sslerrmsg);
errprintf("Unspecified SSL error in SSL_connect to %s on host %s: %s\n",
portinfo, inet_ntoa(item->addr.sin_addr),
sslerrmsg);
errprintf("Unknown error %d in SSL_connect to %s on host %s: %s\n",
err, portinfo,
inet_ntoa(item->addr.sin_addr), sslerrmsg);
errprintf("Cannot get peer certificate for %s on host %s\n",
portinfo, inet_ntoa(item->addr.sin_addr));
Perhaps these can give you some clues about what might be going wrong.
I also suggest taking a look at the webserver logs for any errors, warnings
or notice messages associated with the xymonnet connection.
J
list Uffe R. B. Andersen
▸
On 2023-11-08 13:14, Ingeborg Hellemo via Xymon wrote:
user-d34f6118b459@xymon.invalid said:HTTP/2 support is currently not in xymon, including in the 4.4alpha1 development tree. I did a little testing, and sites like google that support HTTP/2 still pass the xymonnet checks as seen below:As you pointed out HTTP/2 is not part of the equation. (We turned it off completely on the server just to be sure). But I'm not any closer to resolving the issue. As I said, webpage in browser - no errors, curl - no errors, 'openssl s_client' no errors. ~/server/bin/xymonnet --debug --no-update <servername> 35422 2023-11-08 13:06:06.168385 1 status messages merged into 1 transmissions Address=[IP]:443, open=1, res=0, err=5, connecttime=0.000303, totaltime=0.002631, httpstatus = -5, open=1, errcode=5, parsestatus=0 Response: (no headers) URL : https://<servername>/ HTTP status : -5 HTTP headers (NULL) HTTP output (NULL) Any ideas?
Anything in your xymonnet.log file? I just got the same error, after upgrading my xymon server from FreeBSD 13.2 to 14.0. Turns out that OpenSSl 3.0, which is included in FreeBSD 14.0 doesn't support TLS 1.0 out-of-the-box. My old switches only support TLS 1.0. The xymonnet.log have these entries: 2023-12-15 21:03:49.454627 Unspecified SSL error in SSL_connect to https (47873/tcp) on host 192.168.1x1.2x3: error:0A000152:SSL routines::unsafe legacy renegotiation disabled Of course, if your test tools use the same OpenSSL library as xymon, they ought fail as well, but it sounds like an incompatible cipher issue. -- Med venlig hilsen - Sincerely Uffe R. B. Andersen - mailto:user-723fdd193aaa@xymon.invalid http://blog.andersen.nu/
list Ingeborg Hellemo
xymon at xymon.com said:
▸
Anything in your xymonnet.log file? I just got the same error, after upgrading my xymon server from FreeBSD 13.2 to 14.0. Turns out that OpenSSl 3.0, which is included in FreeBSD 14.0 doesn't support TLS 1.0 out-of-the-box. My old switches only support TLS 1.0.
Nothing in xymonnet.log. TLS version is not the issue. (Well, yes the server offers deprecated TLS versions, but this has never thrown xymon-errors before)
Just ran testssl.sh and things seem normal:
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered (deprecated)
TLS 1.1 offered (deprecated)
TLS 1.2 offered (OK)
TLS 1.3 offered (OK): final
NPN/SPDY not offered
ALPN/HTTP2 not offered
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK)
Triple DES Ciphers / IDEA not offered
Obsolete CBC ciphers (AES, ARIA etc.) offered
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) TLS_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA TLS_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA Elliptic curves offered: prime256v1 secp384r1 X25519
Testing server preferences
Has server cipher order? yes (OK) -- TLS 1.3 and below
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Cipher order
TLSv1: ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA TLSv1.1: ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA TLSv1.2: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA
TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256
Testing server defaults (Server Hello)
TLS extensions (standard) "status request/#5" "renegotiation info/#65281" "server name/#0" "supported versions/#43" "key share/#51" "extended master secret/#23"
Session Ticket RFC 5077 hint no -- no lifetime advertised
SSL Session ID support yes
Session Resumption Tickets no, ID: no
TLS clock skew 0 sec from localtime
Signature Algorithm ECDSA with SHA256
Server key size EC 256 bits
Server key usage Digital Signature
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial E665ABF3E5755447429FF75312C192DF (OK: length 16)
Fingerprints SHA1 AEED932E3A8A750A5D12ACC9E8A265FBFBAAFCE3
SHA256 F54A156CD0BDBC06479BB4497CA09E1BC1D771D4E6
DC78542EB4E701163F0415
Common Name (CN) removed (request w/o SNI didn't succeed, usual for EC certificates)
subjectAltName (SAN) removed Issuer GEANT OV ECC CA 4 (GEANT Vereniging from NL)
Trust (hostname) Ok via SAN (SNI mandatory)
Chain of trust Ok EV cert (experimental) no ETS/"eTLS", visibility info not present
Certificate Validity (UTC) expires < 60 days (50) (2023-02-06 00:00 --> 2024-02-06 23:59)
# of certificates provided 3
Certificate Revocation List http://GEANT.crl.sectigo.com/GEANTOVECCCA4.crl
OCSP URI http://GEANT.ocsp.sectigo.com
OCSP stapling offered, not revoked
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)
Testing HTTP header response @ "/"
HTTP Status Code 200 OK
HTTP clock skew 0 sec from localtime
Strict Transport Security 365 days=31536000 s, just this domain
Public Key Pinning --
Server banner (no "Server" line in header, interesting!)
Application banner --
Cookie(s) (none issued at "/")
Security headers Cache-Control: private
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (RFC 5746) OpenSSL handshake didn't succeed
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) potentially NOT ok, "gzip" HTTP compression detected. - only supplied "/" tested
Can be ignored for static pages or if no secrets in the page
POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 support
TLS_FALLBACK_SCSV (RFC 7507) Rerun including POODLE SSL check. Downgrade attack prevention NOT supported
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
no RSA certificate, thus certificate can't be used with SSLv2 elsewhere
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
BEAST (CVE-2011-3389) TLS1: ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA
VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated)
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC)
x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384
xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 384 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 384 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
xc00a ECDHE-ECDSA-AES256-SHA ECDH 384 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256
xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
Running client simulations (HTTP) via sockets
Android 6.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 7.0 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
Android 8.1 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
Android 9.0 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Android 10.0 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Android 11 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Android 12 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Chrome 79 (Win 10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Chrome 101 (Win 10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Firefox 66 (Win 8.1/10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Firefox 100 (Win 10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
IE 6 XP No connection
IE 8 Win 7 TLSv1.0 ECDHE-ECDSA-AES256-SHA, 384 bit ECDH (P-384)
IE 8 XP No connection
IE 11 Win 7 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
IE 11 Win 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
IE 11 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
Edge 15 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
Edge 101 Win 10 21H2 TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Safari 12.1 (iOS 12.2) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Safari 13.0 (macOS 10.14.6) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Safari 15.4 (macOS 12.3.1) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Java 7u25 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256)
Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
Java 11.0.2 (OpenJDK) TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
Java 17.0.3 (OpenJDK) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
go 1.17.8 TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
LibreSSL 2.8.3 (Apple) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
OpenSSL 1.1.0l (Debian) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
OpenSSL 1.1.1d (Debian) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
OpenSSL 3.0.3 (git) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)
Apple Mail (16.0) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
Thunderbird (91.9) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)