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 ?

from openhab-addons.

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 :-)

from openhab-addons.

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

from openhab-addons.

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

from openhab-addons.

Wuha, great number of imports ;-)

from openhab-addons.

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.

from openhab-addons.

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

from openhab-addons.

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...

from openhab-addons.

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.

from openhab-addons.

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).

from openhab-addons.

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).

from openhab-addons.

Sounds good!

from openhab-addons.

@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" [email protected] wrote:

Sounds good!

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

from openhab-addons.

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.

from openhab-addons.

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 ?

from openhab-addons.

=> 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?

from openhab-addons.

from openhab-addons.

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.

from openhab-addons.

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.

from openhab-addons.

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.

from openhab-addons.

Ok, I will try that. Thanks.

from openhab-addons.

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 ?

from openhab-addons.

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.

from openhab-addons.

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 [email protected]:

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).

from openhab-addons.

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 [email protected]:

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 [email protected]:

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).

from openhab-addons.

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)?

from openhab-addons.

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...

from openhab-addons.

The long waiting time might be because the ssh daemon waits for enough entropy to be collected so a key can be generated. This is an issue especially with virtual machines or servers which lack physical input.

from openhab-addons.

Yes, but this entropy is missing for the private key of the certificate,
too. :)

2015-09-29 15:01 GMT+02:00 Hakan Tandogan [email protected]:

The long waiting time might be because the ssh daemon waits for enough
entropy to be collected so a key can be generated. This is an issue
especially with virtual machines or servers which lack physical input.

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

from openhab-addons.

On my Windows virtual machine running on a Core-i5, it takes less than a second to generate the whole certificate (and so the 2048 bits length RSA keys). The BouncyCastle key generator uses the SecureRandom class to generate the random prime numbers. In the certificate generator, I force the use of the sha1prng generator (which is the default one and available with all JVM). This one collects entropy on startup and uses it during all the life of the JVM process (not a problem in our case since we use the genertor a small amount of times), so it is pretty fast.

On some other systems and key generation implementations, a NativePRNG may be used if available. These PRNG generators can be far slower, which may explain why your SSH daemon takes so musch time to generate the keys.

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.

I will try. Thanks

from openhab-addons.

from openhab-addons.

Perhaps the requirements for the entropy are higher of that ssh implementation.
I tested the generation using the keytool:

time keytool -genkeypair -v -keysize 2048 -keystore /tmp/tmp.keystore
-storepass foofoo -keypass foofoo -dname ""
Generating 2,048 bit DSA key pair and self-signed certificate
(SHA1withDSA) with a validity of 90 days
for:
[Storing /tmp/tmp.keystore]

real 0m1.064s
user 0m1.135s

sys 0m0.105s

This looks good.

And entropy... I think if we need "real" certificates for security, we
would not use self signed and generated at runtime ones.

from openhab-addons.

Implemented with #402

from openhab-addons.