Review: grammar, spelling. Errorneous and obsolete description.
Some items reordered.
Updated: to reflect the current capabilities.
Moreover: (Almost) complete the tuning variables section.
This addresses #1169: When using JSON as output format when mass testing
AND we have a non-fatal condition when e.g. openssl lacks support for
something it led to an invalid JSON as the warning was put into file w/o
a trailing comma.
The commit removes the warning to be put into the output. We still have the
message on screen + in HTML which is not as optimal as it could be.
Also I did some cleanups related to redundant double quotes I stumbled over while
fixing this.
As a kind of a pre-warning this commit allows the n-1 connection problem to
give feedback on the screen (that wasn't working before).
Also the message on the screen is now more clear and the manpage
gives better advice.
Related to #1172
This PR fixes#1165 by changing resend_if_hello_retry_request() to modify the initial ClientHello rather than having it call prepare_tls_clienthello() to try to generate a new ClientHello that is almost the same as the first. The modification is done using a revised version of create_client_simulation_tls_clienthello(), which is now renamed as modify_clienthello().
Since prepare_tls_clienthello() is no longer used to create a second ClientHello message, argument 7 to that function is no longer needed.
There is at least one extension that will fail on a TLSv1.3 ClientHello if the psk_key_exchange_modes extension is not present (see #990). The PR adds the extension to TLSv1.3 ClientHello messages. OpenSSL, Firefox, and Chrome all include this extension in their ClientHello messages, so including it is unlikely to cause problems for any servers.
.. after some discussion. As TLS 1.3 is not tested here
any RFC 7919 primes using this protocol will not show
up (they in in run_pfs() though). To avoid misunderstandings
" DH key detected with <= TLS 1.2" is now being printed.
This PR provides an additional fix for the issue raised by #1159. It defines a third option for the degree of processing that should be performed by tls_sockets(): "all+". When "all+" is provided, the processing is exactly the same as for "all" with the exception of the creation of the supported_groups extension. For a TLSv1.3 ClientHello, curves that are not supported by $OPENSSL are omitted from the supported_groups extension rather than offering these curves as the least preferred option.
The "all+" option is used in run_server_defaults() where, unlike with almost every other call to tls_sockets(), a successful connection is of no use unless the response can be decrypted. This is also the case for run_alpn(), and so the call to tls_sockets() was also changed to "all+" there. But, the change has no effect at the moment, since run_alpn() sends a TLSv1.2 ClientHello.
As a result of #276, `run_server_defaults()` makes several attempts to find certificates that a server offers if the ClientHello is for TLSv1.2 and no SNI is offered. However, these tests are unnecessary if it is already known that the server does not support TLSv1.1.
This PR modifies `run_server_defaults()` so that the the TLSv1.1-only tests are skipped if the server is known to not support TLSv1.1.
This PR fixes#1159. If tls_sockets() connects to a server using TLSv1.3, it cannot be assumed that the server's certificate is available, as testssl.sh may not have been able to decrypt the server's response. This can happen, for example, if X25519 was used for the key exchange and `$OPENSSL` does not support X25519.
If the connection was successful, but the certificate could not be obtained, then this PR tries again using `$OPENSSL`. However, since `$OPENSSL` does not support TLSv1.3, this will only work if the server supports TLSv1.2 or earlier.
This commit addresses #179 and implements NNTP via STARTTLS. I did
a few tests and it did work so far.
However the binary support needs to be done. I backported in my
fork of @PeterMosmans tree the section from OpenSSL 1.1.1 -- but
it didn't work, see https://github.com/openssl/openssl/issues/7722.
I just tried to patch it as I suggested and it worked then. My
patch is pushed soon after to https://github.com/drwetter/openssl-1.0.2.bad,
however I'll better wait for the official OPenSSL 1.1.1 patch.
This commit finalizes #1139. It displays the DH groups
in both run_logjam() and run_pfs() in a simlilar manner
(except the FFDHE groups).
A common small function pr_dh() was introduced which prints
out the dh group and in round brackets colored DH bits.
This commit finally fixes#547 and makes XMPP handshakes at least
as fast as the other STARTTLS handshakes.
It utilizes dd to read from the file descriptor. In all tests
I ran so far it didn't cause any problems. There's a potential
problem though that dd might block.
This PR fixes#924 and does some foundation for #547. It's a
somewhat preliminary push of code and further work for #547 is required.
XMPP is now similar programmed as other STARTTLS handshakes with the exception
that it is not line based but stream based. That is still the catch here and
needs to be addressed: STARTTLS protocols like IMAP + SMTP use
starttls_full_read() which reads lines until the line is completely received or
the timeout was encountered.
The new function ``starttls_io()`` however does a wait (fixed value: 1 second)
as there's no lf or terminator.
The XMPP STARTTLS handshakes are now the same as in OpenSSL.
There are redundant functions in this code which will be removed later.
Also at some places a hint for lmtp was missing which was added.
The cipher suites names in the RFCs stem (mostly) from IANA, see
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
This PR corrects that in places visible to the user. For backwards
compatibility the cmd line switches still work as before, but there's
a preference to IANA. The RFC naming is labeled as to be retired
in the future.
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
In addition to 7d36ba9a2e which
added new SSLv2 ciphers to the ciphers file this commit adds those
ciphers also to those functions where needed.
Also it does some housekeeping. [[ doesn't require strings on
the right hand side to be quoted, see bash hackers wiki.
PR #1114 brought #1139 a good step forward. This commit adds
a few tweaks to it:
* the groups in run_pfs() are now also italic, except FFDHE groups
* renaming FF groups to DH groups to provide consistency with the
remainder of testssl.sh
* JSON identifier was renamed from DHE_groups to DH_GROUPS
Open points:
* in run_logjam() there's no warning at all regarding e.g. dh512.badssl.com.
Reading the Logjam paper in section 3.5., first couple of paragraphs we
should warn at least against 512 bits here too.
* how do we treat/label 768 bit and 1024 bit in run_logjam() which comes from
unknown groups? Looks like the paper only was concerned about precompuation.
* In run_logjam() is the bit length not colored but in run_pfs() it is.
* Notation: when do we label FF groups / DH parameter ephemeral?
* Code in run_pfs() and run_logjam() can be merged more.
run_logjam() is only related to TLSv1.2 and earlier ciphers. So, run_pfs() should only update $DH_GROUP_OFFERED if a DH group was found using a non-TLSv1.3 cipher.
On the other side, if run_logjam() happened to have been run first, and it found an ffdhe cipher, then there is no need for run_pfs() to test for it.
In run_pfs(), when information about the finite field groups offered is printed, the color used is based on the length of the key. This information should also be conveyed to fileout() in the severity parameter.
Dirk
David Cooper
bitsofinfo