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?

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 your question reads:

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.

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.