The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Winter <stefan.winter AT restena.lu>]

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

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature