The https connections to the mentioned sites just hang, because OpenSSL sends too-big ClientHello packets that are filtered out. Reproducible: Always Steps to Reproduce: In a python interpreter, type these lines: >>> from urllib2 import urlopen >>> urlopen('https://graph.facebook.com/give_me_a_404').read() Actual Results: After a long timeout, the following message is printed: urllib2.URLError: <urlopen error [Errno 104] Connection reset by peer> Expected Results: In less than two seconds, the following exception should be raised: urllib2.HTTPError: HTTP Error 404: Not Found This was the case with openssl-1.0.0 This regression against openssl-1.0.0 breaks web scripts that use django-social-auth, because they no longer can get a token from facebook. IMHO it is critical enough to warrant package.masking >=dev-libs/openssl-1.0.1 Upstream bugtracker: http://rt.openssl.org/Ticket/Display.html?id=2771 (use guset:guest as login/password)
It also seems to breaks 802.1X in wpa_supplicant. (Only tried with PEAP + MSCHAPv2). For me it always results in EAP authentication failure. Downgrading to openssl-1.0.0i fixed the issue.
paypal and facebook look like they're fixed. @Jan is that a microsoft radius server your client is talking to? With your 1.0.0i openssl, try openssl s_client -tls1 -servername "verylonghostnameaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" -msg -connect server:port Check that the hello message length is >255 bytes (at least 0x100) If that replicates the problem (or try a longer servername if it works), then it's your radius server's ssl implementation that's the problem.
Can we close this? It is not a bug in Gentoo, it's a bug in other people's ssl implementations and most of them seem to be fixed by now.
closing, as this is not a gentoo bug
*** Bug 462348 has been marked as a duplicate of this bug. ***
