I've got a local application (which I didn't write, and can't change) that talks to a remote web service. It uses HTTPS, and I'd like to see what's in the traffic.
Is there any way I can do this? I'd prefer a Windows system, but I'm happy to set up a proxy on Linux if this makes things easier.
What I'm considering:
Redirecting the web site by hacking my hosts file (or setting up alternate DNS).
Installing an HTTPS server on that site, with a self-signed (but trusted) certificate.
Apparently, WireShark can see what's in HTTPS if you feed it the private key. I've never tried this.
Somehow, proxy this traffic to the real server (i.e. it's a full-blown man-in-the-middle "attack").
Does this sound sensible? Can WireShark really see what's in HTTPS traffic? Can anyone point me at a suitable proxy (and configuration for same)?
Does Fiddler do what you want?
What is Fiddler?
Fiddler is a Web Debugging Proxy which
logs all HTTP(S) traffic between your
computer and the Internet. Fiddler
allows you to inspect all HTTP(S)
traffic, set breakpoints, and "fiddle"
with incoming or outgoing data.
Fiddler includes a powerful
event-based scripting subsystem, and
can be extended using any .NET
language.
Fiddler is freeware and can debug
traffic from virtually any
application, including Internet
Explorer, Mozilla Firefox, Opera, and
thousands more.
Wireshark can definitely display TLS/SSL encrypted streams as plaintext. However, you will definitely need the private key of the server to do so. The private key must be added to Wireshark as an SSL option under preferences. Note that this only works if you can follow the SSL stream from the start. It will not work if an SSL connection is reused.
For Internet Explorer this (SSL session reuse) can be avoided by clearing the SSL state using the Internet Options dialog. Other environments may require restarting a browser or even rebooting a system (to avoid SSL session reuse).
The other key constraint is that an RSA cipher must be used. Wireshark can not decode TLS/SSL stream that use DFH (Diffie-Hellman).
Assuming you can satisfy the constraints above, the "Follow SSL Stream" right-click command works rather well.
You need to setup a proxy for your local application and if it doesnt honour proxy settings, put a transparent proxy and route all https traffic into it before going outside. Something like this can be the "man" in the middle: http://crypto.stanford.edu/ssl-mitm
Also, here's brief instructions on how to archive this with wireshark: http://predev.wikidot.com/decrypt-ssl-traffic
You should also consider Charles. From the product description at the time of this answer:
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information).
For using https proxy to monitor, it depends on the type of handshake. If you local application does not check the server's certificate by CA's signature which you can not fake, and the server does not check your local application's certificate ( or if you have one to setup on https proxy) then you can set up a https proxy to monitor the https traffic. Otherwise, I think it is impossible to monitor traffic with https proxy.
Another way you can try is to add instrumentation probe at the routines of your client program where it send and receive messages from its https library. It needs some reverse engineering work, but should work for you for all situations.
I would recommend WireShark, it is the best tool to follow on different pieces of traffic. Although, I am not sure what can you see with SSL turned on. Maybe, if you supply it with a certificate?
Related
I have two projects running on Wildfly-8 and I have two SSL certificates for each of them and one IP.
I figured out that I should have one IP for one SSL certificate.
But I needed to use these two SSL for one IP. I couldn't find a way to do it with Wildfly but there was a way to do it with Apache Server. So,I installed Apache Server up to Wildfly.
I listen https port(443) on Apache and redirect it to Wildfly's http port(I used 8080). It works without any problem.
What I wonder is;
1. Is Apache decrypt request and redirect it to Wildfly?
2. Is it correct way to do it or I have done it by chance?
3. Does this method create a security hole?
I googled some, but I could not find satisfied answers.
Thanks for replies.
For this answer, I'm supposing that by "redirecting" you mean "proxying": Apache receives the request, proxies it to Wildfly, receives an answer from Wildfly, sends the answer to the client.
If you mean something else, then the simple answer is: it is wrong[1].
Is Apache decrypt request and redirect it to Wildfly?
Yes. Apache will receive and send secure data to/from the client. Its communication with Wildfly will be plaintext.
Is it correct way to do it or I have done it by chance?
That's how it's usually done, yes. In other words: a load balancer and/or a proxy in front of Wildfly (Apache in your case). Wildfly itself is not reached directly by the public internet.
Does this method create a security hole?
It does, just like everything else is a security "compromise". In this case, you are trusting your internal network, in the name of a more practical/manageable architecture. If you do not trust your internal network, you should look for another solution. In the general case, the price to pay seems fair to me, as you'll "only" be open to a man-in-the-middle between your Apache and your Wildfly. So, if you trust your internal network, you should trust that there won't be any MITM there.
Edit
[1] - As everything else in life, there's no absolute truth. Basically, there are 3 techniques that can be used in a scenario like this: pass through, edge and re-encryption.
Pass through is a "dumb" pipe, where nothing about TLS is known by the proxy. Wildfly would then handle the secure communication with the client. I'm not sure Apache would do this, but this can be done with haproxy in TCP mode;
Edge (or offloading) is the situation I described above: Client talks TLS with Apache, Apache talks plaintext with Wildfly;
Re-encryption, which is like Edge, but the communication between Apache and Wildfly is also TLS, using a different certificate.
I've been wanting to setup a linux VirtualBox instance and use iptables to route traffic from other VMs through it and on to an external SOCKS proxy server. However, I have recently read that transparent proxies like this break HTTPS transmissions and that this is part of the design – to prevent man-in-the-middle attacks. If I want this to work, I'll need to configure the proxy inside the browsers of the VM clients for port 443. Are there any other options I could explore to achieve my goal?
To access a SOCKS server each TCP connection must be prefixed with the necessary SOCKS header. That means, that a simple redirect is not possible. You need instead a protocol converter like redsocks or transocks (never used these, but from the description they do what you need).
Apart from that it is not a problem to simply redirect HTTPS traffic or use these protocol converters, as long as you don't change the SSL stream itself. The only problem is if transparent proxies try to intercept and re-route this traffic to other sites (like redirecting to a capture portal) or try to decrypt the connection in order to analyse it (like in firewalls). These kind of interceptions will be noticed from the browser, because either the name in the certificate does not match the target name and/or the issuer of the certificate is not trusted.
I've created WCF Service and I share it via ssl. I have little knowledge about security, but I'm curious why can I see whole communication as a plain text in httpAnalyzer, even though POSTs are sending via https?
When my client application invokes wcf service, then I can see it in sniffer - passwords etc.
Does it mean that SSL works only on the lower layer - while transporting data? So every evil application can sniff communication on client's side and an encryption only secures us against man-in-the-middle?
SSL works indeed on a "lower layer" than HTTP. According to the OSI Model, SSL works on the Session Layer, while HTTP is on the Application Layer.
Most of these clientside HTTP Analyzers work from within the browser, analyzing the HTTP traffic on the application layer, before it is processed by the SSL logic. So it is completely normal to see the plain HTTP request.
Concerning security, an evil application installed within the browser can indeed read upon the traffic. But once it is processed by the SSL layer, it becomes way harder for an evil application to read the traffic.
SSL works by firstly authenticating the server to you as a client. (Do I talk to the one I really want to talk to). As you can't know all of the servers and their certificates before hand, you use some well known root certificates, which are pre-installed on your OS. These are used to check if some server is perhaps known by an already well known service. (I don't know you, but some really important server tells me that you indeed are who you say you are).
This authentication step works independent from the encryption of the traffic. No program can decrypt an arbitrary SSL stream by "installing a root certificate". (As said these root certificates are already on your machine from the first moment you install an OS on it =)
But if a evil programs is able to let you believe that you are talking to a legitimate server, using a forged root certificate for example, instead of actually talking to malware, it is able to see what the contents of the SSL traffic is. But then again, you are talking to the evil program itself, not the server you were intended to talk to. This is however not the case with HTTP Analyzer
This is in short terms how SSL works and hopefully answers your question.
Most likely HTTP analyzer install it's own root certificate, and intercepts SSL traffic, working as man-in-the-middle.
So I've gone ahead and set up my ShoutCast server DNAS and set my DSP in Winamp on my host computer. The server listens on port 8000, so per some instructions I installed an output plugin for winamp (Shoutcast DSP) and used 8000 and the password to connect. Server accepts the connection.
Now, what the heck do I do now? My host computer is SSL secured and the DNAS server is installed within the secure web directory (if that matters). My desired end result is that I want to listen to my ShoutCast setup at home (host computer) from any computer.
I try browsing to my ip address and port 8000 (without using HTTPS) and it comes back with nothing. If I browse with HTTPS://my.server.com:8000, I get Error code: ssl_error_rx_record_too_long)
Have I completely missed something, or am I just a total moron?
Thanks.
SHOUTcast doesn't support SSL. The service on port 8000 is an unencrypted server for HTTP and ICY (the rather pointless SHOUTcast native streaming protocol, which is almost but not quite HTTP). The ssl_error_rx_record_too_long error is characteristic of trying to access a non-HTTPS service as HTTPS.
You should be able to connect to 8000 with your web browser and get the DNAS status page. If, on the other hand, you connect to that port with a media player, it'll return the direct MP3 stream. (Unfortunately, in an incredibly boneheaded piece of design, the way SHOUTcast decides which to respond with is by sniffing your User-Agent header for something beginning with Mozilla, so if you're using an alternative browser or blocking your UA you'll not be able to get the status, and if the stream's down you might just get nothing.)
To listen to a SHOUTcast server through SSL you would need to set up a proxy on another port that forwarded HTTPS requests to local HTTP requests; it'd also have to be a streaming-capable proxy, and you might need some hacks to stop ICY breaking it.
Probably easier, you could set up an SSH forwarded port from your client to the server. That would also be the only way to allow the DJ to connect to SHOUTcast with encryption, since the DJ protocol isn't HTTP compatible at all. Obviously SSH tunnels are no good for random public listeners though.
You could also try Icecast, an alternative to SHOUTcast that I believe has some SSL support (and also uses plain HTTP streaming instead of ICY).
I need a Reverse Proxy to front both Lablz Web server and SSL VPN Adito (SSL Explorer fork) by sitting on one IP/port. Failed to achieve that with Nginx. Failed to use Adito as a generic reverse HTTP proxy.
Can HAProxy fall back to being a TCP proxy if it does not sense HTTP traffic?
In other words can it fall back to Layer 4 if its Layer 7 inspection determines this is not HTTP traffic?
Here is my setup
EC2 machine with one public IP (Elastic IP).
Only one port is open - 443.
Stunnel is sitting on 443 and is passing traffic to HAProxy (I do not like to use Stunnel but HAProxy does not have full support for SSL yet, unlike Nginx).
HAProxy must be configured to pass some HTTP traffic to one server (Apache server which fronts the SVN server) and the rest of the HTTP traffic to our Lablz Web/App server.
All non-HTTP traffic must be forwarded to Adito VPN.
This traffic is:
VNC, NX, SMB
... and all other protocols that Adito supports
I can not rely on source IP address or port to split traffic into HTTP and non-HTTP.
So, can such config be accomplished in HAProxy? Can any other reverse proxy be used for this? Let me know if I am not thinking right about HAProxy and an alternative approach is possible.
BTW, Adito SSL VPN is amazing and if this setup works we will be able to provide Lablz developers with a fantastic one-click single-login secure VNC-over-HTTPS access to their boxes in the cloud.
No solution exists for this but via Adito - please prove me wrong. But please do not say that VNC over SSH is better. Yes, VNC-over-SSH is faster, more secure, but also is much harder (for our target user base) to setup and presumes that user is behind the firewall that allows outbound traffic on port 22 (not always the case).
Besides, Adito is much more than the remote access gateway - it is a full blown in-browser VPN, a software distribution platform and more. I am not associated with Adito guys - see my Adito post on our Lablz blog.
OK, first off, I'd use a simple firewall to divide all HTTP from NON-HTTP traffic. What you need is packet inspection to figure out what it is that is coming in.
Neither haproxy or nginx can do that. They are both made for web traffic and I don't see how they could inspect traffic to guess what it is that they are dealing with.
Update: Looked into this it a bit and with iptables you could probably use string matching to devide the traffic. However, that's all tricky, especially with the encrypted nature. A friend of mine discovered l7-filter and this looks like what you need. Let me know if this helps.