From stud -h:

    Encryption Methods:
       --tls                    (TLSv1, default)
       --ssl                    (SSLv3)
       -c CIPHER_SUITE          (set allowed ciphers)

Edit: Though, you'd need to set DHE params, as another commenter said below. Stud doesn't do this atm, but I'm open to a patch!

I think 'seiji's right, and OpenSSL won't actually do DHE handshakes unless you give it parameters, which is another 2 lines of code that aren't actually in stud.

nginx is a web server, like Apache. stud is a few hundred lines of trivial proxy code. And would you like to take a bet on how many lines of C code it would take to add support for configurable cipher suite modes in stud? Fair warning: I already know the answer to this (and I don't even know that stud doesn't allow it).

Do you happen to have a patch? I might be interested in that :)

That's the trick -- you can enable your DHE cipher all day long, but if the code doesn't set up DHparams, it will never work.

Here's a quick (no error checking) way to set up DHparams if they are appended to a cert:

    BIO *bio = BIO_new_file(path_to_a_file_with_dhparams, "r");
    DH *dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
    BIO_free(bio);
    SSL_CTX_set_tmp_dh(ctx, dh);
    DH_free(dh);

Where do the DH parameters come from? You can generate it yourself (1024 bits here):

    openssl dhparam -rand - 1024

For a completely isolated implementation (requiring no user certificate changes), see function ngx_ssl_dhparam in nginx-1.0.4/src/event/ngx_event_openssl.c

Doh! 'seiji wins. I was way too glib about DHE. Sorry.

Just a bit of history: I was the one that prodded Igor to add this.

I had been checking things out in nginx and noticed that DH was not implemented. One quick email to Igor and he got it done the same day along with getting this into the next version of nginx. Dude is bad ass.

Now if only someone can convince him or provide a patch to add SPDY support to nginx...

So what would you do with the generated DH parameters? Literally just `cat` them to the bottom of the SSL cert? Is there anything else that needs to be done? What happens when DHE-RSA-AES256-SHA is used without having those DH parameters in play?

Yup. Just add it to the end of your private key/certificate file (NB: only applies to stunnel when configured for DH or other programs reading DHparams from a key/cert file).

If you try to use only DHE-RSA-AES256-SHA without DH being setup, nothing will connect. If you have DHE-RSA-AES256-SHA as an option with others, it will negotiate a non-DH cipher. (e.g. "DHE-RSA-AES256-SHA:!ADH:SHA" -- you can verify the ordering with `openssl ciphers -v DHE-RSA-AES256-SHA:!ADH:SHA`)

Fair warning: this comment is apparently all kinds of wrong, but I leave it here for posterity.

Put:

  if(getenv("SSL_CIPHER_SUITES"))
    SSL_CTX_set_cipher_list(ctx, getenv("SSL_CIPHER_SUITES"));

anywhere after SSL_CTX_new().

But don't bother doing it with stud, because (as I sort of predicted) stud already does this: stud -c <ciphersuites>.

I don't understand what Matt is saying by "stud doesn't enable DH at all". Does stud build its own OpenSSL? The system OpenSSL will already support DHE.

Ask and ye shall receive: https://github.com/bumptech/stud/pull/6

stunnel DH code inserted into stud.