Repository navigation
Add Firefox 148 fingerprint (with X25519MLKEM768) and make it HelloFirefox_Auto - #8
Open
scarletjess77 wants to merge 1 commit into
Open
scarletjess77 wants to merge 1 commit into
scarletjess77 wants to merge 1 commit into
Conversation
For browsers that sends pq hybrid and classical keyshare pairs, it may or may not choose to reuse the classical part between them. Add a helper to be used when crafting the spec to signify that the reuse should happen, and implement the reuse when generating keyshares. Existing specs will still generate keys independently. Add Firefox 148 spec that uses this reuse. Ported from refraction-networking/utls@fc716b2. The only conflict was the imports: mlkem comes from internal/mlkem here, so only crypto/ecdh is added.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This brings over upstream's Firefox 148 ClientHello (refraction-networking/utls@fc716b2, by Mingye Chen) and points
HelloFirefox_Autoat it.Why
HelloFirefox_Autois still Firefox 120, which sends noX25519MLKEM768; Firefox has sent it since 132. Since XTLS/REALITY@8cdf7bf (in Xray-core v26.9.30 and later), REALITY servers turn away a Client Hello withoutX25519MLKEM768beforeX25519, and pass it on to the target as a normal visitor.So in mihomo,
client-fingerprint: firefoxcan't reach a REALITY server on a current Xray, even withsupport-x25519mlkem768: true. The log showsREALITY authentication failed.chromeworks, because Chrome 133 has the key share. Xray clients work withfirefox, because upstream uTLS already has Firefox 148.What changes
HelloFirefox_148, the spec from upstream unchanged:X25519MLKEM768first, thenX25519andP-256key shares, cert compression, ECH GREASE and record size limit, as Firefox 148 sends them.X25519key share reuses the classical half of the hybrid one (ReuseHybridAndClassicalKeyShares). Specs that don't ask for it are unchanged.HelloFirefox_Auto = HelloFirefox_148.HelloFirefox_120stays, so mihomo'sfirefox120keeps the classical hello.u_parrots_test.go).The only conflict was the imports:
mlkemcomes frominternal/mlkemhere, as in the rest of the fork, so onlycrypto/ecdhis added.Testing
go build ./...,go vet .andgo test .pass on Go 1.20.14 and Go 1.27.3.replace github.com/metacubex/utls), VLESS REALITY outbound withclient-fingerprint: firefoxandsupport-x25519mlkem768: true, against a local Xray-core v26.10.31 REALITY server:REALITY authentication failed(20 of 20).is using X25519MLKEM768 for TLS' communication: true.firefoxstill needssupport-x25519mlkem768: truefor REALITY, likechrome, since mihomo leaves the hybrid key share out otherwise.