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
  • Regarding to Heartbeat authentication, please refer this thread:   Heartbeat authentication failed : username without domain name maybe the cause- Live users disappear but still connected to vpn If this doesn't help, then please PM me access id.

  • Hello there,

    This was due to a setting on your profile that it's only set to receive PMs from your friends. 

    You can change this setting if you would like for any of the options below

    Allow private messages from:

    • No one 
    • Friends Only 
    • Everyone

    You can find this setting by clicking on your profile icon (top right) > Settings > Scroll down to "Allow Private messages from".

    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.
  •   I am very interested in what they find.   I can sent a PM to Luk on your behalf if still needed. We can PM just fine.

  •  did you come up with a solution? How many routes do you accept? We take full tables from 3 providers (2.8 mil routes or so) and V19.5 falls on it's face. V18.5 handles it ok, but not in HA failover. The router process shoots up to 100% CPU and the firewall locks up. V19.5 on a single unit is very sluggish and the network traffic latency is affected. This is an XG330, so there should be no issues. We don't use XG as an edge device, since I know it can't handle it, but Sophos says it can, so I test it on every release.

  • SOLVED, for me: I disabled InterceptX and it uploaded and installed properly. This is related to InterceptX and web browsers: it got a bad checksum on upload from either Firefox and Safari. Though an SCP uploaded it perfectly. Finally disabled InterceptX (which I'd done before, but just for the download, assuming it was incoming corruption), and it uploaded and installed perfectly.

    SO SOPHOS might want to investigate why InterceptX doesn't recognize its own software and in what manner InterceptX might be corrupting it. I've had issues in other circumstances with downloads being "corrupted" by the XGS sending the file for Zero-Day examination and so the file that results is something like HTML telling you to "click here" or something like that. I wasn't aware that InterceptX would do such things... unless the "corrupt file" was zero-length or something like that.

  • Hi  , is it possible to share support access id for your device running 19.5.?Dev team would like to investigate what causes the device become slow or the cpu utilisation difference between 18.5 and this version. please PM me. -Shrikant

  • Hi Iferrara,

    We have looked at historical logs on your system and not found anything suspicious.

    Would it be possible for you to go back to 19.5-GA again? We would like to run debug script to collect some data periodically.

    I sent you friend request so that I can PM you more details about it.

    Regards,

    Sanket Shah

    Regards,

    Sanket Shah

    Senior Development Manager, Sophos Firewall

  • Sure. I moved back to 19.5. Ping me when you need my help.

  • I manage many firewalls with OSPF. This problem occurred on my test firewall, which normally has no active link on the LAN interface. I use this to test the updates and to test the automation using API. This is of course not a setup that will be used like this in the real world.

    Now that I think about it, another problem might become relevant. If the switch that the firewall is connected to fails, the OSPF route would be deleted and the firewall would not be available to analyze the problem. We usually access the LAN IP of the firewall via VPN tunnel (WebAdmin or ssh) and then see what is reachable in network. This way would then be omitted. I could alternatively access via Sophos Central and open the console in WebAdmin, but then I would have to enter a password again, which I would have to type in manually.

    This can be done, but it is a different way with its own challenges. If the route is kept, we can use the normal workflow to access it.

    So it would be desirable to have at least the choice whether the link monitoring should be active or not.

    If a post solves your question please use the 'Verify Answer' button.

  • Thanks Ben@Network  for the details.

    We are working on the solution to provide a configurable option to end user. 

    We anticipated appliance access scenario and want to know, if this can be an issue for any other scenarios/use cases.