|
No, they would not prevent those other
mechanisms. Where is your evidence that they would?
If the "attacker" controls the software that the client is using, then it would set up the software to not check public-key pinning or CT, if necessary. As Richard noted, this may not even require developing custom software. It may be as simple as distributing a standard browser with its own CA added as a "user-installed" root certificate. In the case that the "attacker" has the cooperation of the server, and the client is using unmodified software, then the data sent between the client and server (including the server's certificate) would be no different than if the server wasn't allowing the "attacker" to have access to the data. There would be no information available to the client at all that would distinguish between scenarios in which the server either is or isn't allowing another party to have access to the data being transmitted over the TLS session. If public-key pinning and CT would prevent other mechanisms from working, please explain in detail how they would do so. Or better yet, let's end this line of discussion and work on finding mutually agreeable solutions to the underlying problem. On 10/25/2017 12:12 PM, Richard Barnes wrote:
|
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
