Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange.
Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters.
From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite.
Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use.
Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only.
So how to use this flaw -
If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a signed 512-bit export-grade Diffie-Hellman tuple, which the client will blindly accept -- because it doesn't realise that the server is negotiating the export version of the ciphersuite.
 |
| Logjam Attack |
All this hard work will fails when client and server will exchange the Finished messages (this include Hash of all the data exchange between client and server). The loophole (or the solution) of this is to recover the DH secret quickly before Finished messages exchanged between client and server.
So, the main task will be solve 512 bit discrete logarithmic problem before exchange of Finished messages. And this is a big task :).