Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

BApp Store and Collaborator HTTPS stopped working with 1.7.34

Udont | Last updated: Jun 22, 2018 06:16PM UTC

When using Burp internally on our corporate network, I am not longer able to update the BApp Store or use the Burp Collaborator features over our BlueCoat proxy when using version 1.7.34. When I downgrade to 1.7.33 or go directly out the issue no longer occurs. The proxy is not replacing the certificates for these sites and the correct comodo certificate is being passed to Burp. In some environments I only have proxy access to HTTPS sites, so that renders a lot of Burp useless. The errors presents itself as "Failed to update BApp list" when clicking Refresh List. And on the Collaborator Health check, Server HTTPS connection (trust enforced) gets a warning, and Polling server connection gets an error. When selecting Poll over unencrypted HTTP the polling server connection works correctly. I'm unclear what about the new MITM protection that were put into Burp has done to make this no longer work on our network. Is it possible to get more information about what these added MITM checks are actually doing so that I may be able to make some network changes to get this working again?

PortSwigger Agent | Last updated: Jun 25, 2018 07:19AM UTC

Hi, The new checks are that it's a valid certificate (chained to a trusted root, not expired, etc.) and that the host name matches portswigger.net. It sounds like the BlueCoat proxy is indeed replacing the certificate for those domains. I'm not sure how you confirmed the Comodo certificate was being presented to Burp, but I would check again. I recommend you install the BlueCoat certificate into the Java certificate store: - https://stackoverflow.com/questions/4325263/how-to-import-a-cer-certificate-into-a-java-keystore Please let us know if you need any further assistance.

Burp User | Last updated: Jun 25, 2018 12:37PM UTC

From everything I can tell there is nothing currently changing the certificate or host names. I had networking confirm and reviewed the logs. All additional CAs trusted by the OS have been added to the local java cert store for the JVM running Burp. Is there anything else that may be tripping this protection?

PortSwigger Agent | Last updated: Jun 25, 2018 12:42PM UTC

Hi, We're not aware of anything else that could cause that. It's possible that BlueCoat could be preserving the certificate but stripping the chain - although this is speculation. To investigate further, turn on SSL debugging. Start Burp like this: java -Djavax.net.debug=all -jar burpsuite_pro.jar The output will include the certificates sent to Burp. This may help you diagnose the issue, and we'd be interested to see this output too.

PortSwigger Agent | Last updated: Jun 25, 2018 01:32PM UTC

Hi, Thanks for sending the debug output. One thing to search for in the log is "Found trusted certificate". It appears you are getting the right certificate, so something else must be upsetting our checking code. Could you please run this Java class and send me the output: - https://github.com/pajswigger/check-connectivity Run it like this: java -cp . CheckConnectivity http://proxy:port The output should help us pin down what is wrong.

Burp User | Last updated: Jun 25, 2018 01:35PM UTC

