[RADIATOR] Certificate Not Trusted - InCommon?

[Stefan Paetow]

Well, whether they are less secure is subjective.

WPA-PSK does not require a username or password. It just requires you to enter the key and get access. That’s handled by the WPA2 process.

Any captive portal requiring a username and password will be managed by either the hotspot that displays the captive portal (and as such one would hope the security certificate for said portal will be one signed by a commercial CA that is trusted by the device OS, because the captive portal pages are browser-based), or it will be sent (hopefully securely) to a third party. Under *NO* circumstances should *any* student/staff member *ever* enter their university/organisation usernames and passwords into a captive portal system *unless* they are categorically sure that it is run by their university/organisation. The risk to the university/organisation and its systems is much too great. In the day and age of ransomware attacks, all it takes is *one* username with access to a system, which can be used to break into others, to inflict untold damage to the university/organisation and its students/employees/both.

However, since universities and other organisations (including large enterprises) tend to be paranoid (which is a good thing), they would very much not like to have usernames and passwords used on *their* systems handed over to anyone. This is why WPA-Enterprise works the way it does. It provides a level of trust in the sense that devices will be either manually configured or set up through a mobile device management (MDM) solution (like Apple Configurator or Microsoft’s InTune) which in turn will ensure that only the right certificate is trusted (usually that involves a CA certificate and a set of CN and/or subjectAltName entries), or, in the most basic case, a certificate is pinned. The latter becomes a problem when a certificate is renewed as the new certificate will no longer match the pinned fingerprint, and the trust breaks (and no authentication takes place). In the user’s eyes that’s extremely suboptimal, although from the security officer of the user’s organisation’s perspective, it’s exactly what’s expected.

By ensuring the CA certificate is either one of your own (and you’ve put it on the device with your MDM (or something like geteduroam, the eduroam CAT website or, on Android, the now virtually obsolete eduroam CAT app), you ensure that any server claiming to be your home server better be signed by your CA, or, just like a browser would (in strict mode), be rejected for being a liar and a fraud. You can use a commercial certificate, sure, but by doing that you trust that the commercial CA who signed that certificate doesn’t make a mess (like several have in the last 12-18 months).

I hope that explains things a little more from the security/tech aspect.

With Kind Regards

Stefan Paetow
Federated Roaming Technical Specialist

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp at jabber.dev.ja.net
skype: stefan.paetow.janet
In line with government advice, at Jisc we’re now working from home and our offices are currently closed. Read our statement on coronavirus<https://www.jisc.ac.uk/about/corporate/coronavirus-statement>.

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.


From: radiator <radiator-bounces at lists.open.com.au> on behalf of "Ullfig, Roberto Alfredo" <rullfig at uic.edu>
Date: Thursday, 9 September 2021 at 17:41
To: Heikki Vatiainen <hvn at open.com.au>, "radiator at lists.open.com.au" <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] Certificate Not Trusted - InCommon?

You're right - there is no username. Just an SSID and credentials. So why do these services not require trusting a certificate? Are those services less secure? Is the shared password going over in clear text?

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen <hvn at open.com.au>
Sent: Thursday, September 9, 2021 10:59 AM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] Certificate Not Trusted - InCommon?

On 9.9.2021 18.11, Ullfig, Roberto Alfredo wrote:

> No, I'm referring to WiFi offered at airports, coffee shops, bars, or at
> someone's home etc... You are given a username and password and the
> phone shows the SSID, you just enter the username and password and are
> connected. There is never a window asking you to trust a certificate.

Could be WPA-Personal, also known as WPA-PSK, where a shared secret (Pre
Shared Key) is needed, or Wi-Fi Protected Setup? But I think these don't
require a username. One option is a built-in client that launches a
customised browser to help with captive portal login.

The problem with the above is that Wi-Fi client software in your device
does not know how to authenticate the network. The network demands that
credentials are used but the Wi-Fi client software has nothing to demand
from the network.

Thanks,
Heikki

--
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software
_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=04%7C01%7Crullfig%40uic.edu%7C223082975583478ac9e208d973aaf2f4%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637668000789719424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=kwMBZeGt00F7dz4i7dD%2FH8Op%2FwfX6VZmzKxDEOqZe28%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210910/104a3775/attachment-0001.html>