On Sun, Dec 12, 2021 at 09:49:57AM +0100, Philip Homburg wrote:
> >> There is something I don't understand about this draft.
> >
> >The main thing to understand is that complex applications like browsers
> >allow data retrieved from one endpoint to script interaction with a
> >*different* endpoint, and possibly see the retrieved content, subject to
> >various CORS (Cross-origin resource sharing) controls.
>
> Indeed this is subject to CORS. Nothing new here. Any browser needs to get
> this right.
Perhaps I failed to explain the issue, but that does not mean that there
is no issue.
The browser may be communicating with a victim server believing its name
to be the same as the attacker's server, and therefore allowing attacker
served scripts (from a prior connection) to script the interaction with
the victim server. The victim server may believe it has a secure
connection with the client (based perhaps a client-certificate-signed
handshake) and may allow it retrieve sensitive data.
Cookie-based authentication does not appear to be vulnerable here, since
the browser would presumably not send victim site cookies to a site
it believes to be the attacker.
If the victim site uses https, but authenticates clients by internal IP
alone, again there could be an issue.
I don't know how to explain this better, you could ask on a cryptography
or TLS-related forum, this is DNSOP, where the expertise tends to be of
a different nature.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
