Certificate problem between 3.0.11 and 3.1.x

[Matthew Newton]

On Fri, Mar 18, 2016 at 09:23:20AM +0000, Scott Armitage wrote:
> Alan Buxey and myself have spent some time and believe we have tracked down the commit which broke EAP:
> 
> commit 8a7f6e330f45439d333f61dde7ee0982ebcc2a29
> Author: Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> Date:   Sun Dec 6 00:34:21 2015 -0500
> 
>     Add additional debugging so we can track TLS fragments sent

Hmm. If that's the case, then the bug is probably to do with the
length included flag and the length of the packet.

What does the EAP data look like in the packet sent before it
breaks immediately after this patch, and in the equivalent packet
before this patch?

Specifically in EAP-Message it's the 8th bit ("length included")
and 7th bit ("more fragments") of the 6th octet ("flags"), the
"message length" field (7th, 8th, 9th and 10th octets) and the
EAP-Message length (3rd and 4th octets). So fragments should be c0
on the first fragment, 40 on intermediate fragments and 00 on the
last fragment. Or 80 for a standalone packet (no further
fragments).

These look OK in the original debug output, but the lengths for
each packet look a bit odd in this sequence starting

(1)      eap_peap - Complete TLS record (2245 bytes) larger than MTU (1000
bytes), will fragment
(1)      eap_peap - Sending first TLS record fragment (1000 bytes), 1245 bytes
remaining
(1)      eap_peap - [eap-tls process] = handled
(1)      vpieap - Sending EAP Request (code 1) ID 4 length 1010
(1)      vpieap (handled)
(1)    } # authenticate (handled)
(1)  Using Post-Auth-Type Challenge
(1)  Post-Auth-Type sub-section not found.  Ignoring.
(1)  Running Post-Auth-Type Challenge from file /etc/raddb/sites-enabled/vpi
(1)  Sent Access-Challenge Id 157 from 137.222.8.134:16020 to
172.17.107.208:32770 via ens192 length 0
(1)    EAP-Message = 0x010403f219c0000008c5160301003902000035030156e823361b5cba1ccb77c8d1c2d294e5648fa5293f6acb6c7e0b210e9899de6e00c01400000dff01000100000b00040300010216030107290b0007250007220002dc308202d830820282020410456227300d06092a864886f70d01010b05003081bf
(1)    Message-Authenticator = 0x00000000000000000000000000000000
(1)    State = 0x02036e003ffa67036d696f996ec2a586
(1)  Finished request

1000 bytes, 1245 remaining. OK. 000008c5 is 2245. 03f2 is 1010,
which is 1000 plus 10 (header octets) but length of that attribute
is only 119 octets. Flags are OK.

The next two challenges are similar

(2)      eap_peap - Sending additional TLS record fragment (1004 bytes), 241
bytes remaining
(2)      eap_peap - [eap-tls process] = handled
(2)      vpieap - Sending EAP Request (code 1) ID 5 length 1010
(2)      vpieap (handled)
(2)    } # authenticate (handled)
(2)  Using Post-Auth-Type Challenge
(2)  Post-Auth-Type sub-section not found.  Ignoring.
(2)  Running Post-Auth-Type Challenge from file /etc/raddb/sites-enabled/vpi
(2)  Sent Access-Challenge Id 158 from 137.222.8.134:16020 to
172.17.107.208:32770 via ens192 length 0
(2)    EAP-Message = 0x010503f219402053657276696365733129302706035504031320556e6976657273697479206f662042726973746f6c2057696e646f7773204341301e170d3033303131303130323733375a170d3233303131303130333531315a3081bf3125302306092a864886f70d010901161663612d61646d696e40

Same length attribute.

(3)      eap_peap - Sending final TLS record fragment (241 bytes)
(3)      eap_peap - [eap-tls process] = handled
(3)      vpieap - Sending EAP Request (code 1) ID 6 length 247
(3)      vpieap (handled)
(3)    } # authenticate (handled)
(3)  Using Post-Auth-Type Challenge
(3)  Post-Auth-Type sub-section not found.  Ignoring.
(3)  Running Post-Auth-Type Challenge from file /etc/raddb/sites-enabled/vpi
(3)  Sent Access-Challenge Id 159 from 137.222.8.134:16020 to
172.17.107.208:32770 via ens192 length 0
(3)    EAP-Message = 0x010600f71900ebe0344cb4e5d4ac912e10789408d80c66f81fd27cddd89c4c4a4dc3ae440f0cc86f59ca46e8ff75376eb7910a0af3153626fe0cf81027c02f568b1e56e2656a4191c98103f0da0f1ff061a21c81756cc2aec65066916bda86078229a217c291a4cb982853454ddb46b5e54200d5fd06d4

Same length attribute.

It looks to me like the lengths are being set correctly in the
attribute, but the actual amount of data sent is just the length
of the final fragment (00f7 = 247 bytes).

Comparing to debug output from the previous commit would verify
this. But can't see how this exact behaviour would be caused by
this patch, so maybe I'm completely wrong. I've not had much coffee
yet today.

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>