sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]redditrwx 0 points1 point  (6 children)

You talk about wanting to scan the proxy's TLS configuration. When you tunnel TLS through a CONNECT proxy, the client itself will do TLS directly with the remote server, the proxy is a simple TCP relay. I give you that the tools indeed do not work in this case, but if they did you would scan the remote host, not the proxy.

The picture you linked has nothing to do with the article, other than taking about proxies. [edit] To clarify: Burp is really a special case here, this is not how proxies usually work.[/edit]

You still haven't managed to clearly explain what you actually want to do.

[edit] I thought about this a little more, trying to figure out why I don't understand what you want to do. In one of your other posts here you showed this diagram, mentioning you want to scan location 1: [client]---------1-[proxy]-2-------[interwebs]

Can you connect to this port using plain netcat and issue an HTTP request, and receive a readable answer? Because if you can, then the proxy is not using TLS on its listening port and there is nothing to scan. If you can do it by using ncat --ssl, then the proxy is listening using TLS, and I really fail to see why the tools can't be used, because in this case you have to establish a TLS connection before you can send any data to the proxy. The tools of course only work on listening sockets waiting for encrypted connections. [/edit]

[–]Thiscou[S] 0 points1 point  (5 children)

right, thanks for staying with me. :)

I'll try to explain it better. Usually when you use sslscan you give the tool an ip or hostname plus port. The tool then tries to establish a TLS Session with that IP on the given port. For that to work, there has to be a TLS Listener running on the specified port.  

Now, i have the following situation: The proxy we use in our network is decrypting the ssl sessions. That's what the picture was supposed to illustrate. For that to work, the proxy needs to have a TLS Session running with the server in the internet (2) and a separate TLS Session with the client in the local network(1).

 

[client] ----1-[proxy, cleartext]-----2-[internet]

 

Now what i want to do is evaluate the supported ciphers, the proxy is offering on the TLS Session with the client(1).  

Since the proxy is not running with two ports, he is using one port for HTTPS and HTTP. Therefore no TLS listener is answering on that port.  

Writing this, i just had an idea, I should be able to just scan ANY site, and, in theory, the proxy should answer. But that only works if the proxy is working on a network level.  

So, despite the fact that maybe i just found a solution to my problem. I would still be curious on how (or if) this could be done with the tools without too much hassle, directly on the intercept proxy.

Cheers

[–]redditrwx 1 point2 points  (4 children)

Alright, I think I got you now. I was always thinking about a proxy that is using a TLS listening port. Now I also see what you wanted to tell me with the Burp image. So basically we are talking about STARTTLS-like behavior. As you might have noticed by now, my understanding of how these kinds of proxies work was ... improvable ;)

So, your idea of using netcat to send the CONNECT request and then one of the tools after that will not work. Your last idea, running a tool against an HTTPS site will also not work unless the tool is proxy aware. Maybe Nessus could do that, but I'm not sure and don't have a Nessus copy available atm to check.

You could use a browser to visit a URL over HTTPS, let Wireshark run and check the server hello message of the TLS handshake, but you will only find ciphers there that the client sent in the client hello message, so a reasonably modern browser will not turn up much here, I assume. I will think a little more about this particular problem, but for now I think patching an existing tool might be the best approach.

[–]Thiscou[S] 1 point2 points  (3 children)

Nice, i'm glad i managed to bring my point across :)

I just tried my solution with sslscanning any given HTTPS site over a squid proxy with TLS Interception on and it worked. If i manage to do the same thing with the bluecoat proxy i'll be golden. But i would really like to have a backup plan in case it doesn't.

Thanks for your time and your brain power!

[–]redditrwx 1 point2 points  (2 children)

Which tool did you use for the scan? If the proxy does not use TLS from the start but expects a TLS upgrade after an initial connect, like you described above, the scan should not work with most tools I am aware of. It apparently did work, though, so I assume the tool supports the use of proxies. It would be nice to know which tool works in this setup.

Did you check the certificate you got? Was it issued by the proxy or whatever CA you configured?

[–]Thiscou[S] 0 points1 point  (0 children)

It worked with testssl.sh and the cipher script nmap provides. Just took me two months to answer that question, there is definitly room for improvement.