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:
gnome-desktop-environment
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:
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08
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
discard).
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: