* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #100 (closed design: wontfix)

Opened 7 years ago

Last modified 3 years ago

DNS Spoofing / DNS Binding advice

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: unassigned
Component: p1-messaging Severity: Active WG Document
Keywords: security dns rebinding spoof Cc:
Origin: http://www.w3.org/mid/1186663336.16745.63.camel@henriknordstrom.net

Description

Been reading and thinking a bit more on the DNS binding problem after the reminder by Lisa, and came to the conclusion that RFC2616 recommendations and actual implementation and security concerns is quite far apart on this.

RCF2616 15.3 "DNS Spoofing" recommends the exact opposite of DNS binding. Any client implementing those recommendations is quite vulnerable to the discussed issues. This makes me wonder if 15.3 perhaps should be dropped from the specifications. Not many user-agents is following the recommendation found there (certainly none of the main browser vendors), and it's recommendations also is not very effective against what 15.3 tries to protect from (DNS poisoning). The protection from DNS poisoning 15.3 tries to achieve is best addressed at the DNS resolver layer, not HTTP application implementation.

The recommendations in 15.3 is sane from a technical perspective, and also close to obviously "correct" from a technical perspective, but unfortunately opens a information theft security issue by using scripting capable user agents using hostname based access checks to jail the executed scripts. So having this in the specs is counter to actual implementation experience.

Additionally viewing 15.3 as a security measure is imho not very useful as it doesn't really improve the security aspects by any noticeable amount at any level.

So in the end it's better to leave this to implementation detail I think, leaving it out of the protocol specifications I think.

But this said, the HTTP solution of not allowing servers to answer requests for "other" sites do solves quite a lot of the security concerns regarding information theft using HTTP. The rest is client implementation details to ensure active content is properly jailed.

Change History

comment:1 Changed 6 years ago by mnot@pobox.com

  • Component changed from non-specific to p1-messaging

comment:2 Changed 5 years ago by mnot@pobox.com

  • Keywords security dns rebinding spoof added
  • Priority set to normal
  • Severity set to Active WG Document

comment:4 Changed 4 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com

comment:5 Changed 4 years ago by mnot@pobox.com

AIUI DNS pinning / binding is no longer considered adequate; current advice is to make sure you check Host headers on incoming requests.

HTTPbis could help here by cautioning clients against allowing modification of the Host header when generating requests.

comment:6 Changed 3 years ago by mnot@pobox.com

p1 4.2 requires

  1. If the host as determined by rule 1 or 2 is not a valid host on

the server, the response MUST be a 400 (Bad Request) error message.

Is this adequate? If so, does the security implication need to be specifically highlighted (either here or in security considerations)?

comment:7 Changed 3 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to wontfix

Seems to be agreement that it's difficult to make specific recommendations that will stand the test of time. Furthermore, there were no proposals for text to generally warn about this problem, so closing as WONTFIX. Can reopen if a proposal is made.

comment:8 Changed 3 years ago by julian.reschke@gmx.de

From [1369]:

rewrite DNS spoofing advice section, taking Henrik's text (see #100)

comment:9 Changed 3 years ago by julian.reschke@gmx.de

From [1370]:

rewrite DNS spoofing advice section, remove unused reference (see #100)

Note: See TracTickets for help on using tickets.