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

[Stefan Winter <address@concealed>]

Hello,

attached is a screenshot of the new error-level condition when we detect
that an EAP conversation broke in the middle of an ongoing TLS
handshake, before receiving a server cert.

Since the server cert is the only thing that gives away the actual name
of the server we ended up at, we had to label it "Connected to
*undetermined server*".

This will go into 2.0.1. Unfortunately, that's new text to translate so
I have to give translators extra time for that. So the source release
and deployment on cat.eduroam.org is going to be delayed by a few days.

BTW: if an empty local part ("@realm.tld") is the /only/ username that
creates trouble for that server, and if the IdP admins are sure that
*no* real end user is going to use that username, then the admin can set
the option "User special Outer Identity for realm checks" in the
corresponding profile and set that to a non-empty value. Our tests will
then use that other username instead of the default.

Once this is set in the admin side, also the end-user diagnostics will
take that other username into account.

Greetings,

Stefan

Am 02.04.19 um 16:28 schrieb Tom Ivar Myren:
> Thanks Stefan - for providing fast and accurate troubleshooting :-)
> 
> Br, 
> Tom Myren
> 
> -----Opprinnelig melding-----
> Fra: Stefan Winter <address@concealed>
> Svar til: Stefan Winter <address@concealed>
> Dato: tirsdag 2. april 2019 15:14
> Til: Anders Baardsgaard <address@concealed>, 
> "address@concealed" <address@concealed>
> Kopi: Tom Ivar Myren <address@concealed>
> Emne: Re: [[cat-users]] Strange eduroam error msg: magicTelepath error
> 
>     Hello,
>     
>     for the benefit of the mailing list:
>     
>     this condition is indeed a bit out of the ordinary. It is related to a
>     server which has problems accepting outer identities with an empty
>     username part (i.e. "@restena.lu" instead of "address@concealed") -
>     and CAT happens to test with an outer username of @something by default.
>     
>     These misconfigurations exist more often, but almost always the request
>     is rejected immediately, before the actual EAP conversation starts. That
>     is a condition we check for and display appropriately.
>     
>     Here, the server first accepts the access request, negotiates PEAP,
>     starts TLS ClientHello/ServerHello exchange, and only when asked by the
>     client to present its server certificate, it sends a Reject instead.
>     
>     We were /not/ prepared to be sent away during an ongoing TLS handshake
>     before any certificate is even exchanged.
>     
>     I have now fixed this in code, and version 2.0.1 will conclude end-user
>     diagnostics correctly and attribute the failure to produce a server
>     certificate as an IdP error.
>     
>     We are also currently fixing the UI of the administrator-side realm
>     checks so that they also display this error condition correctly in the
>     future.
>     
>     Greetings,
>     
>     Stefan Winter
>     
>     Am 02.04.19 um 09:44 schrieb Stefan Winter:
>     > Hello,
>     > 
>     > I can reproduce the problem. It appears that this happens only with 
> the
>     > realm "uit.no": If you run a test for "uninett.no", U.S.A., Georgetown
>     > University then the system will correctly identify that there is no
>     > infrastructure problem with this combination and will continue with
>     > user-interactive questions for further diagnosis.
>     > 
>     > Looking at uit.no, this falls over not only for diagnostics, but also
>     > inside the admin-only realm checks. The failure there is more subtle
>     > though: you get a result stating:
>     > 
>     > "Test partially successful: a bidirectional RADIUS conversation with
>     > multiple round-trips was carried out, and ended in an Access-Reject as
>     > planned. Some properties of the connection attempt were sub-optimal; 
> the
>     > list is below."
>     > 
>     > But then there is no "below"; the list of warnings is not populated.
>     > 
>     > So, there is something special about uit.no, but a variety of special
>     > that we haven't encountered before.
>     > 
>     > From a first look, this would be a certificate issue (either there is
>     > something wrong with the certificate, or our parser misinterprets the
>     > potentially good certificate).
>     > 
>     > I am investigating this issue right now and hope to be able to come 
> back
>     > with more concrete results soon.
>     > 
>     > Greetings,
>     > 
>     > Stefan Winter
>     > 
>     > Am 01.04.19 um 13:54 schrieb Anders Baardsgaard:
>     >> Hi,
>     >>
>     >> one of our researchers is currently visiting Georgetown University, 
> USA,
>     >> and he's having problems with eduroam. He writes that he receives an
>     >> error message on Eduroam Diagnostics Site, when writing UiT.no as the
>     >> host institution: magicTelepath error
>     >>
>     >> I asked  Uninett for advice, and the conclusion is that something is
>     >> wrong with cat.eduroam.org:
>     >>
>     >> [Error] Failed to load resource: the server responded with a status 
> of
>     >> 500 (Internal Server Error) (magicTelepath.php, line 0)
>     >>
>     >> 
> https://cat.eduroam.org/diag/magicTelepath.php?realm=uit.no&lang=en&visited=0
>     >>
>     >> At this point I have left my home ground wrt. knowledge. Any advice?
>     >>
>     >>  -- Anders
>     >>
>     >> --
>     >>
>     >> Anders Baardsgaard
>     >>
>     >> Senioringeniør Infrastruktur, Grunntjenester, IT-avd
>     >>
>     >> UiT - Norges arktiske universitet
>     >>
>     >>
>     >> To unsubscribe, send this message:
>     >> mailto:address@concealed?subject=unsubscribe%20cat-users
>     >> Or use the following link:
>     >> https://lists.geant.org/sympa/sigrequest/cat-users
>     > 
>     > 
>     
>     
>     -- 
>     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
>     
> 
> To unsubscribe, send this message: 
> mailto:address@concealed?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users
> 


-- 
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: Screenshot_20190404_082324.png
Description: PNG image

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

Attachment: signature.asc
Description: OpenPGP digital signature