The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

TLS Error: Insufficient buffer remaining for AEAD cipher fragment

Doby | Last updated: Jul 28, 2021 02:12PM UTC

I'm getting the error, "The client failed to negotiate a TLS connection to x.x.x.x:8080: Insufficient buffer remaining for AEAD cipher fragment (2). Needs to be more than tag size (16) It's said to be an OpenJava bug but I'm wondering if it's hinting to a problem I've been struggling with for some time. I'm trying to intercept an Android app that communicates via HTTP on ports 8888, 6698 and 6699. I'm using Kali Linux, routed the ports of interest to a transparent listener port and arpspoofing the android device. CA certificate installed on Kali and Andriod (user and system). I'm currently using the latest version of Community Burpsuite (Jar) and OpenJava version 17 but I've tried loads of previous Burpsuite builds as well as Open Java 16, 13 and 11. Browser traffic works. Other apps work. It's just this app that's the problem. I've tried the NoPE extension as suggested before but it's not applicable, I know the traffic is HTTP (I can see HTTP headers in wireshark on said traffic) and I know the ports being used, therefore NoPE is of no use. I've tried to dictate the TLS versions BurpSuite uses, but it has no effect. On previous versions of burpsuite/openjava I get the error unknown_ca instead. I've tried every certificate unpinning solution available and none of them solve the problem, I therefore don't think it's a certificate issue. Could it be that the server is only trying to negotiate the handshake with TLS 1.3 cipher TLS_AES_256_GCM_SHA_384 which uses AEAD and therefore fails? I'm really trying to figure out where the problem is originating because at this point after exhausting every certificate unpinning solution, I'm out of Ideas.

Doby | Last updated: Jul 28, 2021 10:54PM UTC

Update: Disregard the last part, after some fiddling I'm no longer getting TLS errors although the problem is not resolved, the server is returning 503 Server Temporarily Unavailable errors. Using mitmproxy I can see the error 'Certificate verification error for [hostname]: self signed certificate (errno: 18, depth: 0) Presumably the server doesn't trust the certificate I've provided because it's self signed? How do I get around this? I'm using the client certificates feature to send the server a client certificate signed by my CA.

Ben, PortSwigger Agent | Last updated: Jul 29, 2021 05:38PM UTC