SSL - Trusted man in the middle

Sometimes an IT administrator needs to install a computer on the network to intercept and take action on (filter, log, virus check, etc) the browsing taking place on their network. This is apparently made impossible by SSL, as the entire point of the protocol is to make sure that no one can eavesdrop on conversations or modify messages.

My hope is that the problem of allowing an trusted MITM is common enough that the designers of SSL have somehow supported the configuration.


---

I know that I can simply put a box in the network that will issue its own certficates and then instruct people to always accept certificates, even if they are apparently bad. The problem is that this will keep us from ever detecting a connection that really is bad, and it will break SSL clients that do not prompt the user when a certificate is not perfect (ie, some antivirus applications, etc).

What I am hoping for is something like this: SSL provides for a certificate to be wrapped in a higher layer certificate. The original certificate would be wrapped inside the certificate coming from the trusted MITM. The client computer would then check the wrapped certificate against the visited URL/host etc and would complain if there were any discrepancies. It would then check the outer certificate against the list of trusted MITMs and reject the whole accept the whole transaction based on that.


I do not see anything like this in the protocol.... I would assume I'm not the only person with this request...

Does anyone have any ideas?

Thanks in advance

You can easily just buy certs for foo.com, have users connect to it, and then setup code on the foo.com server to forward messages to baz.com

It breaks the idea of SSL, but no one really expected SSL to be secure, it was a patch to keep folks from using real security.

Of course, its highly unethical for you to do this unless you own both foo.com and baz.com

Thanks for your reply.

I don't think that is exactly what I am talking about... let me try a different explanation.

End users on this network, let say employees at a company, may sign an agreement that says "IT may monitor any and all connections on network, including https connections". Now those employees go visit h t t p s://mybank.com, they might visit ht t ps://randomwebmail.com, or they might visit any other web server that serves content using https.

The 'magical' setup I am looking for is the one that would allow for these connections to be seamlessly monitored/acted upon.

Put differently, the basic SSL setup says "I trust myself, I trust my computing platform and I trust the serrver I'm connecting to, but I don't trust anyone else. I want a secure connection that can't be touched by anyone else." I'm suggesting that there ought to be a way in SSL to extend this and say "I trust myself, my platform, and this 'other guy' as though they are an extension of my computing platform. The other guy can see all my communications"


If you are curious as to why this is "needed", the short answer is that https is not just for banking and financial anymore. https is now employed by proxy sites, porn sites, etc as a way to prevent IT (network administrators, the owners of networks) from monitoring/controlling browsing and enforcing policy.

Thanks again

OK, so you are saying that all folks at phbco.com agree to be monitored, so you want someone inside the phbco.com world to go through your proxy then they go to either
https://www.bankamerica.com or
https://www.wildpornandgambling.com

Seems to me all you need is a proxy that works in all external routers from phbco.com to the world. So the connection would be something like:

user.lan.phbco.com -> proxy -> badsite.com

I haven't worked with TLS proxies in a while, so I don' tknow if you can do it transparently. Perhaps it would be better not to do it transparently. Rather just say that https is accessed by first going to
https://proxy.phbco.com and entering the URL that you really want to go to in the box on the first page.

That way, everyone knows what's going on, and can't later argue that they had expectations of privacy.

IANAL, and this feels to me to be getting into areas you should talk to good council.

That is a fine suggestion. Pointing the client workstations at a proxy would solve the problem...

Unfortunately, the customer in this situation is not able to change their workstations in that way. There are too many, they are too spread out and too frequently changing. They only thing they control is the gateway and the ability to insist that people accept a MITM's certificate.

Other suggestions?

then change your routers.
Make all the HTTPS requests go thru a common router, have it do the proxy hack.

You seem to have too many constraints to the problem. You should make sure you really have to have them all.

An actual MITM attack (catching things passing through a 'common router') is a possibility. This would simply require that our MITM present either a 1) completely fraudulent certificate to the client (for which they would get a warning that the signature is wrong) or 2) a certificate belonging to the man in the middle (for which they would get a warning that the certificate does not belong to the site they visited).

