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

SECURITY BUG: No Revocation Checking When Performing HTTPS Inspection

Running firmware version 9.111-7 with "Scan HTTPS (SSL) Traffic" enabled.  When I browse to a website who's certificate is revoked (like: https://revoked.grc.com/ ) the UTM allows access to this page.  Browsing directly to that page without going through the UTM shows a proper revocation warning from all my tested browsers.  As I can access the page without error when my connection is proxies by the UTM, this leads me to believe that the UTM is not doing ANY revocation checking.  As revocation checking is a critical component of how certificates and HTTPS function, this is a significant security issue that needs to get fixed ASAP.


This thread was automatically locked due to age.
Parents
  • It appears Sophos was aware of this in 2012 and regarded it as a design decision.  The document (dated 3/21/2012) linked and quoted below refers to 8.3 as the 9 series was not yet released (7/16/2012).

    With the new HTTPS features in 9.2 does this "conscious decision" continue?  (Easier for me to ask than test myself at this time)

    http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

    Astaro Security Gateway

    The Astaro Security Gateway, a Sophos product, is affected by one vulnerability described in this analysis.

    Lack of certificate revocation checking

    The Astaro Security Gateway (firmware 8.300) does not check for certificate revocation via either CRL or OCSP standards. Client-side certificates are created under the context of the proxy's CA even when the server-side certificate has been revoked. An attacker could exploit this vulnerability to perform MITM attacks outside the proxy using compromised certificates that have been revoked. An internal client endpoint sees a valid certificate signed by the proxy's CA and trusts it transitively. This behavior enables spoofing and interception attacks.

    At publication time, there are no software updates or known workarounds available. According to Astaro's security team, the absence of these solutions is a conscious design consideration related to known attack techniques allowing for bypass of both CRL and OCSP checks. Astaro is monitoring developments in this area but does not plan to change the product's behavior at publication time.
Reply
  • It appears Sophos was aware of this in 2012 and regarded it as a design decision.  The document (dated 3/21/2012) linked and quoted below refers to 8.3 as the 9 series was not yet released (7/16/2012).

    With the new HTTPS features in 9.2 does this "conscious decision" continue?  (Easier for me to ask than test myself at this time)

    http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

    Astaro Security Gateway

    The Astaro Security Gateway, a Sophos product, is affected by one vulnerability described in this analysis.

    Lack of certificate revocation checking

    The Astaro Security Gateway (firmware 8.300) does not check for certificate revocation via either CRL or OCSP standards. Client-side certificates are created under the context of the proxy's CA even when the server-side certificate has been revoked. An attacker could exploit this vulnerability to perform MITM attacks outside the proxy using compromised certificates that have been revoked. An internal client endpoint sees a valid certificate signed by the proxy's CA and trusts it transitively. This behavior enables spoofing and interception attacks.

    At publication time, there are no software updates or known workarounds available. According to Astaro's security team, the absence of these solutions is a conscious design consideration related to known attack techniques allowing for bypass of both CRL and OCSP checks. Astaro is monitoring developments in this area but does not plan to change the product's behavior at publication time.
Children
No Data