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 Bill, 

    Would you be able to enable support access, so Engineering can take a look at your device to find out what happened with the upgrade? 

    Please PM me the support access ID if you can.

    Thanks! 

  • Hi Bill,

    When I read through your update experience, in my case it was more likely with an SMB firewall manufacturer who had the updates hit the wall with about 200 rules, because they also tried to "rewrite" the rules to the new firmware.

    With Sophos, compared to an "up2Date" process, the update to 19.5 took about 10 minutes for me. Afterwards, SophosXG did not start cleanly and has the approx. 200 rule sets and the 10 network-segments connected to them online again.

    Good luck to fix all your reported issues

    Chris

  • Tried to update this morning via central. Update was planned to start at 06:00 in the morning but nothing happened. FW is still at 19.0.1.365. Details in central show, that it was updated, but it´s not correct and I can plan to update again in central:

    Sometimes webadministration shows a popup to start a FW-Upgrade to 19.5, sometimes not. If I check for firmware updates on the firewall directly, there are no updates.

  • After Successfull update to 19.5. i got (on-prem hosted XG) the following messages (never seen since version 16)..... no idea what happend, or Up2date is to early to publish the following message

    You may not see the latest firmware or the firmware you want. The reasons are as follows:

    • It may be in the initial release phase.
    • A direct upgrade path isn't available from the current firmware.

    Go to the release notes and see the Upgrade information for the firmware version you want.

    Thinking

    Any idea, why this message is comeing up since 19.5 ?

  • Same here at my team. Sadly didn’t had time to raise a support case on this.

  • Newly announced firmware follows our standard firmware releases phases, and typically takes 2 to 5 weeks before the upgrade is available to all.

    As many customers are unaware of phase-wise staging of new firmware, they feel it is some issue when they do not see the new firmware on their firewall even though it is announced on the community. They spend time debugging and calling up support to find out about release phases.

    This is an informative message with appropriate links to assist customers when they do NOT see newly released firmware in UI.

  • Hellp PM Parth,

    i agree and know the release process at Sophos. Where i was wondering, that information on an on-prem XG is displayed in the firmware & update part, if the Firmware is not set to "Availible to all". I have not seen this on the GUI from v16 to v19.01. Therefore I was a bit irritated by this feature.

    Regards
    Chris

  • Hello there,

    It seems like you’re affected by NR-9006 (The scheduled upgrade to SFOS with v19.5 using Sophos Central aren’t working); the team has found the Root cause and is working on the solution.

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • Hi Bill,

    Issue is due to missing of one DB entry. As you've restored a backup on v19.0.1, that entry is available. 

    Can you please upgrade firmware again, it should work as that entry available?

  • As v19.0.1 build 365 gave us serious freezes and hiccups on our Central Sophos Virtual Appliance (SFV6C8) we had to turn back to v18.5.4 and waited for the v19.5 GA release.

    However after upgrading to v19.5.0 GA-Build197 we see the same issues (freezes and hiccups) and again had to turn back to SFOS 18.5.4 MR-4-Build418.

    I do not see CPU, Memory or other performance issues on the Sophos VA or the VM.

    What can be the cause here? It looks like it is S2S IPsec RBVPN related as all our branch office users are complaining, but not our users working from home.

    Any advice what we can try next here?