tls: add --enable-mlkem flag to advertise X25519MLKEM768 hybrid group

[UnaPibaGeek]

Summary

This PR adds a new TLS flag: --enable-mlkem.

When enabled, zgrab2 advertises the TLS 1.3 hybrid post-quantum key exchange group X25519MLKEM768 as the first curve preference, followed by X25519 for compatibility.

By default, zgrab2 behavior remains unchanged.

---

Motivation

This flag is intended to be used together with the recently proposed ML-KEM (X25519MLKEM768) support in zcrypto: zmap/zcrypto#472.

The goal is to allow opt-in measurement of hybrid post-quantum TLS deployments (e.g., CDNs and servers that already support ML-KEM-based hybrid key exchange) without changing the default TLS fingerprint of zgrab2.

---

Behavior

• Default behavior: unchanged (classical curves only).
• With --enable-mlkem:
  • CurvePreferences is set to:
    • X25519MLKEM768
    • X25519
    • P256
    • P384
    • P521
  • Ensures compatibility fallback for servers that do not support the hybrid group.

---

Compatibility

This change is fully backward-compatible:

• No change to default scanning behavior.
• No change to existing flags.
• No impact unless explicitly enabled.

---

Testing

• Verified successful TLS 1.3 hybrid negotiation with servers supporting ML-KEM.
• Verified fallback to classical X25519 on servers without hybrid support.
• Confirmed no change in behavior when the flag is not used.

NOTE: Not all zgrab2 test will pass until the aforementioned zcrypto PR is merged.

[dadrian]

@UnaPibaGeek Can you update this to keep the schema the same (see the failed integration test)

[UnaPibaGeek]

@UnaPibaGeek Can you update this to keep the schema the same (see the failed integration test)

Sorry I re-requested review accidentally, sure, let me review it asap.

[UnaPibaGeek]

Hmm I thought the integration test failure was due to zgrab2 pinning an older zcrypto_schemas commit that predates the addition of handshake_log.server_hello.key_share introduced in zcrypto #462. I updated the pinned zcrypto_schemas version to zcrypto master merge commit 1e860df zcrypto #472, so the schema matches the current output. Yet CI still doesn't like it... I'll try to figure it out.

[dadrian]

Oh that's entirely possible. We can probably just merge then.

[UnaPibaGeek]

@dadrian I think this update to the schemas in zcrypto should fix the current issue: zmap/zcrypto#476. Then we should point zgrab2 requirements to that commit.

[UnaPibaGeek]

Hmm I see a new/different schema error now, I'll look into it.

Edit: The current error (and even the previous one) has nothing to do with the ML-KEM support. These errors originated earlier, and now that we're pointing to the latest zcrypto commit and the field key_share (introduced in zcrypto PR 462) is being validated, these "new" errors have appeared. I've just submitted another PR to zcrypto that should correct the naming issue that appears here in the latest CI error (zschema.keys.DataValidationException: name: the value ecdh_x25519 is not a valid enum option).

[UnaPibaGeek]

That's strange... I don't know exactly what the test doesn't like, but it has nothing to do with the MLKEM support as far as I can see; it seems to originate from something earlier.