From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 037FB23075 for ; Sat, 9 Mar 2024 01:23:36 +0100 (CET) Received: (qmail 21964 invoked by uid 550); 9 Mar 2024 00:19:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21932 invoked from network); 9 Mar 2024 00:19:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709943803; x=1710548603; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=HwS4B/jneMyo2ytFaKEH7k29jY0O2Q1FKMpVCrVeX94=; b=V0O9hAXdzpXm5y1gikiSgtViJIhydegqtwl4JTewFkB0uCI1sAMs9b+ZC/BFNQxPBc bANjA+DFL4qQDEhJtnWimKINTbrsVCE74dnF/Eo/zXueTiwqOs3KUaBX3ubEkkbHc8Zv 5h8hjpc4Qyh4l2dijQJXn98+usyq0mcchDMYVgvfHuSEjKuMfMswmgUQQ9UNfHBJu+9c TukgLmY1FmawiLtUfl5x94earQqWcSZn/MhrU7WAPRALUwWIeGXTo8c3RUJw8RbMRSPV PO27hccE8vgxw180AVtgTJMw6SDo7CtMRNvjvUzaKw/ednergMPwfiJQqv0msot2W34u u5GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709943803; x=1710548603; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HwS4B/jneMyo2ytFaKEH7k29jY0O2Q1FKMpVCrVeX94=; b=NSoBmtEkwTRUk2nbGt+hjGvDS+2NeYXdq2OK8xYOqDRQinZhWAAl/tEqe/uwlN6lHC w6+vtikiAUgrfDdGjuoUc9udUsau3+FlgcZMICp17ZCaBOE+aZWIlDbNyykdh2pGYSOR LW2EPPT24uaNZKd1yoA+7Kfx/TZJA+1YBd2iD9AC8pZ72FbnZqEqTMfD17V9+1DXKG6M HvTZKmxZU5FTXXub97kmwAEWbQa0E41OIX4BGbyZ8cNl6E0USrTB5zeYkveMQlWz+2FG U8UKtFBXTnyrSDb8BbMEywqW8zSd7P9eFESKGXfueucHGdD4Uc5rCIMA3KATRK9iCViU btYA== X-Gm-Message-State: AOJu0Yy0Oe6V4z/hssR/v6UhvQUN/09I6JI5kBWNi2cRvslVlLrs7hLK JDNL/vV2pPKPNpkKgeSqbdPUruXhbgtnKhMTJecErghmBl4S325/WasEKP1EkKWGP9dYnR5WZe/ wnzmtXW0K3VTAuie4V9S2L7xKmjaPw6OE X-Google-Smtp-Source: AGHT+IGcc1BGVfN7IpdCB8BB2DhLmFK9HpPNPHzyNpl2JErl9IMadcZEE2yD38vjqFat7XP2kV2J09Y2kijgCONOB1k= X-Received: by 2002:a05:6820:290:b0:5a1:1e5e:1fd0 with SMTP id q16-20020a056820029000b005a11e5e1fd0mr929845ood.2.1709943802872; Fri, 08 Mar 2024 16:23:22 -0800 (PST) MIME-Version: 1.0 References: <20240308000818.GJ4163@brightrain.aerifal.cx> <20240308025204.GK4163@brightrain.aerifal.cx> <20240308034740.GL4163@brightrain.aerifal.cx> <20240308133102.GN4163@brightrain.aerifal.cx> <20240308203143.GQ4163@brightrain.aerifal.cx> <20240308225445.GR4163@brightrain.aerifal.cx> In-Reply-To: <20240308225445.GR4163@brightrain.aerifal.cx> From: Jeffrey Walton Date: Fri, 8 Mar 2024 19:23:11 -0500 Message-ID: To: musl@lists.openwall.com Cc: David Schinazi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] mDNS in musl On Fri, Mar 8, 2024 at 5:54=E2=80=AFPM Rich Felker wrote: > > On Fri, Mar 08, 2024 at 01:55:18PM -0800, David Schinazi wrote: > > On Fri, Mar 8, 2024 at 12:31=E2=80=AFPM Rich Felker w= rote: > > > > > On Fri, Mar 08, 2024 at 11:15:52AM -0800, David Schinazi wrote: > > > > On Fri, Mar 8, 2024 at 5:30=E2=80=AFAM Rich Felker wrote: > > > > > > > > > On Thu, Mar 07, 2024 at 08:47:20PM -0800, David Schinazi wrote: > > > > > > Thanks. How would you feel about the following potential > > > configuration > > > > > > design? > > > > > > * Add a new configuration option "send_mdns_unicast" > > > > > > * When true, use the current behavior > > > > > > * When false, send the query on all non-loopback non-p2p interf= aces > > > > > > * Have send_mdns_unicast default to false > > > > > > > > > > > > I was thinking through how to pick interfaces, looked up what o= ther > > > mDNS > > > > > > libraries do, and pretty much all of them don't allow configuri= ng > > > > > > interfaces, whereas Avahi exposes allow-interfaces and > > > deny-interfaces. > > > > > I'm > > > > > > leaning towards not making this configurable to reduce complexi= ty. I > > > > > think > > > > > > that anyone interested in that level of config is probably usin= g > > > Avahi > > > > > > anyway. > > > > > > > > > > > > Additionally this design has two nice properties: the default > > > behavior is > > > > > > RFC-compliant, and it means that for my use-case I don't need t= o > > > change > > > > > the > > > > > > config file, which was a big part of my motivation for doing th= is > > > inside > > > > > of > > > > > > musl in the first place :-) > > > > > > > > > > As discussed in this thread, I don't think so. The biggest proble= ms I > > > > > initially brought up were increased information leakage in the de= fault > > > > > configuration and inability to control where the traffic goes whe= n you > > > > > do want it on. The above proposal just reverts to the initial, ex= cept > > > > > for providing a way to opt-out. > > > > > > > > > > For the most part, mDNS is very much a "home user, personal devic= e on > > > > > trusted network" thing. Not only do you not want it to default on > > > > > because a lot of systems will be network servers on networks wher= e > > > > > it's not meaningful (and can be a weakness that aids attackers in > > > > > lateral movement), but you also don't want it on when connected t= o > > > > > public wifi. For example if you have an open browser tab to > > > > > http://mything.local, and migrate to an untrusted network (with y= our > > > > > laptop, tablet, phone, whatever), now your browser will be leakin= g > > > > > private data (likely at least session auth tokens, maybe more) to > > > > > whoever answers the mDNS query for mything.local. > > > > > > > > That's not quite right. The security properties of mDNS and DNS are= the > > > > same. DNS is inherently insecure, regardless of unicast vs multicas= t. If > > > > I'm on a coffee shop Wi-Fi, all my DNS queries are sent in the clea= r to > > > > whatever IP address the DHCP server gave me. > > > > > > That's not the case. Connections to non-mDNS hosts are authenticated > > > by TLS with certificates issued on the basis of ownership of the > > > domain name. That's not possible with mDNS hostnames, so they'll > > > either be no-TLS or self-signed certs. That's why the above attack is > > > possible. It was also possible with normal DNS in the bad old days of > > > http://, but that time is long gone. > > > > Apologies for being pedantic, but that's not true. The ability to get T= LS > > certificates for a domain name that you own is a property of the WebPKI= , > > not a property of TLS. What you wrote is true, but only in the context = of a > > Web browser with an unmodified root certificate store. The features I > > mentioned above don't use the WebPKI, they have a separate root of trus= t. > > For example, some of those Apple features exchange TLS certificates via= an > > out-of-band mechanism such as Apple trusted servers. Another example is= the > > Apple Watch: when you first pair a new Apple Watch with an iPhone, they > > exchange ed25519 public keys. Then any time the watch wants to transfer= a > > large file to/from the phone, it'll connect to Wi-Fi, use mDNS to find = the > > phone, and set up an IKEv2/IPsec tunnel that then protects the exchange= . > > It's resilient to any attacks at the mDNS level. > > > > You're absolutely right that the security of Web requests using local > > connectivity is completely broken by the lack of WebPKI certificates fo= r > > those. But sending the DNS query over multicast as opposed to unencrypt= ed > > unicast to an untrusted DNS server doesn't change the security properti= es. > > In your example above, the open tab to http://mything.local will send t= hat > > query to the recursive resolver - and if that's the one received by DHC= P > > then that server can reply with its own address and receive your auth > > tokens. One potential fix here is to configure your resolv.conf to > > localhost and then apply policy in that local resolver. But in practice= , > > application developers don't rely on security at that layer, they assum= e > > that DNS is unsafe and implement encryption in userspace with some out = of > > band trust mechanism. > > My specific example was http://mything.local in a web browser, which > is the way you access lots of mDNS-enabled things in the absence of a > specific software ecosystem like Apple's. Since we're talking about > musl which would be running on Linux or a Linux-syscall-compatible > environment, without Apple apps, I think that's the main way anyone > would be using hypothetical mDNS support. And indeed this is the way > you access many printers, 3D printers, IP cameras, etc. > > Maybe at some point we'll have a good framework for authenticating > this kind of usage with certificates (probably certificate pinning on > first use, with good UX, is the only easy solution), but at present, > mDNS devices on the .local zone get accessed with plain http:// all > the time, and this means it's unsafe to do mDNS on > public/untrusted/hostile networks. One comment about pinning. I think host key pinning is a great security control. Key continuity is a better security property than key rotation. Unfortunately, the CA/Browser Forum and IETF are moving the other way. They are hostile to pinning, they are actively working against it by using short-lived intermediate CA certificates, by not providing key rollover hints in existing certificates, and recommending a new key for each end-entity (host) certificate. I was very disappointed to see the IETF get onboard with the CA/Browser Forum. It looks like the IETF has been captured again. So pinning may not be a viable solution when the time comes. Jeff