Logjam TLS attack

That parameter is only for SSHv1 and if you have SSHv1 enabled you've already lost.

What they are refering to is the Key Exchange method named "diffie-hellman-group1-sha1" which uses a 1024-bit DH group. You can disable this with use of the KexAlgorithms parameter. Starting with OpenSSH 6.6 it is already disabled on the server side, but still allowed with the client. There are severe interoperability problems with embedded devices if disabled.

For clients, OpenSSL 1.0.2 introduced a function SSL_get_server_tmp_key() which retrives the ephemeral key parameters used by the server.

Except that most of the export rules that remains that affect browsers are easy to follow nowadays.

If you can break the DH exchange in the DHE ciphersuite, you can recover the session key and decrypt the traffic. That can be a complete break of that particular session without any need to break the server's long-term RSA key. It's quite possible to have a situation where the TLS_RSA... used a 2048-bit RSA key while the TLS_DHE... used a 1024-bit (or worse) DH parameter. In that case an attacker could have an easier time breaking the 1024-bit discrete logarithm problem compared to breaking the 2048-bit RSA problem.

To answer your question more directly, the DHE does use a different form of key establishment which uses different algorithms, different parameters, and potentially different parameter sizes. The forward secrecy is a desirable property in itself, but under some circumstances implementations might use weaker cryptographic parameters in conjunction with it.

(Daniel Kahn Gillmor first told me about this problem; in TLS_DHE_RSA the RSA key is used for authentication of the DH key establishment -- to stop someone from doing an active MITM attack -- but not for the key establishment itself. In TLS_RSA the RSA key is used directly for key establishment. Thus when you use TLS_DHE_RSA, your security levels may be limited by the weakest link mechanism that you rely on for security, which could conceivably be the DH exchange, depending on other features of your configuration and environment. A number of folks have been aware of that particular problem to some extent for a while and even discussed it at, for instance, the IETF TLS working group, but this paper takes things considerably further and makes the problems really concrete.)

Edit: upthread you can find a link to pbsd and AlyssaRowan discussing forms of the problem half a year ago, including the fact that you can get less security from weak DH parameters than you would have gotten from strong RSA parameters, despite the presence of forward secrecy. In some settings there cost trade-offs are possible for attackers between breaking particular sessions vs. breaking all traffic to a particular service.

My side project tries to give secure default settings for all major webservers and other software (like haproxy, mysql, mailservers etc): https://cipherli.st/

From the start it has listed the suggestion to set up >2048 DH keys.

If you want to test your site for export ciphers, you can try my other side project: https://tls.so/ - you can also use the SSL labs test but mine is faster for just testing ciphersuite. (And it's open source, so you can use it internally as well).

Mozilla also has a good wiki page for SSL settings: https://wiki.mozilla.org/Security/Server_Side_TLS