Misinterpretation of no cipher overlap with client

[Niklas974]

I'm debugging a weird client that does not seem to like any ciphers. This is correctly displayed by qsslcaudit (see below: "socket error: […]"). In this case, the server (qsslaudit / openssl) breaks the connection (See Packet 108 in wireshark screenshot)

This is all fine, but qsslcaudit interprets the failure as the client not accepting the certificate, even though the server failed before even sending the certificate.

preparing selected tests...
        skipping test: certificate trust test with user-supplied certificate
        skipping test: certificate trust test with self-signed certificate for user-supplied common name
        skipping test: certificate trust test with user-supplied common name signed by user-supplied certificate
        skipping test: certificate trust test with www.example.com common name signed by user-supplied certificate
        skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate
        skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

SSL library used: OpenSSL 1.0.2u  20 Dec 2019
running test #3: certificate trust test with self-signed certificate for www.example.com
listening on 10.6.6.15:31103
connection from: 10.6.6.10:39978
socket error: Error during SSL handshake: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher (#13)
        The SSL/TLS handshake failed (client did not provide expected ciphers), so the connection was closed.
no unencrypted data received (Error during SSL handshake: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher)
disconnected
report:
client did not accept fake certificate
test finished
tests results summary table:
+----+------------------------------------+------------+-----------------------------+
| ## |             Test Name              |   Result   |           Comment           | 
+----+------------------------------------+------------+-----------------------------+
|  3 | self-signed certificate for invali |   PASSED   |                             | 
|    | d domain trust                     |            |                             | 
+----+------------------------------------+------------+-----------------------------+
most likely all connections were established by the same client
the first connection details:
source host: 10.6.6.10
dtls?: false
ssl errors: Error during SSL handshake: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
ssl conn established?: false
socket errors ids: 13 
received data, bytes: 103
transmitted data, bytes: 0
protocol: TLSv1.2
accepted ciphers: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
heartbeat mode

qsslcaudit version: 0.8.2

[zOrg1331]

Thank you for this report.

I agree, that this has to be handled differently, as qsslcaudit did not actually verified the certificate acceptance. I will alter the logic.

It appears that your client expects a certificate signed using elliptic curve algorithms, thus, it refused to deal with a presented certificate. This might be another issue...

[zOrg1331]

@Niklas974 I've published a new release which contains a change which alters qsslcaudit's way of thinking in scenarios like you reported. Please, have a look at this build. You can use packages from the official PPA (Ubuntu). I am not sure when it will arrive to Kali.

There is another problem in your case: client accepts only elliptic curve-kind of ciphers. This may indicate that it expects that server's certificate will be signed with EC as well. As far as I remember, in this cases it is better to create your self-signed certificate signed with EC to perform proper test. Probably, I'll need to handle this somehow better in qsslcaudit. Will think about it.