The BomGar solution implements the standards for HTTPS, including HSTS, in a good way. However, there is a residual risk which is part of our defence in depth security strategy for all KPN apps and this is with the CA itself. Both the CA and an implanted CA (due to Malware, social engineering or other means) will allow for an attacker to gain opportunities without the client flagging this as a problem.
We understand that HPKP is a solution which fits the problem, but pose operational challenges.
We would like to pose for alternative tactics:
* HPKP pins on the host certificate (aka EEC or leaf certificate). This might pose challenges as mentioned in the linked blogs. We’ve are aware of their content. We still have environments where HPKP is introduced, and has not caused any operational problems.
* In other environments we’ve chosen to pin on an intermediate CA or root CA. Depending upon the available tooling one of the certificates in the chain is used to force the chain. Abuses in the CA vetting process or an attacker with MitMproxy/Burp/other will also be mitigated.
* "Pin on first use”, which makes it more like SSH fingerprint checking and verification with the accepted store. The host certificate (or other certificate in the chain) will be pinned after a first use is securely connected to the endpoint. When account details need to be delete to start over, the pin is dropped and the process starts all over.
We do not have plans to support Key Pinning. This functionality is also being deprecated by the major browsers.
We use HSTS instead of certificate pinning. HSTS offers similar protection as certificate pinning. Certificate pinning can be problematic for customers who use an SSL proxy to access to /login, /appliance, or the Public Portal. This is because SSL proxies can generate SSL certificates on the fly that would not comply with a Public-Key-Pins header.