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.
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.
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.
