localhost to be truly local?

[Daniel Stenberg via curl-library]

Hi,

I've created PR #7039 that makes "localhost" resolve to 127.0.0.1 and ::1
without using the resolver [1].

The point of this is to make sure localhost is the local host for sure. With
this, we should be able to consider transfers from localhost to be using a
"secure context" as per web standards and for example allow 'secure' cookies
even for 'http://localhost' [5].

Firefox already does this [2].

Chrome has a page [3] tracking its and others work on this and it says Edge
already does this.

In Chrome's bug entry for this task [4], it sounds as if 'localhost' is
already at least partially special-cased in Chrome code.

I've tried to find conclusive documentation on exactly how Windows deals with
this. They started to resolve 'localhost' without it being present in their
hosts file several years ago, but I've not found reliable source for this. I
believe you can still put it in there and have it acknowledged.

curl's --resolve option and its libcurl counterpart still allows a user to
make localhost URL's connect to another IP address, just like for any other
name.

Your feedback and thoughts on this are most welcome!

[1] = https://github.com/curl/curl/pull/7039
[2] = https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts
[3] = https://www.chromestatus.com/feature/6269417340010496#details
[4] = https://bugs.chromium.org/p/chromium/issues/detail?id=589141
[5] = https://github.com/curl/curl/issues/6733

[Geoff Beier via curl-library]

On May 10 2021, at 9:52 am, Daniel Stenberg via curl-library

Post by Daniel Stenberg via curl-library
The point of this is to make sure localhost is the local host for sure. With
this, we should be able to consider transfers from localhost to be using a
"secure context" as per web standards and for example allow 'secure' cookies
even for 'http://localhost' [5].

If this is the main goal, it seems useful to test all resolved addresses
to see if they're loopback addresses, and flag them as a
"secure context" if they are. That would both make sure the address
returned when localhost is resolved is really local and let other
aliases for loopback addresses be recognized that way.

This is the kind of test I'm thinking of:
https://github.com/boostorg/asio/blob/558aeb8ea8a2d889ab17a79b9de13566182801e2/include/boost/asio/ip/impl/address_v4.ipp#L112

https://github.com/boostorg/asio/blob/558aeb8ea8a2d889ab17a79b9de13566182801e2/include/boost/asio/ip/impl/address_v6.ipp#L144

Either way, I think the proposal is a good idea and this is not meant as
an attempt to argue about what color the bike shed should be.


-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.

[Daniel Stenberg via curl-library]

If this is the main goal, it seems useful to test all resolved addresses to
see if they're loopback addresses, and flag them as a "secure context" if
they are. That would both make sure the address returned when localhost is
resolved is really local and let other aliases for loopback addresses be
recognized that way.

It is at least *a* goal, not sure if it is the main one.

I have three separate reasons why I don't think we should flag secure context
in run-time like that:

1. It opens up for trickery where the owner of the DNS decides whether
a name is secure context. Once the user has used the name for a few years
and thinks it will remain secure forever, it changes and bad things happen.

2. A huge point of my change is that you know by looking at the host name/URL
if it is secure or not.

3. curl knows immediately if the context is secure without having to resolve
the host name. There's no moment of not knowing. It makes things a lot
easier to not have to rely on resolver responses for this.

[Niall O'Reilly via curl-library]

FWIW, and with the caveat that I am not a **real** DNS expert.

Post by Daniel Stenberg via curl-library
I've created PR #7039 that makes "localhost" resolve to 127.0.0.1 and
::1 without using the resolver [1].
The point of this is to make sure localhost is the local host for
sure.

I think it makes sense to move [[RFC6761][]] compliance inside the
application.

Post by Daniel Stenberg via curl-library
curl's --resolve option and its libcurl counterpart still allows a
user to make localhost URL's connect to another IP address, just like
for any other name.

Compliance with [[RFC6761]] should surely have priority over
consistency. 8-)

Post by Daniel Stenberg via curl-library
Your feedback and thoughts on this are most welcome!

€0,02
/Niall

[RFC6761]: https://datatracker.ietf.org/doc/html/rfc6761#section-6.3