Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got a bit of a tricky application I need to monitor. Its a Java .jnlp file. Using Process Monitor, I've been able to identify it (its instance of javaw) going out to the other servers in my network; however, running Fiddler, it shows no activity what-so-ever. I do know the traffic is HTTPS encrypted, and it appears to be connecting on ports which my servers are running web servers (tomcat). With Process Monitor I can see the length and direction (send/receive) that the data is going, but it doesn't even show me the encrypted contents.

I'm wondering, if there is any way I can man-in-the-middle this program to see what data its sending from my machines?

update

The server software that this jnlp is communicating with, is installed as a "package" and I have not been able to find any SSL certificate files within the directory of this application. I've used Wireshark, but without the private keys, I haven't been able to decrypt the traffic.

The solution with a VM Gateway running some proxy (other?) software seems the easiest to implement, how would you go about deploying that solution with Virtual Box?

share|improve this question
add comment

3 Answers

up vote 2 down vote accepted

Fidler isn't a sniffer-- it's a proxy. Unless you can get the offending application to use a proxy none of its traffic is going to run through Fiddler.

Microsoft Network Monitor will show you the encrypted traffic, as will Wireshark. Network Monitor 3.x versions have the nice touch of being able to filter based on process (since they're "tightly coupled" with the OS).

AFAIK, Java applications don't use the operating system's SSL "stack", so interception utilities that shim into the Windows SSL stack aren't going to be helpful either.

Presumably the remote servers aren't running an SSL stack that's easy to snoop inside (since you say they're running Tomcat, and also not likely using the OS SSL stack).

I'd run the offending program in a VM w/ a Linux-based VM acting as its default gateway. You could then use some iptables NAT rules to redirect the connection attempts to a HTTPS-to-HTTP proxy that, in turn, forwards the request on to an HTTP-to-HTTPS reverse proxy and, ultimately, to your servers. You would be able to log the traffic when it's in an HTTP state between the proxy and reverse-proxy servers. It's not elegant (and somebody else can probably think of a cleaner method that uses fewer moving parts) but you could do the whole thing with off-the-shelf software (I'd probably use a couple instances of nginx). Presumably the offending application isn't authenticating that it's actually talking to your servers but, if it is, you could just export the SSL certs and private keys from your servers to make the deception "complete".

Assuming you've got the SSL private keys from your servers and you don't configuring your servers' SSL to do RSA-based key exchange you could just capture the traffic and decrypt it with Wireshark.

share|improve this answer
    
So, if I set my gateway to a VM thats running a HTTPS-to-HTTP proxy, I could theoretically intercept the requests? Any information on what I might run in this VM Gateway? I've never used nginx... is it easy to setup in a Virtual Box VM? –  Nate Mar 1 '11 at 21:08
    
@Nate Bross: I'm talking about using iptables NAT to redirect the requests to the proxy. Just setting your machine's default gateway to a VM running an HTTPS-to-HTTP proxy won't be enough. You'll need a NAT implementation to perform the redirection at layer 3. Unfortunately, I'd suspect that you've got a fairly steep learning curve ahead of you to go that route if you're not already familiar with redirecting and proxying traffic like this. –  Evan Anderson Mar 1 '11 at 21:12
    
Do you have any links or advise on where to get started? (Operating on your correct assumption that I don't have much experience with this?) –  Nate Mar 1 '11 at 21:14
add comment

Install wireshark on the server

share|improve this answer
add comment

Wireshark is able to decrypt SSL traffic, as long as you provide it with the private key. If you go to Edit->Preferences, then choose SSL from the list of protocols, there's a field to enter the location of a private keyfile, as well as the IPs and Ports it should be used with. Googling will give you plenty of walkthroughs, if you need more. (eg: http://support.citrix.com/article/CTX116557)

This certainly assumes that you have access to the private keys for the servers your application is talking to. But if that's the case, you should be able to pull this off without too much of a problem.


--Christopher Karel

share|improve this answer
1  
Remember that this will only work if the server is doing RSA-based key exchange. Diffie-Hellman has perfect forward secrecy and is protected from eavesdropping attacks even if the attacker has the server's private key. –  Evan Anderson Mar 1 '11 at 21:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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