Bug#427057: iceweasel picks up wrong libssl3.so
In a message of Sun, 03 Jun 2007 20:19:45 EDT, Eric Dorland writes:
So the LD_LIBRARY_PATH is set to /usr/lib/iceweasel in the iceweasel
shell script (which invokes the actual binary,
/usr/lib/iceweasel/firefox-bin). How are you invoking it?
Using the /usr/bin/iceweasel script... So at least theoretically,
running it as env LD_LIBRARY_PATH=/usr/lib/iceweasel iceweasel
vs just iceweasel shouldn't make any difference (I've read the
script now). But it certainly did when I was chasing the SSL problem
friday (or am I going insane?).
I doubt you're crazy but maybe you made a mistake. Try it again on the
machine you were having problems with and see.
Ok, I have some more data now (which also explains why I thought
setting LD_LIBRARY_PATH helped). I haven't managed to recreate
exactly the same situation I had on friday, but it looks similar
enough that I think it's still the same problem.
It seems that it is caused by interaction between the SSL server and
iceweasel. If the SSL server asks for a client certificate, but does
not specify any acceptable certificate authorities, connecting to the
SSL server will always work flawlessly the first time. Sometimes
the second and further attempts to connect will fail with a connection
interrupted error message:
The connection was interrupted
The connection to localhost: was interrupted while the page was loading.
* The site could be temporarily unavailable or too busy. Try again in a few
moments.
* If you are unable to load any pages, check your computer's network
connection.
* If your computer or network is protected by a firewall or proxy, make sure
that Iceweasel is permitted to access the Web.
Sometimes, if the SSL server uses TLSv1 only, it will instead say that
the Iceweasel can't connect securely to localhost because the site uses
a security protocol which isn't enabled.
Unfortunately, I can't trigger it consistently, but it seems more common
if the server uses SSLv3 only or TLSv1 only. Using SSLv23 (i.e. 2 and 3
autonegotiation) breaks less often, but it happens there too.
Oh, and it's not the server, because openssl s_client connects just fine.
I'm including a small python program to test it. Uncommenting the
load_client_ca() line seems to make it consistently not break. If it's
not there, it will occasionally break. Switching methods seems to trigger
it quicker, so changing which SSL.*_METHOD is uncommented and then
reloading the page is more likely to trigger.
You'll need python-twisted-web2 and python-pyopenssl installed.
Generate the required certificates like:
$ openssl genrsa -out CA.key 1024
$ openssl req -new -key CA.key -x509 -out cacert
$ openssl genrsa -out foo.pkey 1024
$ openssl req -new -key foo.pkey -out foo.creq
$ openssl x509 -req -in foo.creq -CA cacert -CAkey CA.key -CAcreateserial -out
foo.cert
/Anders
from twisted.python import log
from twisted.internet import reactor, ssl
from twisted.web2 import server, resource, channel, http
import sys
from OpenSSL import SSL, crypto
class Root(resource.Resource):
addSlash = True
def render(self, req):
return http.Response(code=200, stream='foo')
class SSLContextFactory(ssl.ContextFactory):
def __init__(self, pkey, cert, cacert, method):
_pkey = crypto.load_privatekey(crypto.FILETYPE_PEM, open(pkey).read())
_cert = crypto.load_certificate(crypto.FILETYPE_PEM, open(cert).read())
_cacert = crypto.load_certificate(crypto.FILETYPE_PEM, open(cacert).read())
self._ctx = ctx = SSL.Context(method)
#ctx.load_client_ca(cacert)
ctx.set_verify(SSL.VERIFY_PEER, self.verifyClientCallback)
ctx.set_cipher_list('RC4:-EXP:-LOW:-ADH:@STRENGTH')
ctx.use_certificate(_cert)
ctx.use_privatekey(_pkey)
certstore = ctx.get_cert_store()
certstore.add_cert(_cacert)
def verifyClientCallback(self, conn, cert, errnum, depth, ok):
Verifiy the client connection.
Arguments: conn - the SSL connection
cert - the certificate being checked
errnum - error code from SSL (if applicable)
depth - depth in certificate verification chain
ok - 1: everything ok so far,
0: an error (available in errnum)
Returns: The new 'ok' value
return ok
def getContext(self):
return self._ctx
def main():
log.startLogging(sys.stderr)
site = server.Site(Root())
print site
sslctx = SSLContextFactory('foo.pkey', 'foo.cert', 'cacert',
#SSL.SSLv23_METHOD)
#SSL.SSLv3_METHOD)
SSL.TLSv1_METHOD)
print site
reactor.listenSSL(, channel.HTTPFactory(site), sslctx)
reactor.run()
if __name__ == '__main__':
main()
Bug#427057: iceweasel picks up wrong libssl3.so
In a message of Sat, 02 Jun 2007 23:20:00 EDT, Eric Dorland writes: * Anders Hammarquist ([EMAIL PROTECTED]) wrote: Package: iceweasel Version: 2.0.0.3-2 If libnss3 (from sarge) is installed, iceweasel will use libssl3.so from that package rather than the one that it comes with. This results in partial breakage of its SSL support. Most noticably, it will not support TLSv1 connections. I have a hard time believing that, what makes you think so? The fact that setting LD_LIBRARY_PATH to /usr/lib/iceweasel made the problem go away, and that the problem stayed away without setting LD_LIBRARY_PATH after purging libnss3. However, I can't repeat it on another machine by installing libnss3 so something else must be off too. I'll investigate further when I get back to work (and the machine that was broken) and see if I can figure out what actually happend on monday. Close this bug and I'll refile if I figure it out. /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427057: iceweasel picks up wrong libssl3.so
* Anders Hammarquist ([EMAIL PROTECTED]) wrote: In a message of Sat, 02 Jun 2007 23:20:00 EDT, Eric Dorland writes: * Anders Hammarquist ([EMAIL PROTECTED]) wrote: Package: iceweasel Version: 2.0.0.3-2 If libnss3 (from sarge) is installed, iceweasel will use libssl3.so from that package rather than the one that it comes with. This results in partial breakage of its SSL support. Most noticably, it will not support TLSv1 connections. I have a hard time believing that, what makes you think so? The fact that setting LD_LIBRARY_PATH to /usr/lib/iceweasel made the problem go away, and that the problem stayed away without setting LD_LIBRARY_PATH after purging libnss3. However, I can't repeat it on another machine by installing libnss3 so something else must be off too. I'll investigate further when I get back to work (and the machine that was broken) and see if I can figure out what actually happend on monday. Close this bug and I'll refile if I figure it out. So the LD_LIBRARY_PATH is set to /usr/lib/iceweasel in the iceweasel shell script (which invokes the actual binary, /usr/lib/iceweasel/firefox-bin). How are you invoking it? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#427057: iceweasel picks up wrong libssl3.so
In a message of Sun, 03 Jun 2007 15:01:25 EDT, Eric Dorland writes: I have a hard time believing that, what makes you think so? The fact that setting LD_LIBRARY_PATH to /usr/lib/iceweasel made the problem go away, and that the problem stayed away without setting LD_LIBRARY_PATH after purging libnss3. So the LD_LIBRARY_PATH is set to /usr/lib/iceweasel in the iceweasel shell script (which invokes the actual binary, /usr/lib/iceweasel/firefox-bin). How are you invoking it? Using the /usr/bin/iceweasel script... So at least theoretically, running it as env LD_LIBRARY_PATH=/usr/lib/iceweasel iceweasel vs just iceweasel shouldn't make any difference (I've read the script now). But it certainly did when I was chasing the SSL problem friday (or am I going insane?). /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427057: iceweasel picks up wrong libssl3.so
* Anders Hammarquist ([EMAIL PROTECTED]) wrote: In a message of Sun, 03 Jun 2007 15:01:25 EDT, Eric Dorland writes: I have a hard time believing that, what makes you think so? The fact that setting LD_LIBRARY_PATH to /usr/lib/iceweasel made the problem go away, and that the problem stayed away without setting LD_LIBRARY_PATH after purging libnss3. So the LD_LIBRARY_PATH is set to /usr/lib/iceweasel in the iceweasel shell script (which invokes the actual binary, /usr/lib/iceweasel/firefox-bin). How are you invoking it? Using the /usr/bin/iceweasel script... So at least theoretically, running it as env LD_LIBRARY_PATH=/usr/lib/iceweasel iceweasel vs just iceweasel shouldn't make any difference (I've read the script now). But it certainly did when I was chasing the SSL problem friday (or am I going insane?). I doubt you're crazy but maybe you made a mistake. Try it again on the machine you were having problems with and see. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#427057: iceweasel picks up wrong libssl3.so
* Anders Hammarquist ([EMAIL PROTECTED]) wrote: Package: iceweasel Version: 2.0.0.3-2 If libnss3 (from sarge) is installed, iceweasel will use libssl3.so from that package rather than the one that it comes with. This results in partial breakage of its SSL support. Most noticably, it will not support TLSv1 connections. I have a hard time believing that, what makes you think so? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#427057: iceweasel picks up wrong libssl3.so
Package: iceweasel Version: 2.0.0.3-2 If libnss3 (from sarge) is installed, iceweasel will use libssl3.so from that package rather than the one that it comes with. This results in partial breakage of its SSL support. Most noticably, it will not support TLSv1 connections. /Anders -- -- Of course I'm crazy, but that doesn't mean I'm wrong. Anders Hammarquist | [EMAIL PROTECTED] Physics student, Chalmers University of Technology, | Hem: +46 31 88 48 50 G|teborg, Sweden. RADIO: SM6XMM and N2JGL | Mob: +46 707 27 86 87 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
