Is your feature request related to a problem? Please describe.
Yes. Currently, Reqable's TLS handshake fingerprint significantly differs from modern browsers (like Chrome), causing two major issues:
- Detection & Blocking: WAFs and Anti-bot systems (e.g., Cloudflare, Akamai) easily detect Reqable as a "bot" or "suspicious client" because the JA3/JA4 fingerprint is distinctively different from a standard browser.
- Inaccurate Debugging: Servers may serve different content or behave differently when they detect non-browser TLS parameters (downgrading security or blocking requests entirely).
Based on my analysis using BrowserLeaks:
- Reqable enables TLS 1.0 (weak/deprecated), while Chrome disables it.
- Reqable lacks GREASE (Generate Random Extensions And Sustain Extensibility) support.
- Reqable prioritizes AES-256 over AES-128 (unlike Chrome), heavyweight cipher suite order.
- Reqable does not support Post-Quantum Key Exchange (X25519MLKEM768) yet.
Describe the solution you'd like
I propose updating the TLS handshake stack to better mimic modern browser behaviors. Specifically:
Change Cipher Priority:
Please prioritize TLS_AES_128_GCM_SHA256 (0x1301) over TLS_AES_256_GCM_SHA384.
Reason: Chrome prioritizes AES-128. Using AES-256 as the top pick creates a distinct JA3 fingerprint that triggers WAF blocking. Additionally, AES-256 adds ~40% unnecessary CPU overhead (14 rounds vs 10 rounds) which is costly during the double-encryption process of MITM.
Implement GREASE:
Inject random values (e.g., 0x0a0a) in Cipher Suites and Extensions. The lack of GREASE is the easiest way for servers to detect Reqable as a bot/tool.
Modernize Defaults:
Disable TLS 1.0/1.1 by default to match browser security standards.
Add support for Post-Quantum Key Exchange (X25519MLKEM768).
Support compress_certificate (Brotli).
Describe alternatives you've considered
AdGuard System-Wide: I tested AdGuard, and it successfully mimics Chrome's TLS stack (including GREASE and MLKEM), allowing it to bypass WAF detection. However, AdGuard is not a developer debugging tool like Reqable.
Alternative Proxy: Using standard proxies doesn't allow for the deep inspection and rewriting capabilities that Reqable offers.
Additional context
Here is the comparison data I collected using browserleaks.com/tls:
- Normal Chrome:
- TLS 1.0: Disabled
- GREASE: Present (0x0a0a)
- Key Exchange: X25519MLKEM768 (0x11ec)
- Top Cipher: TLS_AES_128_GCM_SHA256
- Reqable MITM (Current Behavior):
- TLS 1.0: Enabled (Weak) -> This is a red flag for security systems.
- GREASE: Missing -> Major indicator of non-browser client.
- Key Exchange: x25519 (0x001d) -> Not modern Browser default.
- Top Cipher: TLS_AES_256_GCM_SHA384 -> Costly during the double-encryption process of MITM(HTTPS Debug ON).
- Cipher List: Includes legacy DHE and RSA key exchanges (NO PFS), making the list unusually long compared to browsers.
By implementing these changes, Reqable would become a much more powerful tool for debugging modern, protected web applications.
Normal Chrome TLS:
Chrome TLS through Reqable:
Is your feature request related to a problem? Please describe.
Yes. Currently, Reqable's TLS handshake fingerprint significantly differs from modern browsers (like Chrome), causing two major issues:
Based on my analysis using BrowserLeaks:
Describe the solution you'd like
I propose updating the TLS handshake stack to better mimic modern browser behaviors. Specifically:
Change Cipher Priority:
Please prioritize TLS_AES_128_GCM_SHA256 (0x1301) over TLS_AES_256_GCM_SHA384.
Reason: Chrome prioritizes AES-128. Using AES-256 as the top pick creates a distinct JA3 fingerprint that triggers WAF blocking. Additionally, AES-256 adds ~40% unnecessary CPU overhead (14 rounds vs 10 rounds) which is costly during the double-encryption process of MITM.
Implement GREASE:
Inject random values (e.g., 0x0a0a) in Cipher Suites and Extensions. The lack of GREASE is the easiest way for servers to detect Reqable as a bot/tool.
Modernize Defaults:
Disable TLS 1.0/1.1 by default to match browser security standards.
Add support for Post-Quantum Key Exchange (X25519MLKEM768).
Support compress_certificate (Brotli).
Describe alternatives you've considered
AdGuard System-Wide: I tested AdGuard, and it successfully mimics Chrome's TLS stack (including GREASE and MLKEM), allowing it to bypass WAF detection. However, AdGuard is not a developer debugging tool like Reqable.
Alternative Proxy: Using standard proxies doesn't allow for the deep inspection and rewriting capabilities that Reqable offers.
Additional context
Here is the comparison data I collected using browserleaks.com/tls:
By implementing these changes, Reqable would become a much more powerful tool for debugging modern, protected web applications.
Normal Chrome TLS:
Chrome TLS through Reqable: