6 ms·

Will oscp stapling be able to be used to detect "something fishy" going on, because in that case the root ca wouldn't actually match. Do browsers compare the os

Will oscp stapling be able to be used to detect "something fishy" going on, because in that case the root ca wouldn't actually match. Do browsers compare the oscp root with the root of the current chain? Actually, if it's mitm it's "all bets are off" isn't it, because the KZ government can filter that it out the proxied response? Still, if oscp can assist at all, it's probably worth it that the browsers check for mismatch (if they don't already) Edit: typos

vbezhenar 7y ago
Browsers always trust manually installed CA roots, because that scenario is used by many corporations to monitor their traffic. OCSP, HPKP, etc won't help.
- ralphm 7y ago
  For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.
  - vbezhenar 7y ago
    A lot of internal enterprise networks use MITM, so your app won't work there as well. It might be a good thing or not, depending on your use-case.
    - ralphm 7y ago
      Yeah, I considered this a feature. As mentioned elsewhere in these comments, we should have a way to limit the scope of corporate certs.
      - jcrites 7y ago
        One solution is to use Name Constraints. The organizational certificate authority could be issued with Name Constraints limiting its power to a certain domain name only, e.g. *.example.com, using Permitted Subtree. If I was setting up an organizational CA for internal websites (not MITM), I would consider using Name Constraints to limit the certificate's scope and potential for abuse or compromise.
    - gsich 7y ago
      If the app is not for that particular corporation, then no harm done.
- deleted 7y ago
  [deleted]
- Avamander 7y ago
  Not when the cert has been previously CT and Staple preloaded I suspect?
  - michaelt 7y ago
    If a user manually imports a CA, it bypasses protections like CT [1]. This is a feature specifically designed to allow MITM for corporate proxies. Always seemed like a misfeature to me, but all the browsers do it. [1] https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate-transparency.md#Locally_trusted-CAs https://chromium.googlesource.com/chromium/src/+/master/net/...
    - Avamander 7y ago
      Sounds ridiculous that even when a site host specifically says they want things Stapled and CTd are ignored like that.
- GordonS 7y ago
  There are more benign uses too - many organisations run an internal PKI, and installing their root CA prevents employees' browsers from displaying warnings about untrusted certificates when accessing internal web apps/sites.
  - worldofmatthew 7y ago
    You might be able to make intranet.company-name.tld and have a parking page on the company-name.tld and use that to get a wildcard cert that can be used for the internal pages.
    - isostatic 7y ago
      Which you distribute to thousands of people on tens of thousands of devices?
      - worldofmatthew 7y ago
        With this you would have a vaild cert for your intranet aka no need to install a self-signed one.
        isostatic 7y ago
        However you would have a single wildcart cert + key that would need to be placed on thousands, or tens of thousands, of machines, by hundreds of staff is dozens of departments. It would be meaningless. I can prove ownership and then receive a wildcard certificate for *.internal.company.com, usually by a TXT record or similar (lets ignore EV certs for now), however that certificate isn't an intermediate certificate which is limited to signing new end certificates for blah1.internal.company.com, but wouldn't be able to sign for blah1.not.company.com. I'm no SSL/TLS expert by any means, so please let me know if I'm wrong and it is fairly easy to get intermediate certificates that are domain name limited - x509 constraints are apparently flakey.
  - vbezhenar 7y ago
    That would be a bad use IMO. Letsencrypt solves any need for legitimate certificates.
anticensor 7y ago
Would the firewall allow your package if you do not use Kazakh certificate as root certificate?

vbezhenar 7y ago

Browsers always trust manually installed CA roots, because that scenario is used by many corporations to monitor their traffic. OCSP, HPKP, etc won't help.

ralphm 7y ago
For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.
- vbezhenar 7y ago
  A lot of internal enterprise networks use MITM, so your app won't work there as well. It might be a good thing or not, depending on your use-case.
  - ralphm 7y ago
    Yeah, I considered this a feature. As mentioned elsewhere in these comments, we should have a way to limit the scope of corporate certs.
    - jcrites 7y ago
      One solution is to use Name Constraints. The organizational certificate authority could be issued with Name Constraints limiting its power to a certain domain name only, e.g. *.example.com, using Permitted Subtree. If I was setting up an organizational CA for internal websites (not MITM), I would consider using Name Constraints to limit the certificate's scope and potential for abuse or compromise.
  - gsich 7y ago
    If the app is not for that particular corporation, then no harm done.
deleted 7y ago
[deleted]
Avamander 7y ago
Not when the cert has been previously CT and Staple preloaded I suspect?
- michaelt 7y ago
  If a user manually imports a CA, it bypasses protections like CT [1]. This is a feature specifically designed to allow MITM for corporate proxies. Always seemed like a misfeature to me, but all the browsers do it. [1] https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate-transparency.md#Locally_trusted-CAs https://chromium.googlesource.com/chromium/src/+/master/net/...
  - Avamander 7y ago
    Sounds ridiculous that even when a site host specifically says they want things Stapled and CTd are ignored like that.
GordonS 7y ago
There are more benign uses too - many organisations run an internal PKI, and installing their root CA prevents employees' browsers from displaying warnings about untrusted certificates when accessing internal web apps/sites.
- worldofmatthew 7y ago
  You might be able to make intranet.company-name.tld and have a parking page on the company-name.tld and use that to get a wildcard cert that can be used for the internal pages.
  - isostatic 7y ago
    Which you distribute to thousands of people on tens of thousands of devices?
    - worldofmatthew 7y ago
      With this you would have a vaild cert for your intranet aka no need to install a self-signed one.
      - isostatic 7y ago
        However you would have a single wildcart cert + key that would need to be placed on thousands, or tens of thousands, of machines, by hundreds of staff is dozens of departments. It would be meaningless. I can prove ownership and then receive a wildcard certificate for *.internal.company.com, usually by a TXT record or similar (lets ignore EV certs for now), however that certificate isn't an intermediate certificate which is limited to signing new end certificates for blah1.internal.company.com, but wouldn't be able to sign for blah1.not.company.com. I'm no SSL/TLS expert by any means, so please let me know if I'm wrong and it is fairly easy to get intermediate certificates that are domain name limited - x509 constraints are apparently flakey.
- vbezhenar 7y ago
  That would be a bad use IMO. Letsencrypt solves any need for legitimate certificates.

anticensor 7y ago

Would the firewall allow your package if you do not use Kazakh certificate as root certificate?