On Sunday, July 12, 2015 11:38 AM, Ted Lemon wrote: >On 07/11/2015 05:28 PM, Christian Huitema wrote: >> OK, you are probably correct that this is just one of the many attacks possible when >> connecting to insecure networks. Then, of course, there is the whole idea of letting an untrusted >> DHCP server direct one's browser to an arbitrary web page. Looks like an ideal setup for zero >> days and phishing tools. Ideally, we should only process the redirected page into a fairly tight sandbox... > > This is just one example of the "everything is broken" problem. In > point of fact, if you can inject packets on the local wire and sniff packets off of the local wire, you can easily > send malware to the host simply by providing it with mostly correct information, and then once the hotspot > detector has been bypassed, hack the next http query that goes by, stuffing your malware, or instructions > to fetch your malware, into the HTML. Except that local attackers cannot do that if the host is programmed to only query using HTTPS, or if the host sends all its traffic through a VPN. The "web capture" hack is special, because it forces the host to read a web page programmed by the untrusted local admin. As such, it opens a vulnerability window. My point is that the draft should recognize that window, and the three attack vectors: malicious hot spot admin, DHCP response spoofing, and in the case of clear text network packet injection in the capture portal web page. My advice to implementers would be to consider the capture portal web page as fundamentally untrusted, and for example not allow it to run scripts. Then system administrators could consider "white listing" some of these pages, provided of course that the connection could be authenticated and protected through HTTPS. -- Christian Huitema