Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: localhost to be truly local?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 10 May 2021 16:43:44 +0200 (CEST)
On Mon, 10 May 2021, Geoff Beier wrote:
> 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.
Date: Mon, 10 May 2021 16:43:44 +0200 (CEST)
On Mon, 10 May 2021, Geoff Beier wrote:
> 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.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2021-05-10