More on the latest variant of Petya/Petrwrap/Petyawrap ransomware outbreak here.
We have begun to roll out another SWA update - version 4.3.1.4. This update should be available to all customers within the next week.
This update was made necessary by an upcoming change to Google Chrome. In version 58 of Chrome, HTTPS certificate validation rules are changing. Chrome will no longer consider the Common Name field of the certificate when checking to see if the certificate is valid for the web site. It will now only consider the Subject Alternative Name field.
This change is consistent with the relevant RFC for HTTPS. Use of the Common Name when Subject Alternative Name is not present, but the specification also deprecates use of the Common Name as best practice for certificate issuers. Chrome is not the first mainstream browser to have taken the step of enforcing this deprecation: Firefox also made this change recently. But Firefox only enforces it for certificates signed by a CA in their Trusted CA list, so it has not impacted on SWA users in the same way.
We had hoped to roll out this update before Google released version 58. Unfortunately the release came sooner than expected. Any users who update to Chrome v58 in the coming days may experience SSL validation messages until your SWA is updated to v4.3.1.4.
Chrome also recently made it harder to visually inspect a certificate from the main UI. Unlike other browsers, you need to open Chrome's Developer Tools in order to visually check the certificate. But of course, we don't expect users to have to do that.
For SWA customers there are two main areas impacted:
Customers who are using the default, automatically-generated certificate for the Appliance's UI will notice that Chrome v58 will show certificate warnings when connecting. The same certificate is also used for AD SSO authentication in Transparent mode.
Once your SWA has updated to version 4.3.1.4, you can eliminate this problem by going to Configuration > System > Certificates, selecting the 'UI & Portal Certificate' tab and clicking 'Regenerate Certificate'. The new certificate will use the Subject Alternative Name field.
If you are using a Custom Certificate, you may need to ask your certificate issuer to provide you with an updated one. However, if you have purchased a certificate from a commercial CA, it may well already use the Subject Alternative Name field.
When decrypting HTTPS traffic for inspection, the Sophos Web Appliance automatically creates 'shadow' certificates for each website visited by end-users. Because the certificates are created on a site-by-site basis, and do not have to support multiple sites like some original certificates do, the product has just used the Common Name field to identify the site. From version 58, Chrome will report to end-users that the certificate is not valid.
This problem will automatically be resolved by updating to version 4.3.1.4. It requires no further action.
This is the only change in v4.3.1.4, but for the record, the release notes for are available here.
Is it possible to get this update now rather than having to wait a week? We've had to turn off SSL interception because of this and want to turn it back on!
KarlFoley Support can arrange this for you. secure2.sophos.com/.../contact-support.aspx
UPDATE: Following a successful limited release, general availability for this update has started today, 24 April. It should be available to all customers within the next 24 hours.
Still facing this problem after upgrading firmware of Sophos UTM SG230 to 9.413-4... need urgent support to solve the problem.
JojiPallipat - This post relates to the Sophos Web Appliance, not the UTM. However, I am aware that we have had at least one report of a customer where the upgrade to 9.413 did not complete correctly, leaving the old behaviour in place. Have you contacted support about this?