On Dec 2, 2013, at 8:10 AM, Trevor Perrin <[email protected]> wrote: > On Sun, Dec 1, 2013 at 9:09 PM, Yoav Nir <[email protected]> wrote: >>> >>> The question remains whether "strict" is necessary for the "pinning to >>> local trust anchor" case. Ryan argues that it's not, and describes a >>> way for the browser to handle this without "strict": >>> >>> http://www.ietf.org/mail-archive/web/websec/current/msg01947.html >>> >>> >>> That proposal makes sense to me, and avoids the complexity of an >>> additional directive. So I support removing "strict", and adding text >>> for this "pinning to local trust anchor" case. >>> >> The proposal there is for pins that chain to a well-known CA can be >> overridden, but pins that chain to local CAs cannot. This means that public >> sites, such as banks, social media and corporate portals (one type of "SSL >> VPN") cannot opt out of this local policy override. >> >> With vendor hat on, we have been asked by customers whether we could prevent >> traffic to SSL VPNs (which we provide) from being decrypted. Currently, the >> only options we can give them are to deploy client certificates or to use >> IPsec VPNs. The above proposal adds one other way - to deploy a corporate >> CA. All three defeat the purpose of SSL VPNs that is that they can be used >> from pretty much any device. A "strict" directive and enforcing browser >> version (yes, I know it can be spoofed - none of this is secure against a >> malicious client) can get us close enough. > > > It's unclear what you're describing. > > Is it something like this? - > - Company A provides an SSL VPN to its employees, but is unwilling to > customize the user's software (e.g. install a trust root)
Yes. Maybe this is because the employee is using some weird device like a Mac, or a Windows Phone, or a box running Ubuntu - things the IT department has no idea how to handle. In other cases, we've seen SSL VPNs deployed to customers or partners. > - Company B requires everyone working onsite to send all traffic > through a MITM proxy, and *is* willing to customize the user's > software (e.g. install a trust root) Either that, or they can keep clicking through warning screens. > - An employee of Company A is working onsite at Company B, using her > company A laptop, yet subject to B's IT policies (which doesn't make > sense, but let's soldier on…) Sure it makes sense. The transparent proxy goes with the Wifi. > - Company A would like to prevent the user from accessing A's SSL VPN > through B's MITM proxy *Any* MitM proxy. > Is this where you think "strict" is useful? Company A would assert a > "strict" pin for its SSL VPN? > > I think it's useless here. If "strict" was in the spec, many sites > would undoubtedly enable it, causing these sites to (hypothetically) > not to work through B's MITM. But B would "fix" this by configuring > user browsers to ignore strictness (or even worse, requiring users to > disable pinning, or use a browser without it). I don't think many would enable it. I don't think even banks would, and I'm pretty sure social media, and web-based mail wouldn't. It's a niche of web sites that would enable it. > You can't win a policy fight with someone who controls the machine. > It's pointless to try. Agreed. But the use case is against someone who does not control the machine. Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
