Uniq certificate per openHAB instance

[belovictor]

We need to replace pre-created certificate distributed with openHAB with a uniq certificate which should be generated during the first run on openHAB on a user's machine. Right now all openHABs have the same certificate (if user does nothing to change that) which is very insecure - anybody is able to implement man in the middle attack using publicly available certificate.

[Stratehm]

Should the keystore with the unique certificate be removed from the openHAB package and a new keystore/self-signed certificate be generated at the openHAB startup if no user-defined keystore is provided and if no keystore is already present in runtime\etc ?

If so, where the certificate generator should be located ? In the org.openhb.io.jetty bundle ?

[kaikreuzer]

I tried to look around, but did not find any way to create a self-signed certificate from within Java. Did you find any possibility? If so, we can discuss the best place to put it as a second step :-)

[maggu2810]

Someone could perhaps have a further look at this one: https://www.bouncycastle.org/java.html

"Except where otherwise stated, this software is distributed under a license based on the MIT X Consortium license. To view the license, see here (https://www.bouncycastle.org/license.html). The OpenPGP library also includes a modified BZIP2 library which is licensed under the Apache Software License, Version 1.1 (http://www.apache.org/licenses/)."

http://blog.thilinamb.com/2010/01/how-to-generate-self-signed.html

[Stratehm]

I have already developped this feature for one of my project and it could be reused with minor modifications. It indeed uses BouncyCastle.

The code is available here (at line 395): https://github.com/Stratehm/stratum-proxy/blob/master/src/main/java/strat/mining/stratum/proxy/Launcher.java

[maggu2810]

Wuha, great number of imports ;-)

[kaikreuzer]

Do you have any idea about the size of dependencies this draws in? Bouncycastle alone seems to have 3MB already. I would like to avoid that for such a small feature, the minimal runtime grows significantly.

[Stratehm]

It needs 2 dependencies: org.bouncycastle.bcprov-jdk15on (the JAR is 2.8 MB) and org.bouncycastle.bcpkix-jdk15on (the JAR is 608 KB).

[kaikreuzer]

Which confirms that it is rather huge... So I would opt to put it into a bundle on its own and we can let people decide whether they want it or not. The problem is that the code only needs to be executed a single time - afterwards, it is just ballast :-| Maybe we could also automatically uninstall it once we have Karaf in place...

[Stratehm]

If this bundle is not included with the minimal runtime, I think not many people will use it (since they may not understant the ins and the outs of this bundle).
Thus the bundle may not be needed. Maybe a simple documentation is enough to explain how to replace the openhab.org certificate with a new one in the packaged keystore by using command line tools.

[kaikreuzer]

If this bundle is not included with the minimal runtime

Well, I would say that it can be in the "standard" runtime, but it should be possible for users to strip it down, so that this bundle is not part of it anymore. And for that, we would need it in a separate bundle and not within io.jetty (which always has to be present).

[Stratehm]

When I extract only the needed classes of BouncyCastle to generate the certificate (since we just need a little part of BouncyCastle features), the resulting package is only 504 KB. We could re-package these classes directly in the new bundle (I think the MIT license allows it if we provide a copy of the license with the bundle).

[kaikreuzer]

Sounds good!

[maggu2810]

@kaikreuzer Is the problem the size of used RAM at runtime or the size of
the bundle in the file system?
If just the RAM is the problem, I would prefer using some logic, that
install the bundle, generates the feature and uninstalls it - and doing
that only once.
I do not prefer of greating a new unofficial bundle that contains a subset
of packages / classes of another pacckage. Who does fix bugs in cert
generation, ...
On Sep 25, 2015 3:07 PM, "Kai Kreuzer" notifications@github.com wrote:

Sounds good!

—
Reply to this email directly or view it on GitHub
#2 (comment).

[kaikreuzer]

Is the problem the size of used RAM at runtime or the size of
the bundle in the file system?

I would say both.

I do not prefer of greating a new unofficial bundle that contains a subset
of packages / classes of another pacckage

That's a valid point. But I think this repackaging can also be easily automated (like with http://sonatype.github.io/jarjar-maven-plugin/), so that it should not be too hard to update to a newer version of the external lib. This would mean though, that @Stratehm indeed should not include the sources directly, but rather a stripped down jar.

[Stratehm]

I do not prefer of greating a new unofficial bundle that contains a subset of packages / classes of another pacckage. Who does fix bugs in cert generation, ...

Agree, it is a real problem.

