W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2016

Re: [secure-contexts] `*.localhost` + DNS

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Tue, 3 May 2016 15:22:50 +0200
Message-ID: <CA+eFz_L_sokF2QGj5iN_vWfnyLOQUrYgt6G+ej+hqb7VvVZCog@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Mike West <mkwst@google.com>, Craig Francis <craig.francis@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
<snip>

> I would like this setup, where the DNS does resolve to 127.0.0.1, to be
> considered a secure origin, so I can easily develop websites without having
> to setup HTTPS on my local machine (I suspect I will need to anyway, but
> though I'd mention it).
>

Understood. This is something we've resisted offering in the past due both
to conceptual complexity, as well as nondeterministic behavior. It would be
difficult for you to understand why, for instance, `
project.laptop.example.com` was secure when it pointed to `127.0.0.1`, but
not when it pointed to `192.168.0.5`, because that resolution is completely
opaque to you, the user.

</snip>

Who is the user here, the developer? I'd assume a developer that has setup
manual DNS resolution to 127.0.0.1 to understand this right?

Are you saying that the intent is to not consider the actual resolved IP
address of the host but rather the host portion of the requested URL? It
would seem less "hacky" to have a rule that simply says, if the host
resolves to 127.0.0.1 it's secure.

I am +1 to the suggestion that browsers could make this easier to manage
for developers but then again they could also just let developers tweak how
the browser does DNS directly from within in the browser to save us all a
lot of hacking around (or maybe they already do an I just need to catch
up...)


On 3 May 2016 at 14:44, Richard Barnes <rbarnes@mozilla.com> wrote:

>
>
> On Tue, May 3, 2016 at 8:08 AM, Mike West <mkwst@google.com> wrote:
>
>>
>> On Tue, May 3, 2016 at 1:43 PM, Craig Francis <craig.francis@gmail.com>
>> wrote:
>>
>>> As a developer that works on multiple websites, I have a wildcard DNS
>>> entry that points `projectABC.laptop.example.com
>>> <http://projectabc.laptop.example.com>` to 127.0.0.1 (as an aside it
>>> resolves to 192.168.0.5 for the browsers in a VM).
>>>
>>> I would like this setup, where the DNS does resolve to 127.0.0.1, to be
>>> considered a secure origin, so I can easily develop websites without having
>>> to setup HTTPS on my local machine (I suspect I will need to anyway, but
>>> though I'd mention it).
>>>
>>
>> Understood. This is something we've resisted offering in the past due
>> both to conceptual complexity, as well as nondeterministic behavior. It
>> would be difficult for you to understand why, for instance, `
>> project.laptop.example.com` was secure when it pointed to `127.0.0.1`,
>> but not when it pointed to `192.168.0.5`, because that resolution is
>> completely opaque to you, the user.
>>
>> A better solution, I think, is for browser vendors to provide an override
>> mechanism for origins you specifically care about: Chrome
>> has `--unsafely-treat-insecure-origin-as-secure="
>> http://project.laptop.example.com"`, and I assume Safari, Opera,
>> Firefox, and Edge could be prevailed upon to provide similar controls as
>> suggested in
>> https://www.w3.org/TR/secure-contexts/#development-environments.
>>
>
> Yes, we probably could, if people really want it.
>
> It's getting pretty trivial to set up HTTPS locally, though.
> https://www.youtube.com/watch?v=nk4EWHvvZtI
>
> --Richard
>
>
>
Received on Tuesday, 3 May 2016 13:23:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC