how to configure separate settings for a ssl scanner based on the user group or profiles, like it was possible in WW6?
The customer want to tunnel some URL and URL Categories for some User Groups but decrypt for other groups.
For some reason the SSL Scanner placed on very top of rule set, probably to ensure Filter decitions based on embedded URL (https://example.com or https://evil.com) and not on CONNECT URL (example.com:443).
Which disadvantages exist If I move up the Auth Rule Set and place it before the SSL Scanner? Which value is in URL.Host before and after the SSL Scanner?
How it works in WW6? Does the URL Filter , the web reputation and User Mapping with the Host Header based on the URL from CONNECT call or based on embedded https://xxxx ?
This is possible as you have described it, you would move your authentication rules above SSL scanner rules. There may be some side effects of doing this particularly if you were deployed in a transparent setup, in which case the authentication server rules would need to integrate a bit of their own SSL scanning (for authentication purposes only). As far as the URL.Host this value could differ based on the deployment type and sometimes even browser behavior.
The URL host in a proxy environment will be filled with the CONNECT request line or the Host header. In a transparent setup it will be filled with the IP... or if the browser uses SNI (server name indication), it will be filled with that value (typically the domain name).
WG7 can mimic the behavior of WW6, it could filter based on the CONNECT, or based on the embedded URL (within the tunnel) it all depends on the rules.
You said the following:
"The URL host in a proxy environment will be filled with the CONNECT request line or the Host header. In a transparent setup it will be filled with the IP... or if the browser uses SNI (server name indication), it will be filled with that value (typically the domain name)."
So what is the behavior with SNI in Proxy Environment? We have more and more problems with webpages which cannot be accessed because of the wrong certificate presented. We also tried with Windows 7 (Which should support SNI) but it also does not work over MWG7.
Since I cannot find any information about this in the manuals it would be very interesting how it works with MWG7.
sorry for the late response. In a Proxy Environment (I assume "Proxy Environment" means "Direct Proxy": Clients have MWG configured as the Proxy Server to use when accessing the Internet) SNI should not be important. When you access an HTTPS website the browser automatically created a CONNECT request, which contains the URL you have typed in the browsers address bar. For MWG there is usually nothing to look up, because we can take the URL from the CONNECT request and create a server certificate for the domain you want to visit.
SNI is only interesting in transparent environments, because there is no CONNECT header showing the URL but we only see a source IP talking to a destination IP on port 443. To find out the host name you probably typed in the browser we use SNI.
Maybe you can provide more information about your environments and the websites you are trying to talk to and how MWG generates certificates. I have played around a lot with transparent/non-transparent SSL environments and usually MWG is able to obtain the correct host name to deliver the right certificate. Maybe there is a configuration error or something we can look into.
Have the issues been reported to technical support in the past?
Please let me know if you would like to further investigate.
Many thanks for your reply.
We had a problem with the following Webpage: https://www.swissbankers.ch. Unfortunately they fixed now their web server to have ip based ssl again.
But I found the following nice Test Page: https://alice.sni.velox.ch/
On the Test Page above you can see if it is SNI or not.
The problem was that the customer told us that this was working with Webasher before but it is difficult to prove.
So the SNI is only working in transparent mode of the Proxy right?
okay I think I start to understand (finally). Most questions in regards to SSL Scanner and SNI are in regards to a client not capable of sending the SNI so that MWG does not know who to talk to and gives a wrong certificate to the browser. It seems that in this case we are talking about MWG being capable of sending an SNI header to the server (instead of reading it from the client).
The test page is really nice. Unfortunately it is true that MWG in the current version is not capable of sending an SNI header when establish a connection on his own (not tunnel a connection from the client). This is true for MWG 7, but it is also true for MWG 6, even in the latest version. It is possible that in the past the connections were tunneled. By default all banking and finance related sites have been tunneled by MWG 6 by the "Tunnel By Category" feature. In MWG 7 all of these sites will be intercepted by the SSL Scanner, maybe this is why the issue has not shown up earlier.
SNI support is planned for the next release of MWG. It comes with an updated and streamlined operating system which contains updated OpenSSL libraries which (finally) allow us to do SNI.
I hope this information will help to solve some of the questions.
Many thanks for this answer, it is exactly what we're looking for.
We also think that the MWG6 used tunneling that's why it was working there.
We're looking forward for the new release with SNI Support, this problem is showing up more and more on the internet.
A lot of companys still using Windows XP which is not SNI capable, at least with Internet Explorer.
Thank you very much!
PeterMessage was edited by: itagsupport on 7/25/12 2:39:07 PM CEST
I fully agree. SNI is becoming mandatory, so it is good that we finally will support it. Windows XP Clients should have a chance to talk to SNI web servers with MWG (with SNI support) in the loop (and SSL Scanner enabled). I believe transparent environments will remain the only problem.
Please let me know if there are further questions.