Add TLS Fingerprint Mimicry to darkflare-client using uTLS Project

[sinnet3000]

Based on research into tools like Xray, the Go crypto/TLS ClientHello fingerprint is highly unique, making it easier for traffic analysis systems to detect and block.

To improve stealth in darkflare-client, the uTLS project could be integrated. This project allows for mimicking TLS fingerprints used by popular browsers (e.g., Chrome) and operating systems, enabling traffic from darkflare-client to blend in with regular user traffic.

Benefits:
• Better Stealth: Makes darkflare-client traffic harder to detect or block.
• Customizable Options: Users could select different fingerprints to suit specific needs or scenarios.
• Increased Resilience: Reduces the likelihood of detection, flagging, or throttling in restrictive environments.

Proposal:
Implement uTLS within darkflare-client to allow dynamic selection of browser or OS-like TLS fingerprints, enhancing the tool’s robustness and usability in challenging network conditions.

Reference: https://github.com/refraction-networking/utls

[w2035]

I'm curious why you're interested in VPNs?
I thought only people in blocked countries like China were interested in them.

[doxx]

This makes sense. I'll take a stab at that later this week. I also need to make origin to CDN TLS support for https connections.

[doxx]

This is next on the list. I just implemented full TLS/SSL support on the origin side of the server. It's been tested end-to-end with CloudFlare and seems to be very happy both in HTTPs to CDN -> CDN HTTP or HTTPs -> Origin.

[doxx]

Hey question... does it make sense to only implement this in the client side?

[doxx]

I just pushed this...

transport := &http.Transport{
TLSClientConfig: &tls.Config{
MinVersion: tls.VersionTLS12,
// Add these settings to mimic Chrome's TLS fingerprint
CurvePreferences: []tls.CurveID{
tls.X25519, // Chrome prioritizes X25519
tls.CurveP256,
tls.CurveP384,
},
CipherSuites: []uint16{
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
},
PreferServerCipherSuites: false,
SessionTicketsDisabled: false,
InsecureSkipVerify: false,
},
MaxIdleConns: 100,
IdleConnTimeout: 90 * time.Second,
DisableCompression: true,
ForceAttemptHTTP2: true, // Enable HTTP/2 support like Chrome
}

Sets specific curve preferences matching Chrome's order
Configures cipher suites to match modern browser preferences
Enables HTTP/2 support
Uses settings that more closely match browser behavior
While this won't make the fingerprint identical to Chrome (as Go's TLS stack has some inherent characteristics), it will make it less distinctive and more browser-like. For even better fingerprint matching, I need to use utls, but this change provides a good balance of improved stealth without adding external dependencies. Also utls might require a full re-write of the entire application.

[sinnet3000]

Hey question... does it make sense to only implement this in the client side?

Yes, that is correct. Only the client sends the ClientHello message in the TLS handshake. Very excited that you took a stab at this!!

[doxx]

I've started a discord chat if you guys want to chat more about this: https://discord.gg/7wVKeP88