Closed BRUHItsABunny closed 9 months ago
Interesting. So you are basically saying you copy-pasted the preset of HelloChrome_120
from u_parrot.go
and trying to use it as a custom ClientHelloSpec but with no luck.
While I have not yet encounter such problem in the past, here's a few thing you might want to double check:
spec
? Currently uTLS modifies the input spec, the solution is making a deep copy every time (#111). config.PreferSkipResumptionOnNilExtension
to true
while not including PSK in your Config
, when using a custom parrot.
https://github.com/refraction-networking/utls/blob/d2768e4eaac0c6f6e7b9e53ccec6ce8e907addd9/u_conn.go#L69Plus, doing a pcap may efficiently assist you in figuring out in which step of the TLS handshake did the error occur. You may also want to trace back to which tls: internal error
are you seeing. I think uTLS has a longer error message like tls: internal error: attempted to read record with pending application data
instead of just tls: internal error
.
So you are basically saying you copy-pasted the preset of HelloChrome_120 from u_parrot.go and trying to use it as a custom ClientHelloSpec but with no luck.
That's correct, with the exception of commenting out TLS 1.3 in the supported TLS versions in the ClientSpec somehow not giving an error.
I can confirm that I am not re-using the ClientSpec as this is currently running inside a unit test that just makes a single client with a single request going out.
Good catch on that config.PreferSkipResumptionOnNilExtension
this got my hopes up but despite adding it the issue remains the same.
I will try a pcap sometime today and post full code that reproduces this issue as well.
Also I would suggest explicitly call uTLSConn.Handshake()
after you call ApplyPreset()
to see if it errors. So far I have tried a variety of combinations of possible utls.Config
fields but was able to connect to www.google.com:443
anyways. If you can share a hard-coded Config
you used to reproduce this error, either me or someone from the community might be able to help you.
It looks like the initial connection works but then the redirect to www.google.com is failing.
When using the ClientHelloId it seems to be able to handle that redirect:
I'm a bit rusty with wireshark, but I will try and dig deeper into this tomorrow
Code that reproduces the issue can be found here: https://github.com/BRUHItsABunny/gOkHttp-ja3spoof/blob/test/tls-1-3-issue/client_opt_test.go
I will work on a snippet that doesn't use oohttp to see if I can limit the possibilities of outside influences
Excuse me for intrusion.
What caught my eye on these screenshots is that SNI is incorrect on redirected connection in the first case (it's google.com
, although www.google.com
is expected). DNS query is for www.google.com
, so host is probably passed in correctly.
On the second screenshot second connection's SNI is correct.
My bet is that there's something wrong with SNI. I support @gaukas' suggestion about Handshake()
and also suggest trying SetSNI()
before Handshake()
(at least that's the way I use custom ClientHello specs and it works).
SNI is incorrect on redirected connection
Good catch. And I actually think it is an indication of an old client spec being reused -- or something else is happening which prevented the server name from updating.
Reproduced error. And the error is from here:
No extra error message because it is not a specific error hardcoded inside uTLS, but rather a general TLS Alert alertInternalError
(80).
Now I am almost certain that you reused the ClientHelloSpec
. Let me know if otherwise @BRUHItsABunny.
Thanks, it didn't look like a re-use at first glance but looking deeper into it it really is a re-use and I got PoC working that fixes that within my code base. Thank you all very much for your help and patience.
This works, I can dial Google and it gives no errors.
This can't dial Google, it errors out with
Get "https://www.google.com/": local error: tls: internal error
If I comment oututls.VersionTLS13,
it will work though. This spec is a copy paste of the spec backingutls.HelloChrome_120
, and there TLS 1.3 functions as expected.This code is a basic example of what I'm facing, I will post a repo with a piece of code that reproduces the error if needed.
Does anyone happen to know what's wrong? I'm not entirely sure what I'm missing to get this to work. The end goal will be to load custom specs from my database, similar to loading from JA3 except my database entries contain the missing information that's technically still part of the TLS hello but not fully represented in a JA3 full string. This technically does work already, when limiting to TLS 1.2 and below.
Thanks for your time