Auto tls fingerprint

[VovkoO]

Hi! I have added functionality that automatically retrieves tls fingerprint from the request and uses it. To do this, another proxy server is raised, which stands up before burp and catches tls fingerprint. I hope you find this functionality useful

[sleeyax]

Hey thank you for your efforts, that's a really cool idea I haven't even considered!

However, I'm a little concerned it might over-complicate this burp extension. Some people are already confused by the listener address alone, I'm sure there will be more confusion if there's 3 different kind of addresses in the extension settings.

I hope we can figure something out to make this feature easy to use and understand. Perhaps it can be hidden away as an advanced feature? Or maybe it's more useful as a standalone tool, like capture the fingerprint and then copy laste the hex string in the custom fingerprint field you added last time?

Let's think about this.

[VovkoO]

it seems to me that it's a good idea to make a new tab with advanced settings using JTabbedPane. if I understand you correctly, then the second option will not simplify, because you will still need to add a new address for proxy that will capture fingerprint.

[VovkoO]

What do you think?

[sleeyax]

Hey, sorry for the slow response time. I'm busy with other projects. I'd like to further look into your PR before making a decision. I'll try to free up some time tomorrow!

[sleeyax]

First of all, can you explain in detail what these different addresses are for so there's no misunderstanding:

• Intercept proxy address
  • I assume this is the extra proxy address that captures the TLS fingerprint?
• Burp proxy address
  • I assume this is needed for the intercept proxy to forward traffic to?
• Emulate proxy address
  • Is this what is currently known as the 'listener address'? If so, please keep that name.

Secondly, can you elaborate a bit more on the use case for this feature? In what scenario would it be useful, what's the usual setup like etc.

Finally, I'd rather avoid listening on multiple interfaces if possible. Correct me if I'm wrong but I think this feature is mostly useful in specific scenarios and therefore it should be an option that's turned off by default. An option like 'enable capture fingerprint mode' in settings which in turn opens a submenu with the associated address settings would be nice.

[sleeyax]

Another question that springs to mind; will Awesome TLS still work the same way when this feature is enabled? For example, let's say I don't connect to the intercept address and point my browser to the burp listener address instead, does it still apply the selected fingerprint like before?

[VovkoO]

First of all, can you explain in detail what these different addresses are for so there's no misunderstanding:

• Intercept proxy address

  • I assume this is the extra proxy address that captures the TLS fingerprint?

• Burp proxy address

  • I assume this is needed for the intercept proxy to forward traffic to?

• Emulate proxy address

  • Is this what is currently known as the 'listener address'? If so, please keep that name.

Secondly, can you elaborate a bit more on the use case for this feature? In what scenario would it be useful, what's the usual setup like etc.

Finally, I'd rather avoid listening on multiple interfaces if possible. Correct me if I'm wrong but I think this feature is mostly useful in specific scenarios and therefore it should be an option that's turned off by default. An option like 'enable capture fingerprint mode' in settings which in turn opens a submenu with the associated address settings would be nice.

You got it right, that's what these addresses are for. It can be useful when antibots check only a certain set of fingerprints, so as not to search for them additionally in wireshark, and then specify it in the extension settings. Maybe this will make the process easier for some people. The idea about submenu is cool, I'll try to implement it.

[VovkoO]

Another question that springs to mind; will Awesome TLS still work the same way when this feature is enabled? For example, let's say I don't connect to the intercept address and point my browser to the burp listener address instead, does it still apply the selected fingerprint like before?

Yea, it will work, it does not affect the default usage in any way. In any case, if it failed to get the intercepted fingerprint, it will use the one specified in the settings. So even if you pressed checkbox to use intercepted fingerprint, but at the same time you will use the burp address, it won't break.

[VovkoO]

I will look at other issues later, when I have free time

[VovkoO]

Skimmed through the PR and left some initial comments.

On another note, the intercept TLS proxy is missing some proper error handling. In production, users of this extension don't have access to any logs other than the Burp extension log. If something goes wrong, the extension will just stop working with no clear indication as to why. Maybe you can try to forward error messages from the intercept proxy to burp via the established connection somehow?

One of the options, its not really nice. We can do requests with errors from itercepted proxy thtought burp. So it wold be look like that:

[sleeyax]

Skimmed through the PR and left some initial comments. On another note, the intercept TLS proxy is missing some proper error handling. In production, users of this extension don't have access to any logs other than the Burp extension log. If something goes wrong, the extension will just stop working with no clear indication as to why. Maybe you can try to forward error messages from the intercept proxy to burp via the established connection somehow?

One of the options, its not really nice. We can do requests with errors from itercepted proxy thtought burp. So it wold be look like that:

Looks a bit weird like this but I suppose there's no other way to communicate errors... For added readability you can prefix it with a 'key' like Awesome TLS intercept error: and intercept that at the Java code part (burp instance) to write the error to the extension error log too.

[VovkoO]

Hey, can you please explain me why do you generate С wrapper for go code, isn't it easier to build go and call it as command line tool from java? Maybe this way it would be easier to read stdout of go program from java and write it to extension logs.

[sleeyax]

Hey, can you please explain me why do you generate С wrapper for go code, isn't it easier to build go and call it as command line tool from java? Maybe this way it would be easier to read stdout of go program from java and write it to extension logs.

Hmm wont that require a separate binary to be installed somewhere on the system? I find plug and play important; I want people to be able to install the jar file and be done with it. I don't think you can include executables in the jar file and call it like a CLI program without extracting those executables to a location first.

Also, the current approach technically allows you to run the go server on a different device or VPS and allows you to connect burp to it. I don't exactly have this documented as a feature, but maybe people would have a usecase for that.

