In TLS, does the client know the server's public key before starting the data exchange?

I am reading about the logjam attack. I was asked if the attack could be prevented by checking the integrity of the Server Hello message.

My answer would be no because the man-in-the-middle can still not send the original Server Hello message and send its own.

From my research, it seems like the client only gets hold of the server's public key during the Server Hello message which includes the server's public key.

If it's so, my answer should be correct.

Is there a way for the client to know the server's public key before the Server Hello message?

• Which server publickey? The one used for authentication, or the one used for keyexchange which is always different in 1.3 and often but not always different in earlier protocols? Only the ephemeral kx key in 1.3 is in ServerHello, and that can't be used to verify integrity of anything. But Logjam wouldn't apply to 1.3 because it no longer allows too-small or unvalidated and potentially defective FFDH groups for kx. Sep 8 '21 at 2:15
• @dave_thompson_085 as seen here: cryptologie.net/upload/logjam.png the ServerHello message sends certS, sign(skS,[p512, g, g^b]). I am trying to find out if during this point the client can verify the identity of the server can the logjam attack be prevented?
– Jack
Sep 8 '21 at 4:22
• That diagram shows only the specific data items relevant to the attack, not anywhere near all the protocol and definitely not the messages containing them. See RFC 2246 et seq. Although as Maarten says, the critical item to verify is the chosen ciphersuite and that is indeed in ServerHello. Sep 9 '21 at 1:14

The attack, which we call Logjam, is depicted in Figure 2 and relies on a flaw in the way TLS composes DHE and DHE_EXPORT. When a server selects DHE_EXPORT for a handshake, it proceeds by issuing a signed ServerKeyExchange message containing a 512-bit $$p_{512}$$, but the structure of this message is identical to the message sent during standard DHE ciphersuites. Critically, the signed portion of the server’s message fails to include any indication of the specific ciphersuite that the server has chosen. Provided that a client offers DHE, an active attacker can rewrite the client’s ClientHello to offer a corresponding DHE_EXPORT ciphersuite accepted by the server and remove other ciphersuites that could be chosen instead. The attacker rewrites the ServerHello response to replace the chosen DHE_EXPORT ciphersuite with a matching non-export ciphersuite and forwards the ServerKeyExchange message to the client as is. The client will interpret the export-grade tuple $$(p_{512}, g, g^b)$$ as valid DHE parameters chosen by the server and proceed with the handshake. The client and server have different handshake transcripts at this stage, but an attacker who can compute $$b$$ in close to real time can then derive the master secret and connection keys to complete the handshake with the client, and then freely read and write application data pretending to be the server.

And I guess that the answer is yes, but only if it would sign / verify the set of cipher suites that is being offered within the ServerHello, and it seems that at least TLS up to 1.2 fails to do so. In other words, you'd have to change the TLS protocol to include the offered cipher suites in the signature generation / verification, making it incompatible with any other TLS software.
So currently it seems that simply disallowing your implementation to execute DHE_EXPORT (or 1024 bit ephemeral DH) is the way forward for TLS up to 1.2.
• I meant that theoretically you can also sign the cipher suite in the ServerHello, but that would mean change of the overall protocol. If you are just using the protocol then it's a strong no. Sep 8 '21 at 14:11