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

HTTPS Inspection and CipherSuite selection

Ever since US Cert issued its Alert (TA17-075A) "HTTPS Interception Weakens TLS Security", I have been deliberating how to adapt to its observations.   I gathered these objections from the report:

  • Some implementations would silently accept certificates that would cause browsers to either warn or block the connection.   UTM has never had this problem, it tends to block traffic that a browser would accept.   The problem was more severe in v9.4 than it is in v9.5.  v9.4 blocked included root certificates as well as missing intermediate certificates.   v9.5 only blocks on missing intermediate certificates.  (My recommended workaround is to obtain the missing certificate and load it into UTM as a root certificate.)

  • Some implementations would permit connections using obsolete ciphersuites.  At the time it was published, UTM had this problem because the RC4 protocol remained usable.  The UTM ciphersuites have since been modified to address this objection, but the list of "good" ciphersuites seems to be constantly changing as a result of white-hat research.

  • Most vendors failed to provide their users or administrators with visibility into the ciphersuite behavior and certificate policy of the product.   UTM still has this problem, because the HTTP inspection ciphersuite can only be configured using the CC command in shell mode, which is technically reserved for Sophos Support only.

My first response to this issue was to work with Sophos Support to learn how the https inspection ciphersuites are configured.   

When white-hat researchers reported that the RSA key exchange method was vulnerable to attack, my first inclination was to use my new knowledge to remove RSA key exchange from the methods that UTM's https inspection was allowed to use.   But on closer consideration, I changed my mind.   If an important website is blocked because of security issues, I will almost certainly be forced to create an https-inspection bypass exception.   This teaches me a little about the world of behind-the-times websites, but does not really change the security posture of the organization.   Https inspection provides better logging and better malware defenses than inspection bypass, so it actually weakens overall security.

I concluded that all that was needed for my organization was to keep tight certificate validation, while settling for best-available encryption protocols, which the client and server will find through the negotiation process.   UTM with https inspection provides centralized certificate policy control, a benefit that cannot be matched easily by any other method.

I have decided that the best ciphersuite configuration is one that mimics the major browsers as closely as possible.   So that is how my https inspection is currently set.

Your thoughts?

   



This thread was automatically locked due to age.
  • Great contribution, Doug.

    Initially, my lab UTM was configured with what I'd done to address POODLE.  That meant that cc get http tlsciphers_client returned:

    ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:PSK-RC4-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA

    When I ran the Qualys SSL Client Test, there were some weak ciphers.  I then saw that a recently installed client had 'HIGH:!MD5:!aNULL:!EDH:!RC4' instead, so I changed tlsciphers_client to that.  There are still vulnerable ciphers with that, so I changed back to the POODLE fix.  I then re-ran the test and eliminated the weak ciphers, winding up with:

    PSK-RC4-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA

    Does anyone have suggestions of "important websites" where I might test to see if they won't work with any of these ciphers?

    Wait a minute - I just found one - community.sophos.com - hah!

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I am currently using this setting:

    HIGH:!MD5:!aNULL:!RC4

    with TLS1.0 as the minimum protocol.

    I think this is pretty close to browser equivalence