That being said, and ignoring that last part, I've been thinking about revisiting the current approach too. Maybe there's no need for a server in the first place and it's possible to return the whole HTTP response as a byte array in CGO, decode it in Java and show it directly in burp with correct header order etc. I don't quite remember because it's been a while, but I think there were some limitations at the time making a direct approach like that impossible, which is why it's currently implemented the way it is.

Either way, if you want to experiment please create another branch (and perhaps open a new issue as well if you want to discuss this further). See also #25, perhaps the new Burp API allows for more possibilities in this regard.

[VovkoO]

Another option to log golang errors in Burp is to do something like that. Write function if go, that will accept errors from chan, export that function to java using cgo, and call this function in for loop in java in thread, and log them. What do you think about this idea, isnt it a crutch?

func getLogs() string { err := <- errChan return err }

[sleeyax]

That solution sounds too hacky to me.

For the time being I think my comment above is the best shot at resolving this error handling issue the clean way. Assuming it's possible to redesign the project like that though...

[VovkoO]

Hey, can you please explain to me how to regenerate $$$setupUI$$$ func, I tried several options and it didn't work out

[sleeyax]

Hey, can you please explain to me how to regenerate $$$setupUI$$$ func, I tried several options and it didn't work out

Is that part of the GUI? You should be able to open and edit it in Intellij IDE's GUI designer in that case. I can't recommend other options to modify it.

[sleeyax]

A drag-and-drop designer should open when you open SettingsTab.form in IntelliJ IDE:

I'm not very experienced with Java GUI design and frankly I don't wanna bother learning it for the sake of this project alone. So this is how I did. Sorry but I don't know of other ways to modify it graphically.

[sleeyax]

So when you make a change in the designer and save/compile I think it should regenerate $$$setupUI$$$.

[VovkoO]

Ohh ok, i tried the same way, but setupUI does`nt want to regenerate

[VovkoO]

I did it, it only worked when I opened src > home > java > burp, not root directory

[VovkoO]

what do you think about such design?

[sleeyax]

Much better! One thing, move 'use intercept address' to the top of advanced settings and make sure it's a checkbox that can be checked and unchecked.

[VovkoO]

Hi! I resolved your comments. Added advanced settings. Added error handling in intercept proxy printing it in requests and also intercepting it in java and printing in plugin errors

[sleeyax]

Awesome, I'll have a secondary review somewhere this week. Ping me if I forget.

[VovkoO]

Hi, did you have time to test?

[sleeyax]

Hey, sorry for the delay in testing.

I just built a local jar and get the following error when I load the extension in Burp:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7fb618615cf7]

goroutine 17 [running, locked to thread]:
net.SplitHostPort({0x0, 0x7fb8a86808a0})
        /usr/lib/go/src/net/ipsock.go:180 +0x57
net.(*Resolver).internetAddrList(0x7fb61891f2b0?, {0x7fb61891f2b0, 0x7fb618ba24a0}, {0x7fb6187de0c0, 0x3}, {0x0?, 0x1c00022fbd0?})
        /usr/lib/go/src/net/ipsock.go:257 +0x13b
net.(*Resolver).resolveAddrList(0x1c000102d00?, {0x7fb61891f2b0, 0x7fb618ba24a0}, {0x7fb6187de732, 0x6}, {0x7fb6187de0c0?, 0x1c00022fc50?}, {0x0, 0x7fb8a86808a0}, {0x0, ...})
        /usr/lib/go/src/net/dial.go:282 +0x405
net.(*ListenConfig).Listen(0x1c00022fcd8, {0x7fb61891f2b0, 0x7fb618ba24a0}, {0x7fb6187de0c0, 0x3}, {0x0, 0x7fb8a86808a0})
        /usr/lib/go/src/net/dial.go:716 +0x7e
net.Listen({0x7fb6187de0c0?, 0x7fb6187de003?}, {0x0?, 0x7fb61891be78?})
        /usr/lib/go/src/net/dial.go:806 +0x47
server.StartServer({{0x0, 0x0}, {0x0, 0x0}, {0x0, 0x7fb8a86808a0}})
        /home/quinten/Programming/java/burp/burp-awesome-tls/src-go/server/server.go:116 +0x325
main.StartServer({0x0?, 0x1c000094e20?}, {0x0?, 0x1c000118000?}, {0x0?, 0x7fb61850a801?})
        /home/quinten/Programming/java/burp/burp-awesome-tls/src-go/server/cmd/main.go:35 +0x66
[1]    67551 IOT instruction (core dumped)  burpsuite-pro

I don't get this error when building from the main branch, so it must be related to your changes. Can you look into it?

[VovkoO]

fixed it and also added pipline for mac m1 in build.sh

[VovkoO]

also i will need to test some cases.

[sleeyax]

fixed it and also added pipline for mac m1 in build.

M1 support should have been a different PR as it's a different feature/change. I'll let it slide for now.

[sleeyax]

I'm testing again and did a clean install of the extension with latest changes from this PR and I get the following error message:

newInterceptProxy, err: listen tcp 127.0.0.1:8886: bind: address already in use

Now maybe this address is in fact already occupied on my system but I don't think it should prevent me from using Awesome TLS altogether because the intercept proxy is a feature I haven't even enabled yet. Do you think it's possible to make changes so that the intercept proxy listener is only spawned when the feature is enabled (after the user presses the save changes button)? That way, if this same error happens users can adjust the listener port and try again.

[sleeyax]

I'm sorry, but I can't accept these changes right now. Feel free to open another or reopen this PR with the remaining comments and concerns addressed. Also keep in mind that Mac M1 support has already been merged in another PR so you should rebase your changes.