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: option to disallow IDN ?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Fri, 16 Dec 2022 13:18:12 -0500
On 15-Dec-22 03:06, Daniel Stenberg via curl-library wrote:
> Hello,
>
> After my recent blog post "IDN is crazy" [1], a few people have
> requested a new option to curl that prevents it from accepting/using
> IDN. To reduce the risk of getting exploited by one of the many
> trickeries you can do with it.
>
> Thoughts?
>
> [1] = https://daniel.haxx.se/blog/2022/12/14/idn-is-crazy/
>
That seems a bit extreme. perhaps something more nuanced:
* Warn if an IDN name is used (perhaps check for characters that look
like latin?) Could be the default for the tool.
* Have a don't warn switch that can go in .curlrc
* Let the don't warn switch take a whitelist of idn names that the
user expects to communicate with
* For the library, allow registering an 'idn name encountered';
callback. Allows checking white (or black) list of idn names.
Callback returns OK to use, or Reject. command tool could use to
implement warning. Allows library users to choose (or not) to
filter. Default (no callback registered) would be "OK" for
compatibility.
Callback could also be used to gather data on IDN names.
And/or the callback registration could specify "all domain names", "Just
IDN" - it might be generally useful to be able to white/blacklist any
set of domain names. In this case, the callback would get passed the
type (IDN, ASCII), the handle, the original URL, the current URL (e.g.
when redirecting), and the domain name to check. Maybe the IP address too.
Something like this would seem to be more flexible than an outright
option to ban all IDNs, and even be useful for other policy choices.
(Think a library-based IOT device that should only talk to a known
server, but might be compromised. Or 'Never talk to twitter'. or ...)
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2022-12-16
Date: Fri, 16 Dec 2022 13:18:12 -0500
On 15-Dec-22 03:06, Daniel Stenberg via curl-library wrote:
> Hello,
>
> After my recent blog post "IDN is crazy" [1], a few people have
> requested a new option to curl that prevents it from accepting/using
> IDN. To reduce the risk of getting exploited by one of the many
> trickeries you can do with it.
>
> Thoughts?
>
> [1] = https://daniel.haxx.se/blog/2022/12/14/idn-is-crazy/
>
That seems a bit extreme. perhaps something more nuanced:
* Warn if an IDN name is used (perhaps check for characters that look
like latin?) Could be the default for the tool.
* Have a don't warn switch that can go in .curlrc
* Let the don't warn switch take a whitelist of idn names that the
user expects to communicate with
* For the library, allow registering an 'idn name encountered';
callback. Allows checking white (or black) list of idn names.
Callback returns OK to use, or Reject. command tool could use to
implement warning. Allows library users to choose (or not) to
filter. Default (no callback registered) would be "OK" for
compatibility.
Callback could also be used to gather data on IDN names.
And/or the callback registration could specify "all domain names", "Just
IDN" - it might be generally useful to be able to white/blacklist any
set of domain names. In this case, the callback would get passed the
type (IDN, ASCII), the handle, the original URL, the current URL (e.g.
when redirecting), and the domain name to check. Maybe the IP address too.
Something like this would seem to be more flexible than an outright
option to ban all IDNs, and even be useful for other policy choices.
(Think a library-based IOT device that should only talk to a known
server, but might be compromised. Or 'Never talk to twitter'. or ...)
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature