On Thu, Nov 22, 2007 at 01:57:01PM +0100, Alan DeKok wrote:
I've just committed some more fixes that make TTLS/PEAP call the tls_hanshake_recv() function, which takes care of fragments and ACKs. That appears to work a little better.
It looks like I can now receive the first fragment of the long phase 2 message from the server. This is sent in two phase 1 fragments and the combined data can be decrypted correctly. However, after this, the server does not seem to be sending out the following data from phase 2. The phase 2 message (the one with EAP-TLS ServerHello, Certificate, ServerKeyExchange, and CertificateRequest) is 3808 bytes and it looks like only the first 1020 bytes (fragment_size - 4 octets for TLS Message Length field) is transmitted. Is the phase 2 data actually truncated somewhere?
I've made some more hacks (uncommitted) to work around certain assumptions in the internal implementation of the server. I now see the connection established, and then the inner EAP-TLS session says:
rlm_eap_tls: >>> TLS 1.0 Handshake [length 00a8], CertificateRequest TLS_accept: SSLv3 write certificate request A TLS_accept: SSLv3 flush data TLS_accept: Need to read more data: SSLv3 read client certificate A
This should show up even before the server has sent out the first large message from phase 2 (I see the same in the debug log).
wpa_supplicant sends the certificate in 3 fragments, including change cipher specs, and FreeRADIUS receives the fragments. However, FreeRADIUS doesn't process the data, and instead asks for more.
However, this would require the larger server message to go through which is something I do not see. Could you please send me the hacks needed to get here? -- Jouni Malinen PGP id EFC895FA