This site is enabled for hybrid post-quantum key exchange with the X25519MLKEM768 or X25519Kyber768Draft00 using cfgo. Your connection to this site is using the TLS_AES_128_GCM_SHA256 cipher which is data we pull from the TLS connection state CipherSuite method. We are probably using the X25519 elliptic curve but it's complicated to get the info directly server side. You can check client side in chromium based browsers by right clicking "inspect" to get to the developer tools and switching to the "security" tab to see if X25519MLKEM768 or X25519Kyber768Draft00 are listed, or in firefox with inspect->network->select an item on the list->security->look for mlkem768 or kyber768d00.
You can learn about the new PQC standards from NIST. If you want more details about your browser check out browserleaks.
This is enabled by default in the latest versions of Chrome and Edge. You can enable in Firefox by going to about:config and turning on security.tls.enable_kyber. We check the Key encapsulation Mechanism (KEM) now because that's what protects against Steal Now Decrypt Later (SNDL) attacks. We'll add Digital Signature Algorithm (DSA) checks too when things are ready.
In go it's challenging to pull curveID being established in a connection as it happens. It's a chicken and egg problem with the tls.Config. Additionally, many of the methods in common.go and key_agreement.go are defined internally within the crypto/tls package and are not exported, so we can't actually reference the information they hold directly without circumventing via logging or rebuilding aspects of the package. Specifically, we need the curveID variable from line 173 in key_agreement.go. So, our work around is that this site runs a duplicate of that method (~3 lines of code) with the same inputs. We're reasonably sure that provides the correct curveID, but there might be cases where it is not, so sorry about that. If you have another approach for checking server side let us know!