Support HTTPS

[SpiritQuaddicted]

Weird that we did not have an issue for this yet.

The Injector does not support HTTPS, it only works with HTTP. Since Quaddicted tries to force all traffic onto HTTPS the Injector is broken.

One problem is that Quaddicted uses a Startcom certificate which is not supported by Oracle by default. A workaround could be shipping the public key or hard-code something so it gets accepted like a self-signed one (pinning?). The certificate is only valid for a year so we would need a mechanism to prompt users to update or better yet, expose the certificate stuff via the configuration somehow. If this is too much work compared to simply adding general HTTPS support, I could buy a supported certificate instead.

[neogeographica]

The StartCom situation is a bummer.

If you create a truststore file containing only the StartSSL certificates, and ship it with QuakeInjector, you can apparently use it via

System.setProperty("javax.net.ssl.trustStore","<path_to_truststore>");
System.setProperty("javax.net.ssl.trustStorePassword","<truststore_password>");

Note that this truststore is for the StartCom CA cert(s), not your own cert, so you shouldn't have to renew it very often. I'm not sure how often those change.

StartCom says that the two files you need to have in the truststore are their ca.crt and sub.class1.server.ca.crt. Looking at http://www.startssl.com/certs/ I see that those files last changed in 2007 and 2010 respectively. (I've seen other snippets that say you also want/need sub.class2.server.ca.crt, sub.class3.server.ca.crt, and sub.class4.server.ca.crt ... also from 2010).

So anyway, they don't change often, but they probably don't stick around forever either. You'd have to keep an eye on things and issue a new version of the Injector if the certificates change.

Or you could try to be clever-er and have the injector automatically download an update. You would kind of have a chicken-and-egg problem getting the update from Quaddicted. Alternately you could download the certs directly from StartCom and build a new truststore, although that's starting to feel a bit too jerry-rigged.

As a side node, if you were to use some Apache commons http/ssl classes, you could (apparently) import the CA certs directly without building a truststore, e.g. https://forum.startcom.org/viewtopic.php?f=15&t=1815

Anyway, food for thought. I may have time to fiddle around with making a StartSSL-dedicate truststore and seeing if the Injector is happy using it. Examples of modifying the global truststore abound (https://forum.startcom.org/viewtopic.php?f=15&t=1678 , https://github.com/haron/startssl-java , http://www.ailis.de/~k/uploads/scripts/import-startssl) ... I don't think I want to do that, but creating a new truststore file should be similar.

[neogeographica]

One potential gotcha with using a StartSSL-specific truststore, cf. this answer at the bottom of this StackOverflow page: http://stackoverflow.com/questions/3674849/how-support-multiple-truststores-in-java-ssl-client-application

It looks like if you specify the javax.net.ssl.trustStore property you will completely replace, rather than add to, the global truststore (for the activities of your application). If StartSSL CA certs themselves depend on a trust chain that requires other certs from the global truststore, then that's bad. There's some other possible solutions that could be chased from that page, but if this is the case then maybe the Apache commons classes would be a better solution.

[SpiritQuaddicted]

Thanks for looking into this!

Can one make a Java application simply accept self-signed certificates? I would consider that a decent solution. The adversary is dragnet surveillance or someone lazily sniffing traffic. Protecting against MITM is not necessary in my opinion. I mean, right now it is running unencrypted, so anything is an improvement. Nothing in Quaddicted user accounts is too sensitive either. If someone goes to all the trouble to MITM a QI user, well, kudos to them.

Startcom is a normal CA, so it does not depend on an additional trust chain. At least from what I know.

For updating I would be an ass and only supply a fake database to everyone who does not update (connecting via http), with a single map description telling the user to update. We totally should have planned an update mechanism from the beginning. =)

[neogeographica]

As far as the self-signed certificate goes, it seems doable without too much hoop-jumping. I'm really just regurgitating Google at this point but the things I'm seeing all seem pretty similar: http://stackoverflow.com/questions/2893819/telling-java-to-accept-self-signed-ssl-certificate , http://www.howardism.org/Technical/Java/SelfSignedCerts.html , http://danielkvist.net/code/accept-any-certificate-in-java-and-https-ssl-connection-and-get-your-json-on , http://samindaw.wordpress.com/2010/01/18/accept-or-ignore-self-signed-certificates-while-reading-ssl-web-page-using-java/

[ericwa]

I might poke around with the previous link you posted, neogeographica (http://stackoverflow.com/questions/3674849/how-support-multiple-truststores-in-java-ssl-client-application), and see if it's straightforward to get the CA we provide (startcom) trusted along with all of the default ones

[ericwa]

Well, I got something to work, but it sure is ugly! See HTTPS pull request.

[SpiritQuaddicted]

Fixed since #93