WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network. Check out this quarters report on the threats that shook the industry in Q4 2017.
SSL Proxy... double proxy.... Will it work?
Hi all.
This is the question I have. If you have a double ssl proxy will it work? So you are faking a fake certificate basically. In theory, I think it should work. In reality.. well that is often a different thing.
Your thoughts?
This is the question I have. If you have a double ssl proxy will it work? So you are faking a fake certificate basically. In theory, I think it should work. In reality.. well that is often a different thing.
Your thoughts?
Asked:
5-
4
1 Solution
note that most proxies (of either type) can be configured to forward some or all requests explicitly to another proxy, or query the cached data on other proxies for already-downloaded content, or both :)
Let me clarify in my mind.
For theory sake....
We take one blue coat ssl intercept then we place another blue coat intercept next to it logically.
Assumptions: 1. That a root CA has been trusted by the end user. 2. That both Blue Coat devices have an intermediate trusted CA.
We should not have problems capturing the decrypted traffic twice, because the end user will never see a difference.
Thanks again for you assistance Dave.
For theory sake....
We take one blue coat ssl intercept then we place another blue coat intercept next to it logically.
Assumptions: 1. That a root CA has been trusted by the end user. 2. That both Blue Coat devices have an intermediate trusted CA.
We should not have problems capturing the decrypted traffic twice, because the end user will never see a difference.
Thanks again for you assistance Dave.
if one bluecoat is "upstream" of the other, then the second bluecoat may well alert if you have not added the CA key for the first bluecoat to it.
however, given you own both bluecoats and the setup procedure pretty much requires that you use an external root CA (usually a MS one, although I have used xca for this in the past) they probably have the same root CA onboard anyhow, so it becomes academic :)
however, given you own both bluecoats and the setup procedure pretty much requires that you use an external root CA (usually a MS one, although I have used xca for this in the past) they probably have the same root CA onboard anyhow, so it becomes academic :)
How about this situation:
Each blue coat has a self generated CA certificate. End user has had both certificates pushed out. Then the two blue coats will have no problem with the others certificate. (Actually, I think you will need to use a MS CA because how will the two blue trust each others certificate?)
So user connects to blue coat 1. Blue coat 1 decrypts then re-encrypts traffic and creates on the fly certificate which is sent to Blue Coat 2. Blue Coat accepts blue coat 1 certificate then creates another certificate to connect to the website. (actually, I think it is more complex then this...however this is the basic logic)
Is this practical..
Each blue coat has a self generated CA certificate. End user has had both certificates pushed out. Then the two blue coats will have no problem with the others certificate. (Actually, I think you will need to use a MS CA because how will the two blue trust each others certificate?)
So user connects to blue coat 1. Blue coat 1 decrypts then re-encrypts traffic and creates on the fly certificate which is sent to Blue Coat 2. Blue Coat accepts blue coat 1 certificate then creates another certificate to connect to the website. (actually, I think it is more complex then this...however this is the basic logic)
Is this practical..
sounds about right. assuming 1 is closer to the user than 2, then what will happen is that the user will connect to 1 and ask for the url; 1 will connect to 2, and again, ask for the url, and 2 will connect to the website. the site will respond with a certificate, which 2 will fake a copy off and pass to 1, and 1 will fake a copy off and pass back to the user. both bluecoat devices will then do analysis - which is really a bit of a waste, but if you want to do that it will work :)
I just picked two blue coat devices for theory. I am actually interested in dropping another SSL proxy, however I have greater familiarity with Blue Coat.
Dave, you have helped me out a few time in the past. If you are ever in DC, I will buy you lunch if you are interested. Thanks again!
Dave, you have helped me out a few time in the past. If you are ever in DC, I will buy you lunch if you are interested. Thanks again!
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
If you are acting as a classic proxy, then you will be forwarding (unchanged) the ssl handshake you get from upstream, and it doesn't matter too much how many proxies that goes though.
If you are intercept-proxying a ssl connection then you have to be able to represent to the end user (either by having a locally installed cert for reverse proxies such as ISA server and iChain, or spoofing the certificate "on the fly" like, for example, ironport WSAs) a certificate they will accept as valid for the url they entered.
If there is another proxy upstream of type classic, then it doesn't matter - you are planning to either pass though or spoof the certificate anyhow.
If there is another proxy of the intercept type upstream, then it gets a bit more interesting. The certificate must be acceptable where used, either at the end client (for a pass though proxy) or on the intercept proxy itself (if the chain has TWO intercept proxies in it, the first must accept the second's certificate)
this is usually the case (In fact, most intercept proxies don't actually care if their upstream validates or not) but there is an edge case where the first proxy's cert would be acceptable to the end user (via group policy or whatever) but is *not* acceptable to the second proxy, and hence that proxy generates an error to the user rather than passing though the traffic.