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) - 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) - 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...) - Company A would like to prevent the user from accessing A's SSL VPN through B's 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). You can't win a policy fight with someone who controls the machine. It's pointless to try. Trevor _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
