The draft explains this in more detail. To use your example, there is now confusion over the identity of the server. The client thinks that they have connected to google.com, when in fact they have connected to facebook.com.
That's where the attacks start. Requests made to facebook.com over that connection will be treated as *same-origin* to google.com. That violates the SOP and could allow google.com to read confidential data from facebook.com. On 14 October 2016 at 11:15, John Gilmore <g...@toad.com> wrote: > I'm a bit puzzled by this "UKS" (Unknown Key Share) attack concept. > > The attack scenario, presented in section 2 of > > https://www.ietf.org/id/draft-barnes-dane-uks-00.txt > > is that a user connects to the "attacker" site (say google.com) but > actually google.com has published Facebook.com's public key and is a > man-in-the-middle (MITM) forwarding all the traffic to facebook.com. > > Now this MITM can't actually read or modify any of the traffic, they > are just a passive conduit. The most they can see is the timing of > the traffic and the number of bytes involved. The user sees > Facebook's site, secured with Facebook's key, even though they > connected to google.com. (How or why the user was somehow convinced > to connect to google.com while seeking facebook.com is unexplained.) > > So the threat is... uh... ? > > ... something about some cross-origin scripting firewall policy > elsewhere in the system? > > Why do we care? > > John _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
