I suppose I need to better understand Decrypt and Scan HTTPS Malware Scanning. I noticed that when browse HTTPS site the cert is replaced by the Sophos Cert. So, my question is why and how to troubleshoot. If I turn Decrypt off then all is fine.
This is the way HTTPS filtering - just about ANY HTTPS filtering - has to work. HTTPS is an encrypted protocol. Normally, a "middle-man" - like a firewall - cannot snoop on the traffic at all. It has no way to decrypt the traffic, as the two endpoints negotiate the encryption algorithm and pass keys back and forth in such a way as to keep someone from just snooping and impersonating one side or the other.
The only way, then, to decrypt and scan that traffic, is to perform what, in the wild, anyway, would be the equivalent of a "man-in-the-middle" attack. The firewall therefore acts as the "client" and talks to the secure site, and generates a "fake" certificate to talk to the client, thus impersonating the secure site.
To resolve this: Trust the root certificate of the XG box. Then the https certificates will appear valid in your browser.
You will have this problem on ANY device - XG, UTM, Watchguard, etc - that performs deep HTTPS inspection.
This is the way HTTPS filtering - just about ANY HTTPS filtering - has to work. HTTPS is an encrypted protocol. Normally, a "middle-man" - like a firewall - cannot snoop on the traffic at all. It has no way to decrypt the traffic, as the two endpoints negotiate the encryption algorithm and pass keys back and forth in such a way as to keep someone from just snooping and impersonating one side or the other.
The only way, then, to decrypt and scan that traffic, is to perform what, in the wild, anyway, would be the equivalent of a "man-in-the-middle" attack. The firewall therefore acts as the "client" and talks to the secure site, and generates a "fake" certificate to talk to the client, thus impersonating the secure site.
To resolve this: Trust the root certificate of the XG box. Then the https certificates will appear valid in your browser.
You will have this problem on ANY device - XG, UTM, Watchguard, etc - that performs deep HTTPS inspection.
Ian -
I recommend you google how SSL and public key cryptography work, because unfortunately I do not think you understand the concept, and I don't think this forum is the place to correct that.
In a very quick nutshell:
SSL is "secure" because it combines ENCRYPTION with IDENTITY VERIFICATION.
In SSL/TLS, you are effectively communicating with another machine that you do not know and with whom you do not have keys pre-shared. You have to have some way to relatively securely transmit those keys back and forth when you setup the encrypted conversation. Once encrypted, the connection is SECURE. But... how to setup the keys? If someone was listening at the start of the call, they could intercept them. Enter certificates. Certificates allow you to VERIFY the IDENTITY of the remote server and even provides a mechanism for secure key exchange.
Certificates are issued around a hierarchy of trust. Certain third parties are designated as "trusted." These lists of third parties are built in to your computer and to any device that can connect via SSL to another system.
SSL is "secure" because those third parties issue certificates to the entities to whom we wish to talk over the internet. Those certificates are delivered when you connect to a website via HTTPS, and your browser or operating system or both are designed to VERIFY that the certificate sent is trusted by that magic list. THAT VERIFICATION STEP IS WHAT MAKES SSL "secure."
This is why it is important that you pay attention when you receive one of those lovely warnings that the certificate is invalid. Unless you were EXPECTING that, it may indicate something is wrong with the identity of the remote server. It is also why the various browsers have made it harder to just click through and bypass those issues.
When you browse the web through a security device that is performing deep HTTPS packet scanning, "decrypt and scan" or whatever the vendor happens to call it, the certificate shows as untrusted because the UTM/XG/Security Device is generating and certifying the certificate it sends to you.
DOWNLOAD THE CA generated by the XG box, TRUST that CA on your computer, and magically the problem goes away. Your connection with the XG box is secure. You TRUST the XG box. The XG box then makes the secure connection to the web for you. Everybody is happy. Your browser is happy. You are happy. Malicious systems/people/programs are NOT happy. They will then likely get caught when they try to use HTTPS to download crap to your network. Everyone (except them) is happy.
(sigh)
That is ONE extreme level of security, but of you require that level of security, you need to go ahead and disconnect yourself from the internet and create a private network like the gov't does in a SCIF. You aren't going to find that level here.
The KEY to the SSL/TLS security is the fact it is "secure enough." Your BROWSER or OPERATING SYSTEM is supposed to alert you when a connection is not *trusted*. Thus, NSA and black hats would NOT be able to just bypass SSL... WITHOUT YOUR KNOWLEDGE. Can they? Yes. Will you be alerted to a potential threat? YES.
You can probably even set your browser to reject untrusted certs outright. I think there is a policy setting in there somewhere.
Regarding ChavousCamp's instructions....
I just put in an XG115 and enabled the decrypt and scan option and of course you can't go to any https URLs. So my initial reaction was, what is the option there for if it doesn't *easily* work?
So I see ChavousCamp's instructions after searching and my reaction, are you kidding me? I have to go around to all the machines and install certificates?
So I take it this option is there for those that want a more robust layer of protection that are willing to do all that extra work. For me, I paid GOOD money for this device with the intention that it offers some protection AND makes my life as a Network Admin, from the security standpoint, EASIER not HARDER!
Good security isn't easy, Jeff. You could have paid good money for any number of other manufacturers' devices, whose names I shall not mention here, and you would be in the same boat.
With all due respect, perhaps you should blame yourself for not doing your research on what was REQUIRED to make such decrypt-and-scan functionality work with ANY vendor, or blame yourself for not having the knowledge of how HTTPS works and why this is required. Don't blame Sophos - or any of the other vendors - for the difficulty level of implementation on your network. It is the same for all of them. Sophos actually makes it REALLY easy to set up ON THEIR BOX, and then to MAINTAIN, TROUBLESHOOT, AND REPORT. That's where the ease of use comes in.
Fortunately for security, unfortunately for us trying to scan/filter it, the only way to decrypt and scan https traffic is to, effectively, perform a man-in-the-middle attack on the traffic. HTTPS, with its certificates, was EXPRESSLY designed to try to prevent us from doing what we are doing.... and that is a *good thing* most of the time.
If you are running a domain environment, it is easy - add it to GPO. If you are not, then yes, some work will be required.
Is it really that easy on a domain? some browser don't use the windows trusted root store, also mobile devices aren't domain joined
