to 1.1.0l and 1.1.1d. Seems that for the latter TLS 1.0 and 1.1
are disabled now, looking at the supported version extension.
However on the command line an s_client connect works. So
this commit need to be amended.
The ciphersuites string for Safari 13.0 ends with a colon (':'). which causes OpenSSL to reject the command line when client simulation testing is performed in --ssl-native mode. This PR fixes the problem by removing the trailing colon.
PR #1260 missed a 'current' line which caused an output problem.
I'd like to add round brackets to the displayed name so that we remember
what comes from wireshark and waht from SSLlabs
"protos" contained "-no-ssl3" instead of "-no_ssl3"
which lead to an error message "Oops: openssl s_client connect problem"
-- which wasn't caught by the STARTTLS unit test either :-(
While we are thankful that Ivan Ristic permitted to use the client
data from SSLlabs, it became of bit outdated now (see #1158). Also
as sslhaf [1] was used, the data comes from HTTP traffic only.
This is a start to address it. It provides data from Android 9
(connecting to the play store, so that it is sure we don't capture
a ClientHello from an application having an own TLS stack.
Also it provides documentation how to grab data yourself, and
provide it back to testssl.sh.
Aim is at least for testssl.sh 3.0 to add Android 8 and OpenSSL 1.1.1 (@drwetter).
My hope others can assist with Safari on OSX 11 and 12. Java 10 and 11,
and a recent Opera and Edge version. (Firefox and Chrome are out of
date too)
Mail clients to follow later.
[1] https://github.com/ssllabs/sslhaf
SSLabs API only added one newer version of Chrome (70) and one newer version
of Firefox (62).
Thus the wishlist gets longer (c15e0425dc).
Missing is Android 8 and 9, OpenSSL 1.1.1, Safari on OSX 11 and 12. Java 10
and 11.
Fix#1104
This is a fix for #722. It updates the client simulation data from
the SSLlabs API. As usual data was pulled, resorted and clients
to display were hand-selected.
Wishlist: Missing is Oreo, OpenSSL 1.1.1, Safari on OX 11, Firefox
52.x (ESR)
With the recent PR #1033 from @dcooper it can also show TLS 1.3
handshakes.
When performing client simulations in "--ssl-native" mode, provide the client's list of supported curves to "$OPENSSL s_client" in order to make the results even more accurate.
This PR improves client simulation in "--ssl-native" mode:
* It changes ${protos[i]} to list the protocols that should be disabled rather than those that should be enabled, except in the case that the client only supports one protocol.
* It sets the values for ${tlsvers[i]}, which is used in run_client_simulation(), but was not defined.
* It adds a new variable, ${ciphersuites[i]}, that lists the TLSv1.3 cipher suites supported by a client.
Client simulation still produces false results in "--ssl-native" mode, but the results are better than before.
In the data provided by https://api.dev.ssllabs.com/api/v3/getClients, Chrome 57 Win 7 and Firefox 53 Win 7 send ClientHellos that indicate support for TLSv1.3 draft 18, but the highest_protocol for each of these is specified as 0x0303. The result is that if the server being tested supports TLSV1.3 draft 18, `run_client_simulation()` will incorrectly report "No connection" for these servers since the DETECTED_TLS_VERSION (0x0304) will be higher than the specified highest_protocol.
This PR fixes the problem by changing the highest_protocol to 0x0304. Note that another solution to this problem would be to change the ClientHello messages for these two browsers. It is my understanding that TLSv1.3 is disabled by default for these browsers, so presumably the ClientHello messages would not specify TLSv1.3 support if they were configured with TLSv1.3 support disabled.
Christoph Settgast
David Cooper
Dirk Wetter
David Cooper