Can you give me some guidance on what I should be looking for in here. I'm not finding anything highlighting any kind of warning, error, or mismatch. Are there certain keywords this type of error would generate? As far as the certs, I'm seeing the same certs getting to Burp in these logs that I see when not going through the proxy. Extension server_name, server_name: [type=host_name (0), value=polling.burpcollaborator.net] ... *** Certificate chain chain [0] = [ [ Version: V3 Subject: CN=*.burpcollaborator.net, OU=COMODO SSL Wildcard, OU=Domain Control Validated Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits modulus: 28023189687157204953638711488239069443110811319023312508505908789277717461683927370317696067771432986994325212259909586473667198063023365414311963193010225151880064899777311908111705366144990841108391178703838017849074778329083808361814105381759281784331624502978872820940219647616378178498721695682180671098229365964966704891639306341366923508018131363435450447241136376798097643006122441514702754986830169738943896492598500313506627571845030593616708644405477391142276070269146069388048649747833895953498754899414920071064462893576707635562650004144157332847615398977239628174495087810519840536510360406603839879749 public exponent: 65537 Validity: [From: Mon Feb 23 19:00:00 EST 2015, To: Sun Feb 23 18:59:59 EST 2020] Issuer: CN=COMODO RSA Domain Validation Secure Server CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB SerialNumber: [ 8f38b192 23f8198c 0ecb1c3a 495b0be9] ... chain [1] = [ [ Version: V3 Subject: CN=COMODO RSA Domain Validation Secure Server CA, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB Signature Algorithm: SHA384withRSA, OID = 1.2.840.113549.1.1.12 Key: Sun RSA public key, 2048 bits modulus: 18021508317891126045114383893640587389787314988023771299021472384098480478916503597778296613150634219765052113517870635171403307225477983047468706279013651027886500159485348697094115927961850381525182009137128777951162358715158533528593200093291791323275973789174789209802980910482500744419318360338528025872227868058578212418244189425301367382232973595110901594292490129763308095314503250053957090379265992785603931784956681691284995547158646635183735467516188519673313343149548166538558424521681954529559978463371620234598058977077392872218941503229331579208118464720991080636709101634982701306129953489796945248933 public exponent: 65537 Validity: [From: Tue Feb 11 19:00:00 EST 2014, To: Sun Feb 11 18:59:59 EST 2029] Issuer: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB SerialNumber: [ 2b2e6eea d975366c 148a6edb a37c8c07] ... chain [2] = [ [ Version: V3 Subject: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB Signature Algorithm: SHA384withRSA, OID = 1.2.840.113549.1.1.12 Key: Sun RSA public key, 4096 bits modulus: 595250832037245141724642107398533641144111340640849154810839512193646804439589382557795096048235159392412856809181253983148280442751106836828767077478502910675291715965426418324395462826337195608826159904332409833532414343087397304684051488024083060971973988667565926401713702437407307790551210783180012029671811979458976709742365579736599681150756374332129237698142054260771585540729412505699671993111094681722253786369180597052805125225748672266569013967025850135765598233721214965171040686884703517711864518647963618102322884373894861238464186441528415873877499307554355231373646804211013770034465627350166153734933786011622475019872581027516832913754790596939102532587063612068091625752995700206528059096165261547017202283116886060219954285939324476288744352486373249118864714420341870384243932900936553074796547571643358129426474424573956572670213304441994994142333208766235762328926816055054634905252931414737971249889745696283503174642385591131856834241724878687870772321902051261453524679758731747154638983677185705464969589189761598154153383380395065347776922242683529305823609958629983678843126221186204478003285765580771286537570893899006127941280337699169761047271395591258462580922460487748761665926731923248227868312659 public exponent: 65537 Validity: [From: Tue May 30 06:48:38 EDT 2000, To: Sat May 30 06:48:38 EDT 2020] Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE SerialNumber: [ 2766ee56 eb49f38e abd770a2 fc84de22]

PortSwigger Agent | Last updated: Jun 26, 2018 01:36PM UTC

Hi Nicolas, Thanks for letting us know, it's good to hear you've got this working. We are going to continue to investigate this, as the standalone jar should work, and one other user is having the same issue even when using the platform installer.

Burp User | Last updated: Jun 26, 2018 03:57PM UTC

Hi, I had the same issue on a fresh Ubuntu 18.04 install. Migration of my burp 1.7.34 from my 16.04 didn't work. SSL error happened (as seen in wireshark) on requests when doing : - burp check update - burp bappstore (refresh & download) - burp collaborator health check However the issue didn't happened when running a previous version of burp. As I strongly expect it to be a java - ssl issue, here are the things I tried: - Using different JRE I tried: openjdk11, openjdk8 and oracle java 8. - Installing the "oracle-java8-unlimited-jce-policy" package - Cleaning up the java keystore by removing and installing again the "ca-certificates-java" package. None of this helped, but I figured Burp would be bundled with a decent jre version. Using the Linux burp installer (instead of the jar file) indeed fixed the issue.

Liam, PortSwigger Agent | Last updated: Jun 27, 2018 02:55PM UTC

Just to let you know that this issue should be fixed in today's release (1.7.35). Thanks for your feedback and please let us know if you run into any other problems.

Burp User | Last updated: Jun 29, 2018 01:18PM UTC

Thanks for your help guys, 1.7.35 fixed the issue and Burp is completely usable again in our environment.

PortSwigger Agent | Last updated: Jun 29, 2018 01:34PM UTC

Hi Udont, Thanks for letting us know about this. We recommend running Burp with Oracle Java. While it can work with OpenJDK you are likely to run into a number of problems, including what you mentioned. We will look at this issue at some point, but not at high priority.

Burp User | Last updated: Jul 03, 2018 04:54PM UTC

experienced the same issue with 1.7.34 (jar file) on ubuntu 18.04. the 1.7.35 update did NOT fix the issue... the only error i see in the debug chain is this: pool-6-thread-18, handling exception: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty %% Invalidated: [Session-25, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384] pool-6-thread-18, SEND TLSv1.2 ALERT: fatal, description = internal_error pool-6-thread-18, WRITE: TLSv1.2 Alert, length = 2 [Raw write]: length = 7 0000: 15 03 03 00 02 02 50 ......P pool-6-thread-18, called closeSocket() Works fine on Kali.. doing a bit more troubleshooting now..

Burp User | Last updated: Jul 03, 2018 07:19PM UTC

tl&dr - works using oracle jre1.8.0_172. never got it to work with any version of openjdk. longer - tried update-ca-certificates, and openjdk-8. had to download the ca-certificates-mono package to get update-ca-certificates to run without error - but still no success with BApp access. downloading jre-8u172-linux-x64.tar.gz from oracle, expanding it, and just running from the jre bin directory works. Seems like the difference is in the establishment of the TLSv1.2 session...

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.