How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.
Solved
SSL Proxy... double proxy.... Will it work?
Posted on 2011-03-01
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?
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
5-
4
9 Comments
depends on what you mean by a "double proxy"
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.
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.
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!
Featured Post
In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
The well known Cerber ransomware continues to spread this summer through spear phishing email campaigns targeting enterprises. Learn how it easily bypasses traditional defenses - and what you can do to protect your data.
Check out the latest tech news, community articles, and expert highlights in August's newsletter.
The Email Laundry PDF encryption service allows companies to send confidential encrypted emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…
The Email Laundry PDF encryption service allows companies to send confidential encrypted emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…
Suggested Courses
Course of the Month6 days, 5 hours left to enroll
688 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.