Support of SSL options

[laurentj]

We should support these parameters:

• --ignore-ssl-errors
• --ssl-protocol=[SSLv3|SSLv2|TLSv1|any](will not be supported)
• --ssl-certificates-path=/path

To support --ssl-certificates-path=/path/to/dir see this code snipet

[laurentj]

to ignore ssl errors, there is no preferences or an API for that. It seems that the only way to do it, is to detect the error page, to add cert exception on the fly and then to load the request page

[laurentj]

See http://darrendev.blogspot.jp/2013/10/slimerjs-getting-it-to-work-with-self.html for a workaround...

[CMCDragonkai]

I wonder if there's a way to make darrendev's method automatic?

[laurentj]

@CMCDragonkai no

[artjomb]

I think that --ssl-protocol must be implemented now that POODLE forced many websites to retire SSLv3. Or at least setup Slimer such that TLS is used by default.

[abozhilov]

Unfortunately there is no way to ignore SSL errors in the current stage of xulrunner. Adding them manually after detected is not good idea. It will work when the SSL error is triggered on the main request, but the SSL error could be caused by image, flash or any other resource on the page. It will be not easy to refresh those resources manually after adding the cert.
I filled a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1106173
We must follow the progress on that issue. Hope they will provide an API or at least compile flag.

[4e976623]

@CMCDragonkai I stumbled upon this issue and I want to note that I do have sample code for automating the launch-Firefox method via shell (and without launching Firefox).

cert="$(openssl s_client -connect "$1" -servername "${1%%:*}" < /dev/null | sed -ne '/BEGIN CERT/,/END CERT/p')"
echo "$cert" | openssl x509 -text | tac >&2
fingerprint="$(echo "$cert" | openssl x509 -sha256 -fingerprint | head -n 1 | sed -re 's/.*=//')"
echo -e "$1\tOID.2.16.840.1.101.3.4.2.1\t$fingerprint\t${2:-U}\tbWFudWFsIG92ZXJyaWRl" 

You need to restart SlimerJS for the new cert_overrides to take effect.

[puravida]

This has been a huge issue for us, because my proprietary screenshot solution (built in 2007) has always been based on the Gecko engine and I found no way to overcome this. So, I feel your pain. Now that I'm testing for possible backup capture methods and leaning toward slimerjs for that, I'm facing the possibility of still not being able to ignore SSL errors. Ugh. I may have to implement a third backup using Chrome or phantomjs, but that is definitely not ideal to maintain all that code and updates, etc.

I wanted to mention that there was a plugin that worked, at one time, to automatically detect SSL errors and add a temporary exception. It is here: https://addons.mozilla.org/en-US/firefox/addon/skip-cert-error/

It no longer works, for me at least, and has been discontinued due to e10s requirements that it won't pass. Just thought I'd mention it, in case looking at it might spark some ideas. However, I realize this probably won't be solved unless Gecko gives some means to do so.

[CMCDragonkai]

@4e976623 What are you trying to do?

@puravida So basically we just need to rewrite the extension, even the original creator said he'll help.

[4e976623]

@CMCDragonkai You asked how to automate the SSL exception line generation and I shared my shell code snippet.

Globally I am trying to extend SlimerJS in a minimal way to get a usable Gecko-based minimal-UI browser. I do have to patch SlimerJS omni.ja, though. I can actually use SlimerJS for 95% of my browsing while using Firefox for the remaining cases.

[puravida]

@4e976623 Thank you for sharing your code. I did see it, but it is a problem to have to restart the process to enable the SSL bypass. It introduces significant delay for the capture. That might not matter in a browser automation testing or personal browsing scenario, but for a service; speed is crucial.

When the "Skip Cert Error" plugin was working, it did not require a restart to bypass. So, there is hope but the original creator made it sound like e10s had killed this ability. Since e10s doesn't affect my usage (that I know of, yet), I have not researched it. I have no idea what it is or what limitations it imposes.

@CMCDragonkai Did you chat with the original creator or did he offer assistance, generally, somewhere? It would be great if he could elaborate on why he cannot make the plugin work any longer, so that we can determine any hope for using his method (which is a rewrite of another plugin). If you aren't already in touch with him, I could reach out to him and invite him to this thread.

[laurentj]

e10s is deactivated in SlimerJS.

[4e976623]

I agree that needing a restart is a drawback.

Maybe SlimerJS could expose rereading the SSL exception list?

When I ask for exposing internal APIs with interactive-use motivation,
it gets rejected as out of scope, but here there is a reasonable use for
that API in a full-automation situation.

[puravida]

I've gotten to concurrency and performance testing with slimerjs and found that running multiple, concurrent capture threads in a persistent slimerjs instance is not really going to work for my use case. So, I will end up running a separate slimerjs instance for each capture. The overhead seems nominal. So, in my case, it will be restarting every time anyway. I suppose that as long as I can catch these SSL errors, I could just retry the capture right away (assuming the exception list is updated and reloaded on retry).

[mirzazeyrek]

I guess there isn't any progress about --ignore-ssl-errors. @laurentj

[randuck-dev]

Is there any progress on --ssl-certificates=/path ? I can't seem to find any on the issues or the pull request. @laurentj