Hi Julien,

> Afaik, the above dynamically links openssl. Am I wrong?

Yes, you're wrong.

> Are you saying you would rather use non-PFS ciphers than wait an extra 15ms
> to complete a DHE handshake? I wouldn't.

No, I'm saying that since you're compiling against OpenSSL-1.0.1,
you've got ECDHE cipher suites, which are much faster than DHE and all
modern browsers support ECDHE.

I know this kind of contradicts my "you shouldn't be dropping SSLv3
support" statement (since SSLv3 doesn't support ECDHE, so it would end
up without PFS cipher suite), but you cannot have everything.

Also, while this isn't the best reason to do things, none of the "big"
players offers DHE.

> Interesting information, which I didn't have before. May I ask how you
> collected it?

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | grep lifetime

While this only shows you the Session Ticket lifetime hint and not the
internal session cache expire policy, it shows you the value they are
aiming for with resumption. Also, in nginx's case both values are the
same.

Trust me, you want this to be high :)

> Because someone else might use DSA certificates.

It's ECDSA, not DSA... And I'm yet to see a site that offers ECDSA
instead of RSA certificate.

> No. The alternatives aren't available everywhere.

Virtually everywhere ;)

> Again, I don't control clients. I push down unwanted ciphers, but I won't
> disable them unless they are obviously broken (MD5, ...).

Kind of the same reasoning as for DHE - AES (with AES-NI) is much
faster than CAMELLIA and I dare you to find a software that supports
CAMELLIA but not AES.

Keep in mind that the reason for disabling slow cipher suites is not
to limit interoperability, but to limit impact of attacks that use
time-consuming crypto... For example, AES (with AES-NI) is 4x faster
than CAMELLIA while essentially providing the same level of security,
which means that (D)DoS attacks on SSL require 4x less resources if
you don't disable it.

> I appreciate the feedback, but no need to be rude about it ;)

Actually, I was trying hard to not sound rude (apparently I failed),
but the fact is that calling it "A grade" and "state of the art"
configuration results in people that don't know any better picking up
your recommendations and deploying them in production.

Best regards,
Piotr Sikora

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx