cat-users AT lists.geant.org
Subject: The mailing list for users of the eduroam Configuration Assistant Tool (CAT)
List archive
- From: Tomasz Wolniewicz <twoln AT umk.pl>
- To: cat-users AT lists.geant.org
- Subject: Re: [[cat-users]] Linux installer: upcoming behaviour change
- Date: Wed, 6 Apr 2016 21:50:54 +0200
Hi,
I have tested an implementation of altsubject-matches in our Linux
installers on recent Linux distributions and things seem to work nicely.
While thinking about it I also begun to wonder if our current fallback -
preparation of a wpa_supplicant configuration file actually serves any
purpose. On a system without Network Manager we collect user's data and
then fail Network Manager installation and just create a wpa_supplicant
configuration file. This file contains user's eduroam access password,
which has raised some concern on this list.
I have a feeling that an average user will not have no clue what to do
with this configuration file. In a typical situation the fall-back will
happen when the network is managed by something else then Network
Manager so the wpa_supplicant file will not be of direct use.
Therefore I would suggest that the installer first detects if it can
interact with Network Manager and if not just informs the user that it
cannot continue.
Does anyone think that the current wpa_supplicant.conf fall-back should
be preserved?
Cheers
Tomasz
W dniu 2016-02-23 o 14:49, Stefan Winter pisze:
> Hello!
>
> We would like to notify you that starting with the coming version 1.1.2
> (no release date yet), the Linux installer will examine a different part
> of the server certificate than before to verify the server name (old:
> Subject, new: subjectAltName:DNS).
>
> The Linux installer is actually two installers in one: it will either
> configure NetworkManager or generate a wpa_supplicant.conf.
>
> Up until recently, both variants used the subject_match / subject-match
> directives. This setting operates on the "Subject" part of the
> certificate (better known as the CN, even if not quite correct).
>
> There is an issue with using subject_match: it is a substring match, and
> a cleverly crafted certificate *from the same CA* could impersonate
> itself as the real server, and be considered trusted with the correct
> name even if it had a different name. That is, naturally, an imperfect
> situation.
>
> As an immediate stop-gap, at least the wpa_supplicant.conf variant was
> changed to use domain_suffix_match - which still operates on Subject,
> but considers the match a suffix match (i.e. it would complain about
> trailing "garbage"), not a substring one. This fixes the impersonation
> issue and had no backward compatibility problems / behaviour change
> requirements.
>
> Unfortunately, that same domain_suffix_match parameter is not available
> in NetworkManager, so we could not fix the issue in a gentle way there.
>
> The more proper fix is to use the configuration options altsubject_match
> / altsubject-matches . They are available in both variants, and they
> compare exact strings. This also fixes the impersonation issue, this
> time on all Linux installation variations we support. That provides a
> permanent fix to the "substring" loophole, and is synchronous behaviour
> across variants.
>
> The behaviour change (thanks for reading this far :-) ) is however that
> the server name is not extracted from Subject / CN but from the
> subjectAltName:DNS field(s) in the certificates.
>
> This should not have a significant impact on any IdP deployment because
> - certificates from most CAs contain both CN and an identical
> subjectAltName:DNS
> - other supplicants already consider subjectAltName:DNS, so your
> deployment is arguably a bit broken right now if your cert doesn't have
> this property
> - ever since version 1.1, CAT emits a WARNING level advice during the
> realm checks if the CN and subjectAltName:DNS values in your certificate
> do not both match your CAT configured server name(s).
>
> Still, if your certificate does not have matching subjectAltName:DNS
> (i.e. you've always ignored our warning so far), then the Linux
> installers of version 1.1.2 and up might refuse to authenticate the
> server. You may want to think about a new server certificate if you care
> about Linux then.
>
> Greetings,
>
> Stefan Winter
>
--
Tomasz Wolniewicz
twoln AT umk.pl
http://www.home.umk.pl/~twoln
Uczelniane Centrum Informatyczne Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University,
pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576
- Re: [[cat-users]] Linux installer: upcoming behaviour change, Tomasz Wolniewicz, 04/06/2016
- Re: [[cat-users]] Linux installer: upcoming behaviour change, A . L . M . Buxey, 04/06/2016
- Re: [[cat-users]] Linux installer: upcoming behaviour change, Tomasz Wolniewicz, 04/07/2016
- Re: [[cat-users]] Linux installer: upcoming behaviour change, Louis Twomey, 04/25/2016
- Re: [[cat-users]] Linux installer: upcoming behaviour change, Tomasz Wolniewicz, 04/07/2016
- Re: [[cat-users]] Linux installer: upcoming behaviour change, A . L . M . Buxey, 04/06/2016
Archive powered by MHonArc 2.6.19.