Either way, this is not smooth and has the substantial problem that it will break any HTTPS client that is not set to warn the user when there's a certificate problem (ie certain AV clients phone home for updates using an HTTPS connection and these clients probably are programmed to simply abort if the certificate is not perfect).

A second problem is that it places the burden on the MITM box of certifying the actual web service the person visited. So if they typed in htt ps://mybank.com and then they accept the certificate from the MITM box, then it is now the MITM's responsibility to confirm that the cert presented by mybank.com is proper. That's hard to do since many more-or-less valid certs on the Internet are not 100% correct....

As far as loosening the constraints goes.... meeting the requirements as they are is of very high importance. This has been a request from multiple large IT organizations for which I am consulting. If it can't be done, it can't be done.... but I have to give it a shot. But I see what you mean, it may be impossible and in that case the soultion may be to make it less painful to point a bunch of workstations at a proper SSL client..

Thanks for playing along

Hi,

Apologies if I'm looking at this too simply, but if Company X doesn't want their employees visiting sites they might not like, then why don't they simply allow access to the sites they do?

Intercepting SSL connections is at the least unethical (as fishtoprecords has already pointed out) but could also be potentially infringing, too.

Isn't monitoring the URL sufficient? I can't see why a company would want to go so far as to trawl actual data.

EDIT: If you visit a site such as http s://somebank.com then they're going to get a certificate warning, even if they have a certificate for an SSL proxy, as something won't match the bank certificate making it "invalid" (EDIT: unless all requests/page data are sent to a forwarding system, like a proxy as suggested above; it looks possible).

It appears to me you want to filter/log/monitor actual encrypted data?????

After that, I'm pretty sure you'd be getting into legal areas on interception of communications, privacy, etc..

Best regards,
AstroTux.

Thanks for the reply.

I am not actually interested in trawling communications, logging, etc. I simply stated the question that way above to make the scenario more general. Specifically I am only interested in the URL (much as you stated above). The problem is that the URL, in SSL communication, is encrypted along with the data. SSL is "transport layer security" ie. layer 4 meaning everything other than IP header is basically out of reach.

You are right, if a company is interested in preventing certain kinds of surfing, all they need is the URL. What I'm saying is that that URL is not available.

I'm going to have to go over the RFCs some more.. it really seems like this should be supported somehow as a nested certficate or secondary certificate or something like that.

As far as legal issues, depending on the area where this system is deployed... that will be an issue for the IT people who are my customers to worry about and to use this only if they think they can do so ethically and safely. I would think that in many cases, a pre-arranged waiver/agreement would be sufficient.

My bad.

If the HTTP headers are encrypted, too, then that is a problem.

Thinking around that problem then... could you do a reverse DNS lookup on the IP and do it that way?

Best regards,
AstroTux.

Just a thought on the Reverse DNS lookup, consider an entry in the hosts file on the client machine

reallynicesite.com 69.69.69.69

any monitoring software would record reallynicesite.com, when in reality the IP address being visited could be anything, and the proxy or MITM doing a reverse DNS would get the correct IP address, no?

reverse DNS is less than ideal for other reasons too. Many websites are hosted virtually so that several website domains all live on the same IP, just looking at the IP would be ambigious. In many other cases it is hard to tell exactly what website is associated with an IP just by looking at the name returned by dns, sometimes the more useful name is an alias or something. Finally, if you don't get the whole URL then you are missing out on a lot of information. There are a great many hosts that hold many classes of content. One host may have both Porn and Travel, but in different paths.

Doing a reverse DNS may help in some cases but I'd like to find a more reliable solution.

Hmm...

Well, the requesting host has to do a DNS request to find the web page, so could you intercept it at that point? It would allow you to see the requested URL before it is encrypted.

You could write a DNS proxy that intercepted the DNS request, checked it against a "blacklist" of DNS hosts you wanted to restrict/disallow, then forward the DNS request to an actual DNS server for processing, then return the response to the requesting client transparently.

If you came across a restricted/disallowed site, just return the IP of say the corporate intranet home page or something???

Might be easier than anything else.

Best regards,
AstroTux.