Browse cannot connect to sites with non-standard Certificate Authorities

[cscott]

Browse's security settings are set to 'maximum paranoid' -- which means, however, that there is no way to connect to several gated networks, which require you to register your machine via an SSL page before they will let you connect. MIT's network is administered this way, for example: you need to connect to https://nic.mit.edu:444 to register, but all of MIT's sites have certificates signed by MIT's own Certificate Authority, so Web won't let you connect, and thus won't let you register.

I've seen this on other gated networks as well.

[erikos]

Scott please mark it first Update.1? to get it triaged right, even so you think this should be in Update.1.

[AlbertCahalan]

From the UI and security points of view, such sites need to be treated exactly like non-SSL sites. (no security icon, no warning, etc.)

On the network of course, you do SSL to make the web server happy.

[marco]

I think this is due to #5487.

[cscott]

I'm reopening, because this should be verified independently of 5487. This is what the 'blocked by' field is for.

[marco]

#5487 doesn't actually fix this. Looks like security UI is changed. I'll have to look into it.

[sj]

See also #542.

[kimquirk]

Moving this to higher priority and asking for triage/discussion. Seems pretty important to me.

[jg]

The question in my mind is there a configuration option we can set to be less paranoid... It's probably too late to be hacking code...

[jg]

Chris, Scott; do you have ideas?

[marco]

Relevant mozilla "bug": https://bugzilla.mozilla.org/show_bug.cgi?id=327181

[marco]

Testing with the latest firefox I get a different UI which doesn't depend on the preference pane. That **might** work for us, but we won't know until we try it out.

[marco]

Nope, that UI is firefox specific and embedder doesn't get it. So we will to implement our own UI here. I don't think this can happen for u.1.

[jg]

Sigh... I agree.

[Russell McOrmond]

I am wondering if there is a temporary workaround? I thought that installing the relevant Root certificate would do the trick. Many of the sites I'm wanting to access are using cacert.org signed certificates. Unfortunately going to the relevant "Root Certificate" page at http://www.cacert.org/index.php?id=3 doesn't offer me anything. Clicking on the PEM file doesn't seem to do anything -- clicking on the DER file caused a file to be downloaded, but doesn't do anything when I open it.

Hopefully this bug tracking system will send notifications so I will know when to test/etc.

[cnoocy]

Replying to Russell McOrmond:

I am wondering if there is a temporary workaround?

Apparently copying the certs.db file from a computer that has successfully accessed the self-signed site to the XO works around this problem. cscott can confirm.

[chihyu]

The workaround does not work with build 690. I copied cert8.db and key3.db from a Windows machine that had successfully accessed the site (https://nic.mit.edu:444) to the XO (under gecko), but still failed to register.

Replying to cnoocy:

Replying to Russell McOrmond:

I am wondering if there is a temporary workaround?

Apparently copying the certs.db file from a computer that has successfully accessed the self-signed site to the XO works around this problem. cscott can confirm.

[nealmcb]

I ran into this problem at a wifi site that uses a captive portal with ssl and javascript and an expired certificate.

I wonder if there is a workaround with a different browser. E.g. you can yum install elinks, which has ssl support, though I don't know how it reacts to expired certificates. But it doesn't seem to have javascript, though it seems that that can be configured at build time. So it wouldn't work with captive wifi portals that require javascript.

I don't know the current story on other fedora text-mode browsers with ssl and javascript support. w3m might also be able to do both, but it also doesn't seem to be built with javascript. Or at least this page doesn't seem to work: http://www.javascriptsearch.com/scripts/Utilities/javascript_test.html

[byte]

I notice this error (sec_error_unknown_issuer) even when accessing websites that have a valid security certificate (the site in particular uses RC4 128 bit encryption, with VeriSign? signing the certificate). It is however, the web URI for the Microsoft ISA Server 2006 (which a lot of schools in Australia use).

Loading in Firefox shows the certificate to be valid. Loading on the OLPC, tells me otherwise and there is no "workaround" - i.e. I can't add an exception, seeing that I can't go to the advanced encryption settings

[cscott]

Copying the certs file from an existing machine does work with whatever update.1 build was current as of January 15. I'm not terribly surprised that it doesn't work with the certs file from a Windows machine, since it is a gross and evil hack. Be careful you're overwriting the correct copy of the certs file: Browse has a copy inside the activity which is used to create an appropriate certs file in the profile on first start up. Overwriting the copy in the activity only works if you've never launched Browse on that particular machine before; otherwise you need to hunt down the copy in the activities instance directory.

RC4 128-bit is pretty insecure -- see Wikipedia for one long list of flaws found in RC4 -- I wouldn't be terribly surprised to find that it wasn't on SSL's default accept list anymore. byte, could you supply a URL which uses the certificate in question, to allow us to investigate?

[byte]

Hi cscott, thanks for responding quickly - a URL in question can be https://mail.ggs.vic.edu.au/

Many other Victorian schools use a similar configuration, from what I've noted (sadly, all broken, Microsoft based email systems)

[cscott]

Well, that mail.ggs.vic.edu.au certificate is flagged as problematic in Firefox on my Debian Linux box, so it's not an XO-specific problem.