Re: [arch-d] Treating "private" address ranges specially

[Christian Huitema <[e-mail]>]

On 3/31/2021 4:52 PM, Martin Thomson wrote:

> Thanks everyone for the insights.
>
> I'll reply to Ted as he hit the crux of the issue most adroitly...
>
> On Wed, Mar 31, 2021, at 20:07, Ted Hardie wrote:
>> What I think this proposal would actually like to do is to determine
>> whether a resource referenced by a specific web server would also be
>> reachable by that server.
> That's exactly it.
>
> Brian's point about the inherent folly of making such guesses is well taken.
>
> It's quite clear that it is generically bad to make these sorts of inferences from addresses.  That's good information.
>
> The question I'm now interested in answering is whether using these as part of a heuristic in order to limit the scope of a change like the proposed is tolerable.
>
> The goal here is to close off a security loophole in how browser make request for a tiny slice of the total set of requests that are made.  The ultimate goal might be to remove the loopholes uniformly.  However, that would break so much stuff that a change like that would never stick.  This is a more narrowly-scoped approach that tries to identify conditions where the requests are a) more dangerous in general, and b) rare enough that any breaks would not be widely felt.

Martin,

Do you have a description of the type of attacks you are thinking off? I 
understand the general idea of "malicious server somehow gets to use or 
attack internal sites behind the firewall", but a concrete description 
of a couple examples might help. Is it about opening a frame against an 
internal host, or about running javascript and evading the standard 
protections? Is it something like the "request forgery attacks" 
discussed in QUIC?

-- Christian Huitema