1

I'm doing two tests using the openssl s_client command to identify anonymous. I did two tests:

One first test: I'm using the following command to anonymous ciphers:

openssl s_client -cipher aNULL -connect example.com:443

And I get the answer:

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4565 bytes and written 338 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 626B89DDAD15392B05CC2D638566569BECC252C8AACD904BA22470B84BB4B2DC
    Session-ID-ctx: 
    Resumption PSK:     46383EA3BEA5C2AC3B1C43FE330146581F9CDBA55D0D43AABB3F45C18CA7871770F6DD6E0C94353DD647162AE586203E
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:

And second test get the answer::

CONNECTED(00000003)
140420107691392:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake     failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 264 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

I have a question, am I vulnerable to anonymous ciphers in either of the two examples? Please help me.

2
  • 1
    Your first connection used TLS1.3 -- which is surprising because all TLS1.3-supporting versions of OpenSSL reject -ciphers aNULL if built with 'standard' (upstream) config. In TLS1.3 keyexchange is no longer specified by the ciphersuite(s), and server authentication is always done, as was clearly shown in the first part of the output which you didn't post, but should look at. Your second connection failed. This may have happened because the server only supports TLS1.2 (or lower, but hopefully not) and doesn't support any anonymous suites, but we (and you) can't tell that for certain. Jun 16 at 2:43
  • dave, thanks you very much for help, but the TLS 1.2 and TLS 1.3 is enabled. I think that's the problem. What do you think? The second example is not vulnerable, correct? Jun 16 at 14:38

1 Answer 1

1
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384

In this first example a TLS 1.3 handshake was done. The -ciphers argument for openssl s_client is irrelevant in this case since (from the documentation):

-cipher cipherlist
This allows the TLSv1.2 and below cipher list sent by the client to be modified. This list will be combined with any TLSv1.3 ciphersuites that have been configured. Although the server determines which ciphersuite is used it should take the first supported cipher in the list sent by the client. See the ciphers command for more information.

Apart from that TLS 1.3 does not even support anonymous authentication. Nevertheless the server might still support anonymous authentication with lower protocol versions.

As for the second example:

... routines:ssl3_read_bytes:sslv3 alert handshake     failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40
...
New, (NONE), Cipher is (NONE)

This just means that the server explicitly let the handshake fail, sending a TLS alert back. The exact reason for the handshake failure is unknown. It might have been that the server does not support anonymous authentication. But there might also have been other reasons, like not support for specific TLS protocol versions, signature algorithms ... whatever.

Therefore this will only be an indicator but is not real a proof that the server does not support anonymous authentication.

Apart from that servers might also change behavior based on the clients IP address, use of IPv4 vs. IPv6, time, other properties of the ClientHello, ... . So just treating the server as a black box and probing it with various ciphers will never be a proof of the servers general behavior but only show the servers behavior in these specific test cases. It only shows what the server supports, but does not show for sure what the server does not support.

2
  • Steffen, thanks very much for help. Your response is very appreciable. The TLS 1.2 and TLS 1.3 is enabled. I think that's the problem. What do you think about? In theory the... one first example is vulnerable and second example is not vulnerable, correct? Jun 16 at 14:39
  • @JhonLaurence: None of the examples shows a vulnerability and none of the examples proofs that a vulnerability is absent. As I said - your attempt to get a null authentication is simply ignored in the first example since TLS 1.3 is used. Jun 16 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.