Question

What I am trying to do: I am trying to MITM a client whom is has the ability to connect to the server with: TLS_DH_anon_WITH_AES_256_CBC_SHA since it does I need to create a cert that will only allow this type of authentication. I am assuming that this is the cipher it is using to sign the cert (if someone can please enlighten me on the correctness of this).

How can I generate a cert with this cipher?

I am using openssl and this is in a lab environment (if I am not mistaken no one uses the DH_anon).

Just a few other questions, what does it mean for the client to not check the signature? and what does it mean for a cert to not be valid.

Thanks

Was it helpful?

Solution

A certificate will not enforce the use of anon DH (ADH), but the server can. And, you don't need to have any certificates with ADH. I've tried it with a recent IO::Socket::SSL (1.973) in Perl:

use strict;
use warnings;
use IO::Socket::SSL;
my $srv = IO::Socket::SSL->new( 
    LocalPort => 1234, 
    Listen => 10, 
    SSL_cipher_list => "ADH"
) or die; 
my $cl = $srv->accept or die; 
print $cl $cl->get_cipher,"\n";

Then connecting with openssl s_client -connect 127.0.0.1:1234 -cipher ALL I get:

CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 850 bytes and written 601 bytes
---
New, TLSv1/SSLv3, Cipher is ADH-AES256-SHA
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : ADH-AES256-SHA
    ....
    Verify return code: 0 (ok)
---
ADH-AES256-SHA
read:errno=0

As you see, it negotiates an ADH cipher and successfully connects without an certificate. To test it for your own you really need a recent version of IO::Socket::SSL.

OTHER TIPS

I am trying to MITM a client... in a lab environment...

The lab environment should not be difficult. Set up a rogue server that only provides TLS_DH_anon_WITH_AES_256_CBC_SHA. Use DNS to direct clients to the rogues server (you can even do it with a hosts file). Then have the rogue server contact the real server. The rogue server and the real server can use any cipher suite for their connection.


How can I generate a cert with this cipher?

You can't.

A X509 certificate binds a public key to an entity through an authority or issuer (sometimes called 'trusted'). The key type can be RSA, DSS or ECDSA. Certs can contain fixed Diffie-Hellman parameters, but I've never used them (and I don't believe I've ever encountered one). There is no cipher suite present.

TLS_DH_anon_WITH_AES_256_CBC_SHA is a parameter called cipher suite. Its a parameter like the protocol (SSL3, TLS1.0, etc). Its negotiated when the SSL/TLS channel is setup.

Anonymous means temporary Diffie-Hellman parameters were used for key exchange, and the Diffie-Hellman parameters were not signed by the server. ADH also means there's no need to send a server certificate because the responses are not signed.


As Steffen mentioned, you can use OpenSSL's s_client and s_server for testing. Rather than -cipher all, use:

openssl s_client -connect localhost:8443 -cipher TLS_DH_anon_WITH_AES_256_CBC_SHA

If you want a TLS connection:

openssl s_client -connect localhost:8443 -servername localhost -tls1 \
    -cipher TLS_DH_anon_WITH_AES_256_CBC_SHA

You can also set up a listening server with:

openssl s_server -accept 8443 -www -certform PEM -cert server-cert.pem \
    -keyform PEM -key server-key.pem -cipher TLS_DH_anon_WITH_AES_256_CBC_SHA

Unfortunately, for the s_server utility, you still need to load a private key even though it won't be used due to your choice of cipher suites.

By definition, DH_anon cipher suites do not use certificates, so you're not going to be able to generate a certificate for it.

Which cipher suite is used only depends on the certificate for the type of key exchange that can be used (generally RSA or DSA). Otherwise, it's an additional setting on the connection itself.

If you want to simulate an environment where a client is willing to use TLS_DH_anon_WITH_AES_256_CBC_SHA, you need to provide it with a server that enables it (it is sensibly disabled by default in most cases). In general, that server would also need to disable all authenticated cipher suites, since it would try to choose a better one otherwise. This should be a setting on your server code (generally on the SSL/TLS socket API).

Just a few other questions, what does it mean for the client to not check the signature? and what does it mean for a cert to not be valid.

Checking the signature is generally the first step for verifying a certificate: you check that it hasn't been tampered with and that it can be verified against the public key of a CA certificate you trust. Validation or verification include other steps such as checking it's valid at the current date/time (w.r.t. its notBefore/notAfter time stamps) and that it has the right attributes to be used for this purpose.


References: TLS 1.2 Specification, Server Certificate message:

  The server MUST send a Certificate message whenever the agreed-
  upon key exchange method uses certificates for authentication
  (this includes all key exchange methods defined in this document
  except DH_anon).

The Cipher Suite section might be of interest too.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top