@tersinemuhendis any proof?
I’ve started studying low-level networking to understand full network behavior in depth. The clear conclusion so far is that a TLS fingerprint cannot be formed solely by BAS (Chromium). TLS fingerprinting also depends on system-level OS behavior, where the browser + OS + network stack + hardware timing together create the final observable fingerprint.
In this process, the protocol-level fingerprint (from Chrome/Chromium) stays consistent, but OS-level packet timing, TCP implementation, congestion control, jitter, and data buffering influence the actual TLS identity.
I do see one possible direction — but this would require building a larger ecosystem where the proxy environment can either emulate or preserve OS-level network characteristics. That’s ongoing R&D, and we’ll see how it evolves.
At least one confusion is now clearly resolved: as per my current knowledge, modifying only BAS (Chromium) to produce different realistic TLS fingerprints does not seem practically feasible unless the OS-level signals are also replicated or manipulated.
(all are translated hindi to english )
@Int64 https://github.com/0x676e67/rnet good tls library.
@tersinemuhendis My module is the same)
@Int64 Having the same boardingssl doesn't mean you're doing the same operations, my friend. Chrome also uses boardingssl, so that doesn't mean your module works the same with Chrome.
@tersinemuhendis omg 😲 read the module description carefully or give me real facts
@usertrue said in TLS Fingerprint основная проблема BAS:
@Int64 пусть изобретают свой велосипед, не трать время на них.
//режим старпера on
Люди слишком доверяют своему мнению, если взять и проверить снаружи свою гипотезу, то будет в сразу видно что происходит.
//режим старпера off
