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

[Stefan Winter <address@concealed>]

Hi,

> The root certificate isn't the problem here. The main issue is that 
> chromeOS denies our radius certificate due to a too 'weak' Diffie-Hellman.

Ah. Well that is something entirely different. Here on the cat-users
mailing list we talk about the CAT service which installs certificates
and more, as a one-time operation before actually /using/ eduroam.

Diffie-Hellman parameters are used during the actual authentication.
They are not a property of any certificate - they are a cryptographic
auxiliary parameter on the system, not in the certificate - and so are
nothing a CAT installer even sees.

So, when you talked about refused certificates, I looked up known issues
we have about certificates and their rejection during installation time
with a CAT installer.

So, strictly spoken, your request is off-topic for this list.

> I already reported this to one of our certificates specialist so we can 
> check this matter from our side. Is this a problem that has been reported 
> previously by any other university? (Because I found this article online) 
> and it seems like a common issue:

The weaknesses of DH and the discontinuation of 1024 bit sizes is a
well-known situation in the IT industry. A few years back, almost every
web server admin had to touch his DH file to make it 2048 bits or more.
1024 DH parameters are as unsafe in a web browser context as in any
other cryptographic context, such as the TLS tunnel establishment with
EAP authentication.

I would think this problem has weathered out in the last few years as
software defaults to larger sizes since a while. As a random data point,
I looked at the FreeRADIUS 3.0.10 (October '15) cert generation Makefile
and it has 2048 bits as the DH size already.

> https://groups.google.com/forum/#!topic/appsusergroup/JjHRpfkS8kg
> 
> --
> 1. What's happening?
> 
> - The main problem here is the Diffie Hellman weakness, this is a 
> mathematical algorithm that is used to exchange a shared secret between two 
> parties (i.e.: client and server). This shared secret can then be used to 
> encrypt messages between the two parties and/or authenticate networks.
> 
> - With the recent wave of further SSL attacks on the tech community, Chrome 
> OS and other systems are making moves to stop SSL clients from negotiating 
> connections where the parameters have weak Diffie-Hellman (DH) keys.
> 
> 2. Behavior:
> 
> - Customers affected by this issue are reporting that they are not able to 
> connect to their PEAP/EAP-xxx networks.  This is most likely due to the 
> fact that an appliance in their environment is using a DH key with sub-1024 
> bit encryption (i.e.: radius server, vpn concentrator, etc.)
> 
> 3. The workarounds given are:
> 
> - Upgrading the DH parameter file to 2048 bit       -or-
> 
> - Use PPSK instead of EAP-xxx                            -or-
> 
> - Update firmware on appliance
> 
> 4. What I would recommend:
> 
> - Contact your network administrator and certificate issuer to upgrade the 
> DH parameter file to 2048 bit, this will increase your certificate quality 
> and security and it will allow the connection to succeed.
> 
> 5. For more details about the Diffie Hellman attacks, please visit 
> https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html.

Well, glad you found that link. It explains all this in a nice way. I
suggest you do what that post recommends :-)

Greetings,

Stefan Winter

> --
> 
> As for Windows Phone. Exactly what I thought.
> 
> Thanks for the assistance!
> 
> Regards,
> Dave
> 
> -----Original Message-----
> From: Stefan Winter <address@concealed> 
> Sent: vrijdag 5 oktober 2018 10:56
> To: Rozenblad, D. (Dave) <address@concealed>; 'address@concealed' 
> <address@concealed>
> Cc: Canoy, V.C.M. (Veronica) <address@concealed>; Willems, T. (Tamira) 
> <address@concealed>; Pol, F.A. (Ferdinand) <address@concealed>
> Subject: Re: [[cat-users]] Eduroam CAT ChromeOS
> 
> Hello,
> 
>> We’ve been using Eduroam CAT as a primary Eduroam configurator for our 
>> university. Unfortunately, unlike other systems ChromeOS somehow (in 
>> some cases) gives us a certificate locally rejected error. Is this a 
>> known issue and is there anything we can do to solve or work-around 
>> this matter? The certificates (when I try to install them via 
>> Settings) are giving the message ‘Already Installed’.
> 
> Is the CA by any chance one that issues EV certificates? We found earlier 
> that ChromeOS treats EV CAs very specially. It considers the addition of 
> the same CA to the Wi-Fi store as an overwrite of its EV trust store and 
> refuses to do this.
> 
> If you are unsure if this is the case, or if you know it is not and want me 
> to investigate further, you would need to send me a copy of the root CA 
> certificate. It's fine to do that off-list.
> 
>> Also I’d like to state that there’s no Windows Phone version but I 
>> guess it won’t be supported or..?
> 
> We put quite some effort into trying this many years ago and ran into some 
> intentionally constructed walls on the OS side.
> 
> And these days, all I can say is that even the manufacturer has given up on 
> the platform. So this is nothing we want to sink time into any more.
> 
> 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
> 


-- 
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: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature