[pkg-wpa-devel] Bug#579297: Re: Bug#579297: wpasupplicant: Recompiling with gnutls fixes (or workarounds) the problem

[Réczey Bálint]

2012/11/13 Balint Reczey <rbalint at gmail.com>:
...
>>> In an eduroam environment (which is basically WPA-Enterprise), I can
>>> confirm disconnects without the possibility to reconnect when using
>>> wpa_supplicant wit network-manager. Killing and restarting
>>> wpa_supplicant allows a temporary reconnect.
Please try to collect the capture file using wireshark about the issue
happening and
post the releavant part. It seems there are multiple issues merged together.

>>
>> This is
>>         http://w1.fi/bugz/show_bug.cgi?id=447
>> respectively
>>         http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668612
>>         http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561081
>>         http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574714
>>         http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579297
>>         http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667706
>>
>>> When researching the problem, I found this posting:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/429370/comments/19
>>>
>>> It states that the problem may be actually an openssl bug which lets the
>>> rekeying
>>> process fail permamently, and recommended recompiling with gnutls instead
>>> of
>>> openssl. I did this:
>>
>> […]
>>
>> The problem with this suggestion and the according patch, is that it
>> switches from one (known) set of bugs to another (unknown) one. While
>> linking to gnutls is supported upstream, none of the major
>> distributions (not even Ubuntu) actually does so, which makes it pretty
>> much untested in practice. Even if we wanted to switch to gnutls, doing
>> so simply isn't possible at this stage of Debian's release process and
>> in freeze*.
>>
>> *)      However technically speaking, we can't switch to gnutls anytime
>>         soon, because gnutls doesn't provide an udeb, which is needed for
>>         using wpa_supplicant by the Debian installer (d-i). While your
>>         package build against gnutls succeeded, you have most likely ended
>>         with an unsatisfiable (in the d-i/ udeb context) dependency on
>>         libgnutls26-udeb for wpasupplicant-udeb_*.udeb (dpkg-gensymbols
>>         employs very crude heuristics to construct the dependencies for
>>         udeb packages without actually having access to a udeb context).
>>
>> […]
>>>
>>> and have been testing the modified package for about a month now, the
>>> frequent disconnects have completely disappeared.
>>>
>>> The right place for a real fix would probably be openssl, but the
>>> problem does not seem to be addressed or sufficiently researched there,
>>> so the workaround by using gnutls instead of openssl gnutls seems to be
>>> the best option for now.
>>
>> […]
>>
>> At this moment it is not obvious to me if wpa_supplicant is broken, or
>> if some popular commercial wlan installations used for eduroam
>> institutions are to blame. While, given the ubiquity and prevalence of
>> this issue in academic environments, it might be possible that
>> wpa_supplicant may need to work around the problem, however this would
>> best be fixed at wpa_supplicant's upstream. Unfortunately none of the
>> current wpa maintainers for Debian has access to an affected wlan setup
>> in order to try to reproduce the problem, nor has enough information to
>> recreate an affected EAP/ PAP setup for debugging, which significantly
>> reduces our abilities to help. Therefore it's probably best to engage
>> with wpa_supplicant upstream to get this fixed once and for all.
>>
>> Regards
>>         Stefan Lippers-Hollmann
>
> Hi,
>
> Please see the attached patch fixing the problem while not breaking other
> use cases.
>
> The fix turns off listing the SessionTicket TLS extension in every second
> hello packet allowing broken servers to accept the connection.
>
> Log:
> 1 0.000000000 Apple_ee:ee:ee -> Procurve_aa:aa:aa EAP 30 Response, Identity
> 3 0.060381000 Procurve_aa:aa:aa -> Apple_ee:ee:ee EAP 60 Request, Protected
> EAP (EAP-PEAP)
> 4 0.060918000 Apple_ee:ee:ee -> Procurve_aa:aa:aa SSL 249 Client Hello
> 5 0.111778000 Procurve_aa:aa:aa -> Apple_ee:ee:ee TLSv1 60 Alert (Level:
> Fatal, Description: Bad Certificate)
> 6 0.112140000 Apple_ee:ee:ee -> Procurve_aa:aa:aa EAP 24 Response, Protected
> EAP (EAP-PEAP)
> 7 0.163244000 Procurve_aa:aa:aa -> Apple_ee:ee:ee EAP 60 Failure
> 8 0.745350000 Procurve_aa:aa:ab -> Apple_ee:ee:ee EAP 60 Request, Identity
> 9 0.745615000 Apple_ee:ee:ee -> Procurve_aa:aa:ab EAP 30 Response, Identity
> 10 0.809622000 Procurve_aa:aa:ab -> Apple_ee:ee:ee EAP 60 Request, Protected
> EAP (EAP-PEAP)
> 11 0.810101000 Apple_ee:ee:ee -> Procurve_aa:aa:ab SSL 245 Client Hello
> 12 0.901729000 Procurve_aa:aa:ab -> Apple_ee:ee:ee EAP 918 Request,
> Protected EAP (EAP-PEAP)
> 13 0.901942000 Apple_ee:ee:ee -> Procurve_aa:aa:ab EAP 24 Response,
> Protected EAP (EAP-PEAP)
>
>
> As you can see the first hello is longer due to the extension and has been
> rejected by the buggy server.
> The second connection attempt has not listed the extension and has been
> accepted by the buggy server - which happens to run on a different host.
>
> Please forward the patch upstream as well, I did not want to register to
> their bugzilla for this single patch.
>
> IMO this fix is needed in Wheezy, but I did not want to push the priority
> higher on my own.
Klaus pointed out correctly in a private email that the fix covers only PEAP.
It definitely fixed the issue for me, but please see the fix covering
all methods using TLS attached.

Cheers,
Balint
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tls-fallback-session-ticket-disable.patch
Type: application/octet-stream
Size: 9897 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/attachments/20121114/01e7e7f7/attachment.obj>