Hi, Am 19.07.20 um 14:58 schrieb Alan DeKok:
IIRC, PEAP enables TLS compression by default (i.e. requires it), and TTLS doesn't. That might be the difference here.
just an update. Currently, it looks like we're heading for "corner case". My limited ideas include exploring above mentioned TLS compression, some weird effect of our unusually long realms (causing fragmentation, adding complexity--really??). More testing, perhaps with a reduced, debugging-friendly setup, will be required. And, of course, the SSL Flags (0x04 vs. 0x00) seen in the EAP packets are giving me headache. Being far from understanding eap_tls.c, is eap_tls_compose() the function where the message triggering failure is assembled? From RFC 2716, sec. 4.2, I would conclude that a Flags octet of 0x04 means that the S (start) bit is set, is this right? And regardless, should this really differ between libssl versions at this step of the EAP-TLS negotiation? Another observation: thm.de is running the exact combination of Debian Buster with 1.1.1d-0+deb10u3:amd64 and FR 3.0.21 Packets and very similar TLS config (thx to Sven). Through our radsec proxy servers, I can trigger an eapol_test simulating some THM eduoram user. Not having a real account, I get rejected, but the cert verification is 100% fine, as with their real clients. For completeness, the eapol_test output is attached. I'm on vacation for the next two weeks, so delayed replies to any comments should not be seen as lack of interest. Thanks to everyone for looking into this so far Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg