Open danielboros opened 6 months ago
It is a known issue caused by TLS extension delegated_credentials
(34) (draft-ietf-tls-subcerts-15). Firefox parrots in uTLS advertise this extension by FakeDelegatedCredentialsExtension
without implementing any support of it, which causes issue if the server selected it and proceeded.
While adding support to delegated_credentials
is not currently planned, we welcome any community contribution in implementing ANY currently unsupported extensions.
FYI, cloudflare/go has implemented it which could be a good reference.
Sounds like I will take on this adventure. Will update here when I make some progress.
The only issue is that we are required to implement the delegated credential extension in the x509 parser as well
@gaukas what do you suggest? a local copy like dicttls ?
Hmm. That's pretty tough.
I am not super familiar with this extension yet, but from cloudflare/go I can see it is due to our certificate handling (from crypto/tls
) is directly using the x509 package which did not support some specific functionality for this extension or something.
Not an expert in this but is it possible for us to override a standard library to a remote package (say cloudflare/go/crypto/x509
)? I personally don't believe vendor-ing a mission critical package would bring us more benefits than trouble, at least in the long run.
I would rather suggest instead trying persuading go team to accept the required change and backport it into currently maintained versions. But afterall, if we really want to vendor it, we might want to minimize the impact by strictly limiting the use of our x509 which would go out-of-date very easily.
Seems to happen on
facebook.com
as well asfbcdn.net
. Minimal recreate below.Changing
utls.HelloFirefox_Auto
toutls.HelloChrome_Auto
appears to resolve the issue.