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.
According to MS this is the latest which is from July 2019.
This is the biggest CA store (probably a lot of intermediate
certificates in there).
This was pulled from MS as described in the Readme.md . It
is exactly the same whether CertUtil will be run from Windows 7
(almost: RIP) or Windows 10.
Other than before teh Java store was extracted directly from a keystore
from a Java JRE from https://jdk.java.net/.
The Debian keystore used previously used the certificates from the Debian
machine itself (installation script in ``/etc/ca-certificates/update.d/``.
Check with ``keytool -list -rfc -keystore /etc/ssl/certs/java/cacerts | grep -i 'alias'``
As a consequence this store contains less certificates:
etc/Java.pem:90
etc/Linux.pem:128
and needs some testing whether it really should be still included.
In some rare cases a server does not support any of the ciphers in $TLS12_CIPHER, but does support at least one cipher in $TLS12_CIPHER_2ND_TRY. In such cases, TLS12_CIPHER should be changed to $TLS12_CIPHER_2ND_TRY so that subsequent tests using $TLS12_CIPHER will succeed.
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
This is an update of the root certificate stores. Date from each store
is from yesterday.
Description update.
Also the Java certificate store was added. Previously Java was omitted
as it appeared not to be complete. I tested successfully this store.
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
There are a couple of old SSLv2 ciphers which haben't been included in
etc/cipher-mapping.txt . This PR updates the file. Names were derived
from the (old) OpenSSL / SSLeay source code.
In addition TLS_NULL_WITH_NULL_NULL (>=SSLv3 cipher) was added.
ToDo: Review functions to be updated to use those ciphers.
This commit removes the '0a' character from public keys used in the key_share extension. New key pairs were created by repeatedly generating new keys until one was found that had no '0a' characters in the public key.
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.
This PR fixes the issue raised in #1013. It primarily does this in two ways:
* In calls to `$OPENSSL s_client` that specify ciphers, the TLSv1.3 ciphers are provided separately using the `-ciphersuites` option. Then, the `s_client_options()` function manipulates the command-line options as necessary based on the version of OpenSSL being used.
* Calls to `$OPENSSL ciphers` were replaced with calls to `actually_supported_ciphers()`, which calls `$OPENSSL ciphers`. `actually_supported_ciphers()` modifies the parameters for the call to `$OPENSSL ciphers` as necessary, based on the version of OpenSSL being used.
Support for X448 was recently added to the development branch of OpenSSL 1.1.1. This PR adds an X448 key pair to etc/tls_data.txt (that was generated using OpenSSL 1.1.1) and adds X448 to the supported_groups extension for TLS 1.3 ClientHello messages.
This prime appears to be not only in HAProxy 1.5 but as well in the newer versions. The test result will return incorrect response message, when testing on the newer HAProxy versions (ie. 1.5 is detected but 1.8 is installed).
This PR adds support for TLSv1.3 to run_server_preference(). It only provides partial support, as it only works if the support supports and earlier TLS protocol (in order to determine whether the server has a cipher order). It also will only show TLSv1.3 as the "Negotiated protocol" if $OPENSSL supports TLSv1.3.
This PR also fixes a bug in which the variable "proto" was defined as used as both a regular variable and as an array.
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.
A PR was just accepted into the master branch of https://github.com/openssl/openssl that specifies OpenSSL names for the ARIA GCM cipher suites: bc32673869. This PR adds these OpenSSL names to the cipher-mapping.txt file. It also changes the description of the encryption algorithm for these ciphers from "ARIA" to "ARIAGCM" to be consistent with OpenSSL and with the other GCM ciphers in the cipher-mapping.txt file.
In addition, OpenSSL names for some of the ARIA CBC ciphers are provided in https://github.com/openssl/openssl/blob/master/doc/man1/ciphers.pod, and this PR adds those OpenSSL names to the cipher-mapping.txt file as well.
Update `$TLS12_CIPHER` to contain only 128 ciphers (so that it will work with servers that can't handle larger ClientHello messages), and also add some newer ciphers to `$TLS12_CIPHER`. Also define a `$TLS12_CIPHER_2ND_TRY` containing a list of 127 ciphers that do not appear in `$TLS12_CIPHER`. `$TLS12_CIPHER_2ND_TRY` is used in `run_protocols()` in order to perform a second test against servers that do not establish a TLSv1.2 connection when offered `$TLS12_CIPHER`.
