I’ve just started testing a new product. The traffic was redirected to the transparent Burp Proxy by altering the DNS response, but the traffic wasn’t showing up in the HTTP history.
It was then I saw the “Alerts” tab was orange, and this message was showing:
The client failed to negotiate an SSL connection to blah.com:443: no cipher suites in common
This is an embedded device – they often have a much more limited set of ciphers supported. Unfortunately Burp gave no hint of which suite was being request.
Crack open Wireshark, and we see
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA
And indeed, this wasn’t listed on the SSL ciphers in Burp.
Turns out this cipher is controlled by export restrictions and not distributed with the normal JRE.
To resolve this, firstly, make sure you have Oracle JRE installed. Follow the instructions I have posted before. 8 seems to be the best version – 9 still causes a lot of quirks. OpenJDK just doesn’t cut it with Burp unfortunately.
The google for “JCE 8” (or whichever version you have). You will get to a download for the Java Cryptography Extensions:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Download the zip, and unzip it to:
/usr/lib/jvm/java-8-oracle/jre/lib/security
Replace the 8 with your version. It will overwrite two files, back them up if you think you need to.
Restart Burp and you should now be able to intercept traffic.
Matt South
May 5, 2016 at 7:43pmNice one! I looked for an answer to this for hours. Thanks for sharing!