An open discussion list for topics related to the geteduroam service

[Hideaki GOTO <hgot AT cc.tohoku.ac.jp>]

Hi Darren,

Have you tried the latest version of FreeRADIUS (3.2.0)?
There were some TLS-related issues in earlier versions 3.0.x.
Presumably, it might be affecting as I see a message reading
  eap_tls: TLS_accept: Need to read more data: error

--
Hideaki Goto

2022年8月17日(水) 21:55 Darren Boss <geteduroam AT lists.geant.org>:
>
> I redeployed the portal on Debian 11.4 (Bullseye) but now I'm getting a 
> error 400 on the call from the Android app to /api/eap-config/. I decided 
> to log the Authorization header to a custom log and was able to decode it 
> using a JWT decoder. Looks fine, sub claim is my email address (using email 
> nameid from Azure AD). Including the decoded JWT in case it's something 
> obvious:
>
> {
>   "__t": "access_token",
>   "iat": "1660739494",
>   "sub": "Darren.Boss AT alliancecan.ca",
>   "realm": "alliancecan.ca",
>   "scope": "eap-metadata",
>   "code_challenge_method": "S256",
>   "code_challenge": "LQpjYE1ZjYAC6i9OwaU3OFYUBR9-rV-X0ohvYcXpLi4",
>   "client_id": "app.eduroam.geteduroam",
>   "redirect_uri": "app.eduroam.geteduroam:/",
>   "exp": "1676637094"
> }
>
> jwt.io is flagging the dates as invalid but they look right to me and the 
> iat matches the date of the apache log entry.
>
> From: geteduroam-request AT lists.geant.org 
> <geteduroam-request AT lists.geant.org> on behalf of Darren Boss 
> <geteduroam AT lists.geant.org>
> Sent: Tuesday, August 16, 2022 3:17 PM
> To: Paul Dekkers <paul.dekkers AT surf.nl>
> Cc: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
> Subject: Re: Problem with certificates generated
>
> I pulled an older Android device out of storage but the errors I'm seeing 
> on the freeradius server are the same as on the newer Android 12 device. 
> I'm not expecting anyone to debug my radius setup, just providing the debug 
> output here in case it's relevant to the portal configuration or someone 
> has encountered a similar issue:
>
> (7) eap: Peer sent EAP Response (code 2) ID 151 length 13
> (7) eap: No EAP Start, assuming it's an on-going EAP conversation
> (7)     [eap] = updated
> (7)   } # authorize = updated
> (7) Found Auth-Type = eap
> (7) # Executing group from file /etc/raddb/sites-enabled/default
> (7)   authenticate {
> (7) eap: Expiring EAP session with state 0xcaea98f1c87d95e7
> (7) eap: Finished EAP session with state 0xcaea98f1c87d95e7
> (7) eap: Previous EAP request found for state 0xcaea98f1c87d95e7, released 
> from the list
> (7) eap: Peer sent packet with method EAP TLS (13)
> (7) eap: Calling submodule eap_tls to process data
> (7) eap_tls: Continuing EAP-TLS
> (7) eap_tls: [eaptls verify] = ok
> (7) eap_tls: Done initial handshake
> (7) eap_tls: <<< recv TLS 1.2  [length 0002]
> (7) eap_tls: ERROR: TLS Alert read:fatal:internal error
> (7) eap_tls: TLS_accept: Need to read more data: error
> (7) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094438:SSL 
> routines:ssl3_read_bytes:tlsv1 alert internal error
> (7) eap_tls: TLS - In Handshake Phase
> (7) eap_tls: TLS - Application data.
> (7) eap_tls: ERROR: TLS failed during operation
> (7) eap_tls: ERROR: [eaptls process] = fail
> (7) eap: ERROR: Failed continuing EAP TLS (13) session.  EAP sub-module 
> failed
>
> I find debugging Radius issues quite challenging because I work with radius 
> very frequently. This is all non-production so I can make sweeping changes 
> to the radius configuration. I followed the guide at 
> https://wiki.freeradius.org/guide/eduroam and I was also responsible for 
> another organization's eduroam radius server which was and still is working 
> but using EAP-PEAP with OpenLDAP. This time I'm quite determined to do 
> EAP-TLS with the portal app using SAML auth to Azure AD IdP.
> A very basic (but functional) eduroam configuration - FreeRADIUS
> mods-available/eap eap { # The initial EAP type requested. Change this to 
> peap if you're # using peap, or tls if you're using EAP-TLS. 
> default_eap_type = ttls # The maximum time an EAP-Session can continue for 
> timer_expire = 60 # The maximum number of ongoing EAP sessions max_sessions 
> = ${max_requests} tls-config tls-common { # The public certificate that 
> your server will present certificate ...
> wiki.freeradius.org
>
>
>
> Darren Boss (he/him)
> Senior Programmer | Développeur Sénior
>
>
>      343-341-2323
>
>
> From: Paul Dekkers <paul.dekkers AT surf.nl>
> Sent: Tuesday, August 16, 2022 12:08 PM
> To: Darren Boss <Darren.Boss AT alliancecan.ca>
> Cc: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
> Subject: Re: Problem with certificates generated
>
>
> You don't often get email from paul.dekkers AT surf.nl. Learn why this is 
> important
>
> Hi,
>
> Ok, so I suspect the issue you're seeing that is fixable with the -legacy 
> flag is only on your local system; yet we don't currently configure a 
> passphrase for the .pkcs12 files that are manually downloaded so I didn't 
> expect you to have that problem on manual downloaded certificates. If you 
> extracted the pkcs12 payload from the .eap-config, this makes more sense.
>
> Android 12 and Pixel 6 should just work; at least I just used Android 12 on 
> a Pixel 5 a couple of times today and that worked ;-)
>
> We need to look at generating a pkcs12 with a supported algorithm for 
> end-user devices with OpenSSL 3; but I don't expect your Android phone has 
> that already unless that's pushed to a very recent Android 12 update? (Feel 
> free to suggest a fix ;-) The fix may actually also be to run the server on 
> an OpenSSL 3 server maybe, hmm. Like Ubuntu 22.04.)
>
> If you want to rule things out, I can give you a test-account at a demo 
> instance (running Debian) so you can test if it happens there or is 
> something related to your local letswifi-ca deployment? (Send me a private 
> mail if you want to try that.)
>
> Regards,
> Paul
>
>
> On 16/08/2022 18:01, Darren Boss wrote:
> On the Rocky 8.6 vm:
> OpenSSL 1.1.1k  FIPS 25 Mar 2021
>
> On my local system (Fedora 36) where I'm running openssl to inspect the 
> certs/keys:
> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>
> Android version is 12 on a Pixel 6
>
>
> Darren Boss (he/him)
> Senior Programmer | Développeur Sénior
>
>
>      343-341-2323
>
>
> From: Paul Dekkers <paul.dekkers AT surf.nl>
> Sent: Tuesday, August 16, 2022 11:56 AM
> To: Darren Boss <Darren.Boss AT alliancecan.ca>
> Cc: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
> Subject: Re: Problem with certificates generated
>
>
> You don't often get email from paul.dekkers AT surf.nl. Learn why this is 
> important
>
> Hi,
>
> What version of OpenSSL does your Rocky server run, and what version of 
> Android are you testing with?
>
> Regards,
> Paul
>
>
> On 16/08/2022 17:12, Darren Boss (via geteduroam Mailing List) wrote:
> I've been able to setup the portal app without too much trouble but while 
> testing with Android it wasn't working and I started looking closely at the 
> assets downloaded manually from the portal. The PKCS12 button generates a 
> file that when I try inspecting with openssl, shows this error:
> Error outputting keys and certificates
> 401C6D75A67F0000:error:0308010C:digital envelope 
> routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global
>  default library context, Algorithm (RC2-40-CBC : 0), Properties ()
>
> When using the -legacy flag, I can convert the format and even get my 
> profile working with a Linux laptop and our appropriately configured 
> freeradius server.
>
> The certs in the mobileconfig are using this cipher as well if I copy out 
> the base64 encoded string, decode, and inspect with openssl from the 
> command line.
>
> The vm running the portal app is running Rocky 8.6 and PHP 7.4 from the 
> Rocky repos. Is the error I see in the manual downloads unusual? Any tips 
> for doing further debugging or thoughts about what I'm seeing? I'm thinking 
> of deploying on a Debian based vm just to see if the behavior is different.
>
> Darren Boss (he/him)
>
> Senior Developer | Développeur Senior
>
>
>
> darren.boss AT alliancecan.ca
>
> 343-341-2323
>
> 0000-0001-7588-9500
> alliancecan.ca
>
>
>