This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Firewall: v19.5 GA: Feedback and experiences

Release Post:  Sophos Firewall v19.5 is Now Available 

Old v19.0 MR1 thread:  Sophos Firewall: v19.0 MR1: Feedback and experiences 

EAP Sub thread:  SFOS v19.5 Early Access Program 

EAP 19.5 Thread:  Sophos Firewall: v19.5 EAP1: Feedback and experiences 



This thread was automatically locked due to age.

Top Replies

  • This is indeed expected behavior of the FCI feature.  What follows is a Draft of a KB Article I'm writing (feedback welcome).



    In XG 18.0 the DPI proxy was introduced, with many more SSL/TLS scanning options and certificate protection. There are some certificate security concerns with that are blocked in most configurations, however they are allowed without any warning when using DPI mode with the decryption profile "Maximum compatibility". In these cases the XG decrypts and re-signs, creating a new certificate with its own Certificate Authority that hides potential problems that the end user should know about which that would be blocked in other configurations.

    In 19.0 a new feature was added called Forward Certificate Invalidity (FCI). This feature detects certain types of certificate invalidity and "forwards" (tells the user) about them. Because we cannot create a certificate with the same error, so we create one in a special way that we know will cause browsers to warn users. A CA is used that us unique and untrusted, and the certificate Common Name is used as the error message to tell the end user what the problem is. This changes the behavior of DPI mode with Maximum Compatibility. By signing it in the way, browsers will warn users that there is a certificate problem but will allow users to proceed and load the pages as they did in 18.0/18.5.

    The most common issue that FCI catches on the public internet is websites that do not send their entire certificate chain. When a website provides their certificate, they usually provide the certificate, the CA that signed it (usually an intermediate CA), the CA that signed that one, up to the root CA. The root CA is trusted by the browser, and the browser can verify the entire chain.

    However some websites do not provide the chain. They may provide only the certificate, or they provide the certificate and the root CA, but they do not provide the intermediate CA. While this is valid, it is not best practice and sites like ssllabs.com which rate sites will cap their score.

    If a website does not provide the chain they usually implement AIA (Authority Information Access). This is a link within the certificate that says where to download the CA that signed it.

    Some browsers (Chrome 58+, Edge, Safari) will automatically use the AIA to download the intermediate and store it for future use. Firefox 75+ uses a different mechanism called intermediate CA preloading (wiki.mozilla.org/.../Intermediate_Preloading). Older Android (pre Oreo) devices do not support any mechanism. The XG does not currently support AIA.

    If the website does not provide the full chain, the XG behavior depends on the configuration. It is important to note that v19 did not introduce blocking of sites that do not provide the full chain. The XG has always blocked these sites when using normal security, and the resolution below has always worked. The difference is that when using a decryption profile that does not block self signed certificate, invalid issuers, or many other security concerns (such as "Maximum compatibility") we used to allow the connection and sign it in a way that made it appear more secure. Now we allow but sign it in a way that appears insecure.

    How to configure the system to allow access to sites that do not provide a complete certificate chain.

    Method 1 - Do not decrypt
    Configure the domain to not be decrypted. Adding the domain to the Local TLS Exclusion List is the best option for DPI mode. Adding it to a Web Exception will exclude it for both DPI and Proxy mode.

    Method 2 - Add the Intermediate certificate to the XG CA store

    Option 1:
    Test the site in www.ssllabs.com/.../
    You should see that the grade is capped to B and the Certification Path includes an "Extra Download". In the section under Issuer there should be an AIA link.

    Option 2:
    Use a browser that is not going through the XG, or is going through the XG with HTTPS not decrypted so that you get the original certificates as presented by the site. Ask the browser to display the certificate information and the AIA link should be there. How this is displayed is browser specific.

    Once you have the AIA link, download the certificate to your computer. Then in WebAdmin go to Certificates > Certificate Authorities and Add. Choose the file.
    With the Intermediate in the CA store, the page will load in all configurations.

    Jump to answer
  • Hi   ,

    thanks for your reply, the status is still at on goning.
    What does it mean "Firmware will be available only after the staging phase is completed?"
    Took it some Time on Sophos site do i need to prepare something?

    Thanks in advance
    Franjo

  • Hello Franjo,

    It would be after the staging phase that it would be completely rolled out to all even though Sophos Central shows that the firmware has been upgraded successfully (but it did not been upgraded to the FW) . In the meantime, you can manually download SFOS v19.5 from the Licensing Portal and update individual firewalls manually if it has not been upgraded into your FW or CFM.

    With regards to preparation, you can always refer to release notes, upgrade information, KIL etc https://docs.sophos.com/releasenotes/index.html before you proceed over with the upgrade and plan upgrade on window hours as this would require reboot and would cause downtime.

    Hope this helps. Have a nice day and thank you for choosing Sophos

    Cheers,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Someone has problems with two WAN connections, too? We have two PPPoE connections, one active one backup. In former versions there was a problem with the PPPoE that if you plugged it out and back then it didn't reconnect. They made a fix for us in the former version, worked. Now this is fixed globally in 19.5 and the connection is restored fine after. But now there is another problem as it seems that the WAN link manager now has some problems.

    To describe it more clear:

    - unplug active connection

    - backup will take the connection, everything is back online with the backup connection

    - plugin active connection

    - pppoe connection is restored

    - WAN link manager shows green (both links)

    - now all connections from internal to WAN get broken. There is some problem that the traffic can't be matched internally.

    Fun fact: connections from outside or VPNs are not affected, their traffic is like it is expected.

    If I go to console and look for dropped packets there are most of the packets are shown as dropped. Now I went back to WAN link manager, made the backup connection active and it works out of the box. Now back to backup, same again and so on. Now I set the backup link as active with weight 2. Works again from my workstation after the backup link. After that I went to the interface from the normally active link (with weight 1) and only saved it. What happened then was kind of horrible. My node 1 made a hard reboot (not even the firmware text was removed in the screen like it is by normal reboots). After reboot it still served connections via the backup connection (which was active with weight 2 at that time). Now I changed it back and now it is normal again. We had this problem several times in the past while we were doing some maintenance on the links.

    Now we are really scared of (even planned) fail overs or maintenance of our links as every time we have many minutes of no internet connection until the box finally get its internal matching with the two WAN links done...

  • I reported this perceived years ago, they told me it is not that important and they are working on more important topics. I shall live with that...

  • Is there a way to "upgrade" existing HA to a LAG link instead of breaking the HA and reinitiate it? I had so many problems in the past with that so that I would like to go around it...

  • Hello K-M,

    Can you please share appliance access id via PM?

    Please also share dropped packets detail if you have it handy.

    Development team will try to analyze historical logs however would it be possible for you to conduct live debug session, if required? 

    Regards,

    Sanket Shah

    Senior Development Manager, Sophos Firewall

  • See PM.

    No, unfortunately I didn't copy the log to a saved file. But what was the problem I think is that the traffic was "matched" to Zone 0 in both directions so it didn't fit to any rule. That was the only thing I could see was special.

    Live debug is only possible in limited conditions as this is our main firewall in productive environment. If needed let us see what we can do.

  • Thanks for sharing access detail.

    Let us investigate the logs and decide next actions.

    Regards,

    Sanket Shah

    Senior Development Manager, Sophos Firewall

  • Is there a solution? and why your support is not knowing the problem?

  • Essentially the problem is, Central Expects the firmware to be available, which is not for the particular firmware. Hence nothing will happen. The Fix will actually prevent the admin from starting the firmware, if the firmware is not available for the firewall. 

    Central will not push the firmware, instead Central will trigger the firewall to do it at its own. 

    __________________________________________________________________________________________________________________