Logjam covers two weaknesses in Diffie-Hellman key exchanges: the ability to downgrade TLS sessions to use extremely weak DH key exchanges, and the potential ability to break DH key exchanges using common, known primes of 1024 bits and below. Logjam affects at least TLS, SSH, and IPSec's IKE protocol, all of which I use. Since Logjam was announced I've been working on figuring out what I can and should do in reaction to it, which in part involved looking at my situation and software, and I think I've come to answers now.

For TLS on my personal site I used the Logjam sysadmin recommendations to generate my own 2048-bit prime for DH key exchange. I haven't put their lighttpd cipher suite suggestion into place because I don't fully trust it to be at least as good as my current set and also every time I touch lighttpd's cipher selection it's a pain in the rear. Sometime I will switch to Apache and then I'll adopt whatever Mozilla's current SSL configuration recommendations are.

(My server already scores decently high on the Qualys SSL server test and doesn't have any export ciphers allowed.)

For SSH, things get more complicated. SSH is not subject to downgrade attacks and OpenSSH already puts the vulnerable DH key exchange algorithm last in the preference list, so the only connections vulnerable to this issue are ones where either the client or the server doesn't support anything else. Unfortunately we sort of have some of those; Illumos aka Solaris SSH is so old that it only supports the vulnerable algorithm and 'diffie-hellman-group-exchange-sha1', which uses custom moduli of some size (hinted by the client, see RFC 4419). If I am reading 'ssh -vv' debug output correctly, modern OpenSSH clients ask for and get DH primes that are larger than 1024 bits even here, so we're safe. If we're not safe, there's probably nothing I can do about it.

(The theoretically 'custom' moduli of d-h-g-e-sha1 may be relatively standardized by mechanisms such as OpenSSH shipping a precreated /etc/ssh/moduli, but if so I'm still safe since connections seem to be using more than 1024 bits.)

So at the moment I don't intend to make any SSH configuration changes. I'm satisfied that any client connecting to our servers that can do better will be doing better, and I don't know if we have any remaining clients that literally can't manage anything better. My client connections will do better to any server where it's possible and I don't want to lose access to anything around here with a really terrible SSH server (most likely some embedded lights out management system from the dark ages).

The situation for IKE turns out to be similar. IKE is apparently not vulnerable to downgrade attacks in normal operation (at least in my setup) and Libreswan, the IKE software I'm using, defaults to using strong primes when talking to itself (per their FAQ answer, also). In this it turns out to be a good thing that I specifically insist on my configuration using IKEv2, which has stronger defaults. Since my only (current) use of IKE IPSec is for two strongly configured hosts to talk to each other, I don't need to do anything in order to keep being secure.

(We have a L2TP VPN server for our users. I suspect that it's already choosing strong defaults when it can, ie when clients support it, but we may need to do some configuration tweaks to it at some point. Disabling any current IKE modp1024 support is probably not viable because it runs the risk of cutting off clients in order to deal with a relatively low risk.)