[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Disable ZeroConf: how to ?

On Wed, Mar 2, 2011 at 10:24 PM, Josselin Mouette <joss@debian.org> wrote:
> Le mercredi 02 mars 2011 à 18:25 +0100, Bastien ROUCARIES a écrit :
>> And more specifically from an administrator point of view does avahi
>> could library could be made purgeable and no more than suggest
>> dependencies (I am willing to fill a mass bug report because purging
>> avahi will purge gnome and kde ...) ?
> As Philipp pointed out, only gnome depends on it, and that’s not
> gnome-desktop-environment. You can use the latter if you want only the
> official GNOME desktop.

Not true anymore see below:
 Depends: gnome-user-share
   Depends: libapache2-mod-dnssd
     Depends: avahi-daemon
 Recommends: telepathy-salut
   Depends: avahi-daemon

>> And moreover could you give a clear answer about the security risk on
>> untrusted network ?
> I’d say Avahi is mostly as insecure as the services that use it for
> advertising.

Yes I have just read the draft RFC and it document some pitfall in
insecure network:
In an environment where the participants are mutually antagonistic
   and unwilling to cooperate, other mechanisms are appropriate, like
   manually administered DNS.

   In an environment where there is a group of cooperating participants,
   but there may be other antagonistic participants on the same physical
   link, the cooperating participants need to use IPSEC signatures
   and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
   messages from trusted participants (which they process as usual) from
   mDNS messages from untrusted participants (which they silently

   When DNS queries for *global* DNS names are sent to the mDNS
   multicast address (during network outages which disrupt communication
   with the greater Internet) it is *especially* important to use
   DNSSEC, because the user may have the impression that he or she is
   communicating with some authentic host, when in fact he or she is
   really communicating with some local host that is merely masquerading
   as that name. This is less critical for names ending with ".local.",
   because the user should be aware that those names have only local
   significance and no global authority is implied.

   Most computer users neglect to type the trailing dot at the end of a
   fully qualified domain name, making it a relative domain name (e.g.
   "www.example.com"). In the event of network outage, attempts to
   positively resolve the name as entered will fail, resulting in
   application of the search list, including ".local.", if present.
   A malicious host could masquerade as "www.example.com." by answering
   the resulting Multicast DNS query for "www.example.com.local."
   To avoid this, a host MUST NOT append the search suffix
   ".local.", if present, to any relative (partially qualified)
   host name containing two or more labels. Appending ".local." to
   single-label relative host names is acceptable, since the user
   should have no expectation that a single-label host name will
   resolve as-is.

Reply to: