In a TLS handshake using DH to negotiate a session key, a prime number on both sides must exist. Calculating a prime number large enough to be secure takes a litte computational time.
When does chrome generate this number?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
Never. Chrome does not support FFDHE (which is how TLS calls Diffie–Hellman over the multiplicative group of integers modulo p) since 2016. Chrome only support ECDHE over NISP P-256, NISP P-384 and X25519 (ECDHE over Curve25519).
When chrome used to support FFDHE, the group and generator were set by the TLS server, not the TLS client, and the group prime was generally either a value from the RFCs (Oakley group) or a value generated by running
openssl dhparam 2048 (or the moral equivalent), usually once on install and never again.
In TLS DHE, the values generated online (the ephemeral keys) do not require generating large prime numbers. For more, see for example these two excellent crypto.SE answer on the properties of p and q for secure DH by Thomas Pornin.
The cryptography code in Chrome is open source, and is used also in Android and in Google's servers. It's Google's fork of openssl called BoringSSL. The main people working on it are Adam Langley and David Benjamin. You can read the code and often the explanation for why something was done. For example, DHE support was dropped because too many servers use a 2048 bit cert and 1024 bit DHE, and this is insecure, but the servers will only get fixed in practice when they upgrade the OS, which for LTS OSs can take a very long time.
If you want to read similar code that is in use, you can look at openssl 1.1.1.
Inside choosing group, we see that if not overriden, you get values from RFC (not generating new group online during TLS handshake).