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.
See #1429.
OpenBSD 6.6 had an offset with the HTTP header time of -3600 seconds.
This PR fixes that by adding the GMT time zone to parse_date()'s
HAS_FREEBSDDATE incarnation. That doesn't matter to FreeBSD.
Also now for older OpenBSDs the local and remote time are now
in the same format:
```
HTTP clock skew remote: Thu, 09 Jan 2020 12:52:32 GMT
local: Thu, 09 Jan 2020 12:52:02 GMT
``
so that a time difference is easier to spot.
OpenBSD's grep seems to interpret "-w <EXPR>:" differently
than Linux or MacOSX/FreeBSD in a sense that this doesn't
matchs, see #1430.
This PR fixes that by squashing the w option in all occuorrences.
In addition it removes the SOCKETHEADER if-statement which was
introduced looking forward a while back. It's not happening soon
at least and the variable was not initialized either.
... and reorder manpages also so that --warnings, --connect-timeout
and --openssl-timeout appear in the "input parameter" section.
The HTML manpage looks in the diff view quite different as previously
another computer was used for converting the source format with ronn(1).
The manpage in (g)roff format was manually edited with .RE / .RS
for provide indented bulletpoints.
See also #1419
* It'll be a warning now when a host certificate was issued after
March 1st, 2018 which has a lifetime >825 days, independent
whether it is an internal certificate or not. This can
change later, as browsers treat those certificates different
as "official ones"
* Still the 5 or 10 year threshold overrides this
* For older OpenBSDs there's now a better date format support
used in the expiration and validity period of a host certificate.
It mimics in bash the conversion of other date binaries. It is
not accurate so it might be off a day or at maximum two, probably
as a month has 30.42 days and not 30.
* The date output for OpenBSD is now in line with other OS. Previously
we just echoed the lines in openssl x509 output whereas now we
convert that
The expression 'grep -aw "Public-Key:"' hiccuped on the colon
under OpenBSD, so that any bitsize on a certificate had wrong
values, see #1425. (FreeBSD was fine)
This PR fixes that. It updates the expression by using awk and
bash internal functions.
The same problem occured in run_robot(). The strong typing of
pubkeybits had to be relaxed to a dynamic typing, unless we
choose to define a second string variable.
* old OpenBSD kinda works
* let's encrypt section moved so that OpenBSD can use it too
* Days are wrong
* Date format is not the same as with e.g. GNUdate (but should be)
* variables y m d not declared
* date warning for openbsd completely missing
As noted in #1418 LLMNR (Link-Local Multicast Name Resolution)
resolution times out when using x as an argument to "-connect".
This commit fixes that by replacing "-connect x" by "-connect invalid."
which is supposedly also generally more "DNS query friendly", see
https://tools.ietf.org/html/rfc6761#section-6.4 .
In addition this commit adds a check in get_common_prime() whether
the openssl version used has pkey support. If not with old openssl
versions and previously testssl.sh terminated after presenting garbledoutput.
(This was found as tested how very old version of openssl versions
handle "-connect invalid.")
If the server is known not to support TLS 1.3 (as well as TLS 1.2, TLS 1.1, and TLS 1), then mention TLS 1.3 in the list of not supported protocols. While lack of TLS 1.3 support is not part of the reason that no fallback is possible, it is part of the reason that the result is reported as prln_svrty_high.
If $high_proto is set to something other than SSLv3, support for SSLv3 will not have been determined by determine_optimal_sockets_params(), but it may have been determined later (e.g., by run_protocols()). So, this commit changes the loop to always check for SSLv3 support (without calling "$OPENSSL s_client" if $HAS_SSL3 is false). The check for whether the fallback test can be performed is moved until after the loop
This PR fixes a couple of places where "$OPENSSL s_client" is called with "-ssl3" even if SSLv3 is not supported.
The fix in ciphers_by_strength() is easy, as the issue only occurs if "$using_sockets" is true. If SSLv3 (or TLSv1.3) is not supported, then testing using "$OPENSSL s_client" is skipped and all of the supported ciphers are found using tls_sockets().
The fix for run_tls_fallback_scsv() is more complicated. While it is easy to avoid calling "$OPENSSL s_client" with "-ssl3" if SSLv3 is not supported, it is not easy to determine the correct message to present to the user if support for SSLv3 (and possibly also TLSv1.3) is unknown.
For the case in which $high_proto cannot be set, I believe that I have covered all of the possibilities, but an not sure if the correct message/rating is used in every case.
For the case in which it is not possible to determine whether SSLv3 is the $low_proto, more could be done. If $high_proto is TLS 1.1 or TLS 1, then this PR is okay, as it is possible that SSLv3 would be the fallback protocol, but there is no way to tell. However, it seems unlikely that a server would support TLS 1.2 and SSLv3, but not TLS 1.1 or TLS 1. So, perhaps if $high_proto is TLS 1.2 and the server does not support TLS 1.1 or TLS 1, it should just be assumed that SSLv3 is not supported, even if it cannot be tested.
At the moment, testssl.sh does not correctly derive the handshake traffic keys in the case that the server responds to the initial ClientHello with a HelloRetryRequest. The handshake traffic keys are computed incorrectly because the wrong messages are provided to derive-handshake-traffic-keys() for input to the Transcript-Hash calculation:
* TLS_CLIENT_HELLO is not updated to contain the value of the second ClientHello, and so the first ClientHello is being provided to derive-handshake-traffic-keys() as both the first and the second ClientHello.
* In middlebox compatibility mode the server may send a dummy ChangeCipherSpec message immediately after the HelloRetryRequest. Since it is part of the server's response to the initial ClientHello, the ChangeCipherSpec message is included in the $hrr that is sent to derive-handshake-traffic-keys(), but it should not be included in the computation of the Transcript-Hash.
This PR fixes the above two problems by updating TLS_CLIENT_HELLO when a second ClientHello is sent and by removing any ChangeCipherSpec message (140303000101) from the end of the server's initial response.
* Severity of RC4 in run_cipherlists() is now high as everywhere else
* Same for RC2 and DES. Only Export, NULL and ADH remain critical
* 3DES and IDEA in run_cipherlists() is now medium (see #1393)
* CBC3 SEED 3DES IDEA added in pr_cipher_quality()
* MD5 added to pr_cipher_quality() and labled as high
* double RC2 switch statemnet removed in pr_cipher_quality()
Dirk Wetter
Fabrice Bacchella
Vitalii Tverdokhlib
David Cooper