On Fri, May 06, 2016 at 07:45:23PM +0000, Adrien de Croy <adr...@qbik.com> wrote a message of 84 lines which said:
> when there were no MitMs, (discounting crytpo algorithm downgrade > attacks against SSLv2) you could consider https to be secure > (integrity and privacy). Apparently, you have an analysis of TLS which is quite at odd with everyone else in the security world. TLS *is* secure against MitM (otherwise, there would be little reason to use it). I agree with Paul Hoffman: your objection against the current text is groundless. > Now you can expect in a corporate network to be surfing through a > https-inspecting proxy where neither integrity nor privacy is > guaranteed in any strict sense, Because the end host is controlled by the same organisation as the interceptor. Saying that TLS is vulnerable to MitM because of this case is like saying TLS is vulnerable because, for instance, a program did not bother check the certificate <https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>. > Browsers still happily show their little green lock icon. Sure they > have to accept the signing cert first, and that tends not to happen > unless you're in a corporate network, or some countries I believe > have now mandated acceptance of a cert or are looking at that. If someone (your company or other) can add a cert to your cert store, it can do what it wants. This has been known from the beginning of public-key cryptography. In a typical corporate environment, the IT department install all the software, anyway, and can even install a browser which does not check certs, as well. > So we are left in the situation where users don't really know if > they have security or not, and the green lock icon is untrustworthy. If you don't control your machine (if someone is administrator and you are not), all bets are off. Again, this is well-known for a very long time and you add no new information. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
