I recently started using a security tool (Burpsuite 1.5) which has a free licence and a professional one. Upon downloading the free one from its vendor web-site (I am using BackTrack), I noticed within my Wireshark that every time I launch the tool, a TLS connection is made to the vendor’s IP on their port 443. This connection stays open and exchanging information for as long as the tool is kept open. Because I do not know what is being transmitted I blocked the outgoing traffic on my firewall to this IP: this did not impact on its usability. It might be paranoia, ignorance or both, but I don’t think I want this to be happening.

I have spent a couple of hours’ worth of research to see if the vendors would say anything about, which led me nowhere: perhaps I have not searched correctly, but I am intrigued by this from a learning point of view (and from a security perspective too, but to a lesser degree in this case). I have not directly contacted the vendor yet, mainly because I want to learn about it first, so my apologies if this is out of scope in here. However, a question if I may:

Is there a way of finding out what this is being sent?

Is there a more elegant way of stopping this from happening other than blocking the connection on my Firewall?

  • 3
    I'm actually quite curious about this Jan 28, 2013 at 11:37
  • A new dimension of 'security theater'... Jan 28, 2013 at 11:45
  • @DeerHunter, Well, if your username/passwords/cookies are being encrypted and sent over the channel to be sold to a third party for "analysis" purposes.....
    – Pacerier
    Jan 23, 2016 at 2:54

3 Answers 3


One thing you could look at is setting an upstream proxy in burp (either another instance of burp or a similar tool) and see if the traffic is then sent via that proxy. It may hit a problem with SSL certificate validity on the other hand might work. Assuming that it works, it would let you see within the SSL stream (although there could be further encryption of course).

To block the communication you could add an entry to your hosts file for the DNS name that it's contacting and redirect it to as one option. You could also block it on your hosts firewall or if you're running it via a chained proxy as I mentioned above, you could likely block the traffic there too (depending on which tool you use.)

Another thing I'd recommend is asking in the the PortSwigger Forums, they're usually reasonably responsive, so you could well get an answer there.

  • It seems that this should be enough to keep me busy as well as what has been posted by Thomas Pornin. Thanks @Rory.
    – Lex
    Jan 28, 2013 at 13:24

Burp Suite is written in Java; Java bytecode is easy to reverse-engineer, to the point that decompilers can be written. Looking at the entrails of Burp Suite would be the most direct way to determine what is going on.

Legal framework on reverse engineering varies, depending on the country. In Europe, it tends to be allowed as long as it is for interoperability purposes -- which does not really apply to your situation. Therefore, the safest way to determine what is going on is to ask the vendor.

Another method, which might be considered as not pertaining to reverse-engineering, would be to intercept the SSL/TLS layer. This assumes that Burp Suite does not include its own SSL/TLS code, but instead uses the support provided by Java. In the Java architecture, this uses providers; the default SSL/TLS provider being SunJSSE. Perhaps adding your own provider and registering as default would be enough; or perhaps modifying SunJSSE in your VM would do the trick. Either way, a provider you control could record the exchanged data in files. Possibly, Burp Suite not only uses SunJSSE but also the default store of "root CA" included in the JVM to validate the server's certificate; in that case, you would just have to make a CA of your own, install it, make a fake certificate for the target server, and then use Fiddler to obtain the data. This would be the fastest way to determine what is going on.

  • That's sensible. Both answers, yours and @Rory are very satisfactory. Thanks a million.
    – Lex
    Jan 28, 2013 at 13:26
  • it may be legal in Europe, but your EULA that was expressly agreed does not allow it in 2.2.6. Just pointing it out to the community because it could cause some in-house lawyers to have minor heart feailure. Jan 28, 2013 at 15:48
  • Related: blog.nibblesec.org/2013/01/…
    – Pacerier
    Jan 23, 2016 at 2:51
  • @Thomas, What's the point of making our own CA? Since the encryption is done end to end, and the encryption is done on our side of the end, why couldn't the data be decrypted (without doing stuff like setting up our own CA)?
    – Pacerier
    Jan 23, 2016 at 2:53

the first place I always go to when this sort of thing happens is the licence. It looks like 2.2.6 prevents us from reverse engineering and poking around in the javacode to see what this code does...

There is nothing else that I can see in this licence that allows call-home functionality and it's a pretty poor quality licence for not mentioning it.

  • could not agree more; which is why I have not asked this to the vendor yet: I might not believe whatever they tell me as to what this connection is doing.
    – Lex
    Jan 28, 2013 at 12:01
  • This suggestion is wrong. Licence is distinct from law, even if you live within the same jurisdiction as the code author. People can legally write anything in licence even when they can't be legally enforced.
    – Pacerier
    Jan 23, 2016 at 2:50
  • I've seen some really poor T's & C's before - however, it's important to make the distinction legally between a civil matter (breach of contract) and a criminal breach (the term is unfair, or illegal). Feb 10, 2016 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.