I heard there is a "new" TLS vulnerability named Logjam, what does it do and how do I prevent it?
TL;DR
SSL/TLS client and server agree to use some weak crypto. Well, turns out that weak crypto is weak.

In Detail
When an SSL/TLS protocol is performed, the client sends a list of supported cipher suites, and the server chooses one. At the end of the initial handshake, some Finished messages are exchanged, and encrypted/protected with the newly negotiated crypto algorithms, and the contents of these messages is a hash of all the preceding messages.
The idea is that an active attacker (a MitM attack) could try to manipulate the list of cipher suites sent by the client to remove all "strong" crypto suites, keeping only the weakest that both client and server support. However, this would break the Finished messages. Thus, these messages are meant (among other roles) to detect such downgrade attacks.
In theory, it's fine; unless the client and server both support a cipher suite that is so weak that the MitM attacker can break it right away, unravel the whole crypto layer, and fix a Finished message in real time. Which is what happens here.

In Even More Detail
When using the "DHE" cipher suites (as in "Diffie-Hellman Ephemeral"), the server sends the "DH parameters" (modulus and generator) with which client and server will perform a Diffie-Hellman key exchange. Furthermore, the server signs that message with its private key (usually an RSA key, since everybody uses RSA in practice). The client verifies that signature (the public key is the one in the server certificate), then proceeds to use the DH parameter to complete the key exchange.
It so happens that in the previous century, there were some rather strict US export regulations on crypto, and this prompted "export cipher suites", i.e. weak crypto that was compatible with these regulations. Many SSL servers still support these "export cipher suites". In particular, some cipher suites that use DHE and mandate a DH modulus of no more than 512 bits. Moreover, most SSLs in the servers use the same modulus, because using the one provided with the SSL library is easier than generating your own. Reusing the same modulus as everybody else is not a big issue; DH tolerates that just fine. However, it means that if an attacker invests a lot of computations in breaking one DH instance that uses a given modulus p, the same attacker can reuse almost all of the work for breaking other instances that use the same modulus p.
So the attack runs like this:

Attacker is in the MitM position; where he can modify data flows in real time,
Attacker alters the list of cipher suites sent by the client to specify the use of an export DHE cipher suite,
The server complies and sends a 512-bit modulus p,
The client is still persuaded that it is doing a non-export DHE, but a DH modulus is a DH modulus, so the client accepts the weak/export modulus from the server just fine,
Attacker uses his pre-computations on that value p to break the DH in real time and fix the Finished messages.

The Logjam article authors call this a "protocol flaw" because the ServerKeyExchange message that contains the export DH parameters is not tagged as "for export", and thus is indistinguishable (save for the modulus length) from a ServerKeyExchange message that contains non-export DH parameters. However, I would say that the real flaw is not there; the real problem is that the client and server accept to use a 512-bit DH modulus even though they both know that it is weak.

What should you do?
Well, the same thing as always: install patches from your software vendors. As a matter of fact, this should go without saying.
On the client side, Microsoft has already patched Internet Explorer to refuse to use a too small modulus. A fix for Firefox in the form of a plugin by Mozilla is available here now. It is expected that other browser vendors (Opera, Chrome...) will soon follow.
On the server side, you can explicitly disable support for "export" cipher suites, and generate your own DH parameters. See that page for details. Note that IIS is kind of immune to all of this because apparently it never supported DHE cipher suites with anything else than a DSS server certificate, and nobody uses DSS server certificates.
Note that ECDHE cipher suites, in which "EC" stands for "elliptic curve", are not at risk here, because:

There are no "export" ECDHE cipher suites (ECDHE cipher suites were defined after the US export regulations were considerably lifted).
Clients in general support only a few specific curves (usually only two of them, P-256 and P-384) and neither is weak enough to be broken (not now, not in the foreseeable future either).


And what about the NSA?
The Logjam researchers include some talk about how some "attackers with nation-state resources" could break through 1024-bit DH. This is quite a stretch. In my experience, nation states indeed have a lot of resources and are good at spending it, but that's not the same thing as succeeding at breaking hard crypto.
Nevertheless, if you fear that 1024-bit DH is "too weak", go for 2048-bit (this is the recommended one anyway), or ECDHE.
Or simply accept that people with overwhelming resources really have overwhelming resources and won't be defeated by a simple modulus size. Those who can spend billions of dollars for cracking machines can also bribe your kids with a few hundreds of dollars to go through your computer files and your wallet.
