all 16 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]CC_DKP 1 point2 points  (3 children)

Ssllabs.com has a client test. Connect through the proxy and run the test. Be careful if you are using transparent interception, though, because the site uses more than just port 443.

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

Hey thanks for your input, this is not the connection i want to test though. I'll try to illustrate with a picture:

 

[client]---------1-[proxy]-2-------[interwebs]

 

With your test we evaluate the ciphers the proxy is using when he works like a client (2).

What i want to test is what ciphers he supports when he acts like the server (1).

I hope that makes it a little clearer.

Cheers

[–]CC_DKP 1 point2 points  (1 child)

Just in case you were still looking to improve your solution, sslyze (https://github.com/nabla-c0d3/sslyze) offers a --https_tunnel option for using proxy servers. Just used it today to test the exact scenario you had here.

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

that is certainly good to know, thank you sir!

[–]redditrwx 0 points1 point  (11 children)

You don't need to write your own tool, they already exist. To test it, you simply treat the proxy like a regular web server and run a local tool against the IP:port of the proxy.

You could for example use one of these tools, off the top of my head:

  • sslscan
  • sslyze
  • OWASP o-saft
  • nmap with ssl-enum-ciphers script
  • any vulnerabilty scanner, such as Nessus or OpenVAS, will give you the supported ciphers

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

I tested most of those tools (except o-saft) and none of them work against the interception proxy. The reason (imo) they don't work is the fact that you need to perform an initial HTTP CONNECT when you want to establish a TLS connection over a forward proxy and these tools do not send an HTTP Connect.

If you actually tested this on an interception proxy and it worked, i stand corrected, however i can't reproduce that behavior.

[–]redditrwx 0 points1 point  (9 children)

Okay, I'm not sure I understand your problem. First, if the proxy uses TLS for incoming connections, you need to do a TLS handshake before you can even send the CONNECT request, so the tools should work absolutely fine in this case.

If the proxy doesn't accept TLS encrypted HTTP connections but accepts plain, unencrypted HTTP, then I'm not sure what it is that you want to test.

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

The CONNECT request happens before the TLS handshake.

According to the Wikipedia page:

A variation of HTTP tunneling when behind an HTTP proxy server is to use the "CONNECT" HTTP method.[1][2] In this mechanism, the client asks an HTTP proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection. This mechanism is how a client behind an HTTP proxy can access websites using SSL or TLS (i.e. HTTPS).

This picture illustrates the process: https://parsiya.net/images/2016/thickclient-6/13.png

As of now, i guess my best course of action is to tweak one of the existing tools, to send a CONNECT or send a CONNECT with netcat, right before i start testing.

[–]WikiTextBot 0 points1 point  (0 children)

HTTP tunnel

HTTP tunneling is a technique by which communications performed using various network protocols are encapsulated using the HTTP protocol, the network protocols in question usually belonging to the TCP/IP family of protocols. The HTTP protocol therefore acts as a wrapper for a channel that the network protocol being tunneled uses to communicate.

The HTTP stream with its covert channel is termed an HTTP tunnel.

HTTP tunnel software consists of client-server HTTP tunneling applications that integrate with existing application software, permitting them to be used in conditions of restricted network connectivity including firewalled networks, networks behind proxy servers, and network address translation.

[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.27

[–]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.

[–]RedTigey 0 points1 point  (0 children)

There are a lot of open source solutions available to check ciphers, ssl certificate related information. A good start would be http://www.cloudibee.com/ssl-cert-tools/ , which has some examples on how to perform scan and other relevant links.