Issue: TLS Proxy Handshake Weaknesses (Lack of PQC, Overkill Cipher Suite, and Legacy TLS Support)

[yahhlif]

When Reqable’s HTTPS recording/MITM is active, the TLS handshake performed by the proxy engine is less optimized and less secure compared to a direct browser connection. Specifically:

Key Exchange: It lacks Post-Quantum Cryptography (PQC) support (falling back to x25519 instead of X25519MLKEM786).

Cipher Suite: It uses AES_256_GCM_SHA384 which is overkill/resource-heavy compared to the browser's default AES_128_GCM_SHA256.

Legacy Protocols: It still enables TLS 1.0, which is deprecated and considered weak.

Steps to reproduce the behavior:

Open Reqable and start to Record and Ensure HTTPS recording/intercepting is ON.

Open a browser (Chrome/Edge) and navigate to https://browserleaks.com/tls.

Observe the "Protocol Support", "Cipher Suite", and "Key Exchange" sections.

Turn off Reqable and refresh the page to see the difference.

Expected behavior The Reqable proxy engine should ideally mirror modern browser TLS capabilities:

Support for hybrid PQC key exchange (X25519MLKEM786).

Use TLS_AES_128_GCM_SHA256 by default for better performance/standardization.

Disable TLS 1.0 and TLS 1.1 by default to follow modern security best practices.

Information

Platform: Android & Windows

OS: Android 10 / Windows 11

Arch: x86-64 (Windows) / ARM64 (Android)

App Version: 3.0.31

[MegatronKing]

Hello, I think you're referring to the SSL fingerprint mismatch issue. Reqable doesn't fully replicate the client's SSL fingerprint, including Cipher Suite, SSL extensions, etc. According to our current roadmap, this issue will be optimized in version 3.1.

[yahhlif]

Thank you for your attention, I wish you do the best for the Reqable 3.1 release. I hope it will get a lot of optimizations, performance improvements, and in my opinion, dropping unsecured TLSv1.1 (sticking only v1.2 and v1.3), using lightweight cipher suites such as prioritizing aes-128 over aes-256 (minimizing the double encryption/decryption overhead in MITM record mode), and using modern and lightweight PQC key exchanges such as X25519MLKEM786 instead X25519 only .