Kathleen Moriarty wrote: > Thanks for the discussion on this (more is welcome, I'm not trying to > stop the flow). I'm glad to see there is interest to cover the two > intercept methods described in my discuss as well as the discussion on > them. I think the important part for the middle box example is the > warning/notification to the user in a clear way so they are empowered to > make a decision. Some corporate environments, the security staff is > more advanced and has taken the time to outright block some access that > would be encrypted (webmail sites for instance - fine, that's their > right to do that to prevent viruses, etc.), they have also set up rules > so that certain connections do not go through the TLS proxy (financial > sites). Then there are users like each of us, who know what the errors > mean and can chose to not go to a site if we think our privacy could be > impacted in some way. This doesn't need to be described in the draft of > course and I'm fine with consensus of the WG, but would just like to see > a clear warning to the user as a best practice, independent of whether > or not it is listed as an 'attack'.
Yup. I agree. This is something I do see at customer sites: with middle-boxes deployed and an automated, centrally managed IT infrastructure most companies simply deploy a DPI wildcard certificate on client machines. If they are willing to inspect traffic, that is. Employees usually will not know the difference, because there is this nice green lock in their browser when they visit their banking site. I'm looking forward to the deployment of certificate transparency, not sure how middle boxes will cope with that. Certainly the TLS-proxy stuff is something I do not agree with. Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
