This PR addresses the same issue as 6bb3494d98. In its current form, fileout_insert_warning() cannot be used after fileout_section_header() has been called for the first time.
testssl.sh produces an invalid JSON file if the --json-pretty option is used with the --single-cipher option. The reason is that fileout_section_header() isn't called before run_cipher_match() calls fileout() and fileout_section_footer() is not called afterwards.
There is also a problem with MEASURE_TIME, since the "cleanup" at the end of lets_roll() is not performed.
This PR fixes these problems by adding a call to fileout_section_header() before the call to run_cipher_match() and by copying the code from the end of lets_roll() to run_cipher_match() (just before the call to exit).
Extra client side warning led to a non-valid JSON pretty output. This fixes
this bug by adding an extra object. The objects are named "clientProblem${NUMBER}".
By "extra client side" I mean extra warnings which are not happening during regular
tests -- those are no extra ones and should just warn with ``fileout()`` instead
of ``fileout_insert_warning()``.
Also some ``fileout arg1 WARN`` were patched: WARN is not a finding. It is just
a report that either on the client side something doesn't work as expected or
the server could not be checked during a particular test. WARNING doesn't
exist at all, WARn should be used instead.
Some lines where a warning output to JSON or CSV was missing, was added.
Currently, when `$DEBUG` is 2 and the connection is successful, `parse_tls_serverhello()` prints out information about the server's ephermal (EC)DH key, but nothing else. For example:
```
sending client hello... reading server hello...
dh_bits: ECDH, P-256, 256 bits
sending close_notify...
(183 lines returned)
```
This commit changes `parse_tls_serverhello()` so that information about dh_bits is only displayed if `$DEBUG` is at least 3, making it the same as for other information about the server's response.
In addition, it indents the printing of the information about dh_bits in order to better align with other information displayed at this debug level.
- add forgotten servive FTP and XMPP
- polish other services
- after TLS 1.2 run is finished run a check whether no protocol has been detected and ask the user for confirmation to proceed
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`.
In `run_protocols()` for TLS 1.2, try one set of 127 ciphers and if the result isn't a connection at TLSv1.2 then try another set of 127 ciphers before giving up and assuming that TLS 1.2 isn't supported.
FIX#786
Fixed all other occurences so that debug level 2 is showing only minimal information like rough status and errors
Better line breaks for level 2
In ``client_simulation_sockets()`` and ``tls_sockets()`` moved debug output into if statements (may save a bit of time)
Replaced "$DEBUG -eq" by "$DEBUG -ge"
Removed obsolete hb_rounds in ``run_heartbleed()``
Adjusted wide output in vulnerabilities
The data for `run_client_simulation()` currently includes two clients that send version 2.0 CLIENT-HELLO messages (see Appendix E.2 of RFC 5246). Each of the CLIENT-HELLO messages advertises support for newer protocol versions (SSLv3 in the case of IE6XP and TLSv1.0 in the case of Java 6u45). A server may reject one of these version 2.0 CLIENT-HELLO messages, or it may respond with an SSLv2, SSLv3, or TLSv1.0 ServerHello.
The current code in `client_simulation_sockets()` assumes that the server's response with be an SSLv3 or later ServerHello. So, it can support cases in which servers respond with an SSLv3 or TLSv1.0 ServerHello (once PR #800 is accepted to undo the mistake in PR #797), but not cases in which servers response with an SSLv2 ServerHello.
This PR adds code to `client_simulation_sockets()` to check if the server's response is an SSLv2 ServerHello, so that it can process such responses with `parse_sslv2_serverhello()` rather than `parse_tls_serverhello()`.
When a connection is made using SSLv3 or later, `run_client_simulation()` will show to the protocol and cipher selected for the connection. With this PR, if the connection is made using SSLv2, `run_client_simulation()` will just show "SSLv2." In the case of SSLv2, the ServerHello contains a list of all ciphers that the server and client have in common, and it is up to the client to choose one. So, if the client and server have more than one cipher in common, more information about the client would be needed to know which cipher it would choose.
`std_cipherlists()` uses `has_server_protocol()` to determine whether to test for ciphers using SSLv2. However, this was resulting in false negatives due to #759. This PR removes the `has_server_protocol()` check so that SSLv2 is checked whenever the connection attempt with the TLSv1.2 ClientHello failed.
This PR fixes the extraction of the cipher suites in SSLv2 ClientHellos in `client_simulation_sockets()`. Since `client_simulation_sockets()` can only handle SSLv3 and above ServerHellos, it removes any SSLv2 ciphers and converts the other cipher from 3-byte format to 2-byte format.
If vulnernable to POODLE and has no TLS_FALLBACK_SCSV ==> HIGH.
If only run the fallback check and it has none, still label it as MEDIUM but issue
a clear warning that test under this circumstances is incomplete.
This PR adds the same additional check to `client_simulation_sockets()` as was previously added to `tls_sockets()`. It extracts the list of cipher suites offered from each ClientHello and passes the list to `parse_tls_serverhello()` so that `parse_tls_serverhello()` can check that the cipher offered in the ServerHello was included in the ClientHello.
This assumes that a real client would abort the connection if it was presented with a cipher in the ServerHello that it didn't offer in its ClientHello.
Dirk Wetter
David Cooper