I think this repackaging can also be easily automated (like with http://sonatype.github.io/jarjar-maven-plugin/),

The maven plugin you mention seems to repackage by selecting packages/classes from jars based on static rules.
To obtain a 504 KB package, we have to select only classes that are really needed. Since I do not know any tools which do it, I had to write a small program which extract all the transitives imports from a base class (in this case, the certificate generator class). Since the BouncyCastle classes involved in the certificate generation may change in future BouncyCastle releases, we have to build dynamically the list of needed classes to repackage and not rely on a pre-build classes list.
=> The build of a new stripped down jar from a newer version of BouncyCastle may not be easy to automate.

=> Is this complexity justified to save 2.5 MB ?

[kaikreuzer]

=> Is this complexity justified to save 2.5 MB ?

If package level filtering isn't sufficient, then probably no. Is there any gain possible purely through package filtering or doesn't this have any significant effect?

[maggu2810]

If we greate a bundle that generates a unique certificate, we can use the upstream bundle as dependency. The normal runtime does not contain that bundle. If someone decide to use / need it, that one has to live 2.5 MB. But as it is still a one time procedure, we could perhaps find another solution at all. Will also think about it.

[Stratehm]

Is there any gain possible purely through package filtering or doesn't this have any significant effect?

Unfortunately no effect, since you then embed unneeded classes that requires some other packages, which then in turn requires other packages and so on. So finally, you just have embedded all the BouncyCastle classes and rebuilt the original package... :$

we can use the upstream bundle as dependency

Which upstream bundle ?

But as it is still a one time procedure, we could perhaps find another solution at all.

Right. At the same time, as @kaikreuzer stated, we should try to find a way to automate the BouncyCastle extraction process with maven since it may solve the problem.

EDIT: Just remember about the maven-shade-plugin. It packages all the maven dependencies into the built jar and it seems it is able to remove all the classes that are not used in the project. I will look further.

[Stratehm]

The jar built with the maven-shade-plugin is functionnal and is about 350 KB. Great.

Unfortunately, I will not be able to create the new bundle since I do not know OSGi bundle development well enough (particularly the interaction between Maven and OSGi build which is a bit magical to me :).
But I can provide the certificate generation source code and the Maven configuration to build a standalone JAR. Maybe you could create the bundle from all of that.

[kaikreuzer]

You could add the configuration to the pom.xml of your bundle and have the jar created in the /lib folder of your bundle; then this does not have anything to do with the OSGi stuff of the build, but it will make sure that the Maven build automatically creates a recent version of the jar.

[Stratehm]

Ok, I will try that. Thanks.

[Stratehm]

It is almost done. The certificate generation works if no keystore is already present and the bundle has a size of 357 KB.
I still have a problem: At the first launch, when no keystore is present, jetty tries to load the keystore and fails since the certificate generation bundle is started after Jetty. How could I do to be sure the certificate generation bundle start before Jetty ?

[kaikreuzer]

That should hopefully work if you add it here https://github.com/openhab/openhab2/blob/master/products/org.openhab.product.runtime/org.openhab.runtime.product.product#L38 with startlevel 2 or 3.

[maggu2810]

The property exist in the karaf branch only, but we should use
"${openhab.userdata}" for the manual created keystore, shouldn't we?
Writing to runtime[/etc] should not be done at runtime

2015-09-29 11:44 GMT+02:00 Kai Kreuzer notifications@github.com:

That should hopefully work if you add it here
https://github.com/openhab/openhab2/blob/master/products/org.openhab.product.runtime/org.openhab.runtime.product.product#L38
with startlevel 2 or 3.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[maggu2810]

I do not know how much bits you are using for the private key, but the
generation of a "strong" private key could be take some time.
If I use Karaf with ssh feature and does not provide a pre-generated SSH,
the a key is generated on the first login.
If I try to login first, I get a timeout (120 s). The machine consists of
an A20 CPU (dual ARM Cortex-A7 cores; 2x 1GHz) with 2 GB RAM.
Perhaps @kaikreuzer this could be interesting for you as you target RPi,
too.

2015-09-29 13:22 GMT+02:00 Markus Rathgeb maggu2810@gmail.com:

The property exist in the karaf branch only, but we should use
"${openhab.userdata}" for the manual created keystore, shouldn't we?
Writing to runtime[/etc] should not be done at runtime

2015-09-29 11:44 GMT+02:00 Kai Kreuzer notifications@github.com:

That should hopefully work if you add it here
https://github.com/openhab/openhab2/blob/master/products/org.openhab.product.runtime/org.openhab.runtime.product.product#L38
with startlevel 2 or 3.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[kaikreuzer]

120s? Are you serious...? This would indeed be a no-go for the initial startup.

Could we ship with the existing certificate, so that Jetty starts up correctly and then simply replace it silently in the background (or triggering it as a manual installation step)?

[maggu2810]

Do not know which implementation this ssh daemon for Java is using, but
yes, I am get this timeout.
At get it also with my Udoo (CPU: "Freescale i.MX6Quad, 4 x ARM® Cortex™-A9
core @ 1GHz with ARMv7A instruction set").

Could we ship with the existing certificate, so that Jetty starts up
correctly and then simply replace it silently in the background (or
triggering it as a manual installation step)?

This will result in two keystores, one in runtime, one in userdata.
The openhab jetty bundle have to check if there is one in userdata and
change the jetty property which keystore should be used...