Forum Discussion
AlexBCT
Cumulonimbus
CumulonimbusSSLO Security policies; do we still need the Pinners category?
Playing with SSLO again, and came across the Pinners category in the Security Policy (category of website that is immediately bypassing SSLO due to the use of Pinned certificates).
(More detail on Certificate Pinning:
https://community.f5.com/t5/technical-articles/implementing-ssl-orchestrator-guided-configuration/ta-p/285880
https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
It seems that HTTP pinning and Certificate pinning has now mostly been deprecated (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning & https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning , but the Pinners category still exist. I've removed quite a few of the domains from the category, tested again with Forged certificates, and all sites still work! (which I believe they shouldn't if Pinning was still in place at those sites. And Google classically being one of the biggest users of Pinning initially isn't even in the Pinners category anymore.
So, should SSLO still configure the Pinners category by default, or should it now be removed by default and Pinning only be kept in the back of our minds in the case we do come across a website that uses it? (Or 3rd and just as likely option - have I completely misunderstood something?
Certificate pinning was never intended for browser traffic.
In the simplest sense, modern browsers contain TWO CA trust stores - a system-level and separate user-level store, and a policy that says, basically, that a pinned certificate violation shall be ignored if the issuer is trusted via the user-level trust store. So in an SSL forward proxy, when you import the CA certificate to the clients, you're placing that CA in the user-level trust store, thus negating the effects of certificate pinning.
What is not covered, however, are non-browser agents that do certificate pinning. These are typically your antivirus and OS/software update agents. These non-browser agents have a single CA trust store and thus must honor all certification pinning validations. Without the pinners category in SSLO, these agents would break.
AlexBCTHi Kevin,
Thanks for the very useful answer - that clarifies a few things (and fills a couple of holes in my knowledge 😉
I am however now wondering if some of the entries in the Pinners category aren't too broad to be included by default. For example, for Dropbox, it contains the full domain (https://*.dropbox.com), which means no matter where people are coming from (Agent or Browser), Dropbox will always be allowed by default - that's quite a potential hole in a DLP policy. For these domains it has now become a default-allow, rather than a default-deny architecture (though I do appreciate that it's still only a fraction of domains that you'll be interested in, and a level of pragmatism should be used).
Do you know if the entries in the list are checked regularly on whether they should still be in the list and/or can be made more specific?
Thanks,
- Kevin_Stewart
Employee
The are indeed checked regularly. And most of the URLs in the pinners list are specific to "updates", so only ever used by non-browser agents. Dropbox is a notable exception here, where the desktop agent and a browser are using the same URLs.
- AlexBCT
Good to know, thanks!
- Kevin_Stewart
Certificate pinning was never intended for browser traffic.
In the simplest sense, modern browsers contain TWO CA trust stores - a system-level and separate user-level store, and a policy that says, basically, that a pinned certificate violation shall be ignored if the issuer is trusted via the user-level trust store. So in an SSL forward proxy, when you import the CA certificate to the clients, you're placing that CA in the user-level trust store, thus negating the effects of certificate pinning.
What is not covered, however, are non-browser agents that do certificate pinning. These are typically your antivirus and OS/software update agents. These non-browser agents have a single CA trust store and thus must honor all certification pinning validations. Without the pinners category in SSLO, these agents would break.