Comments (33)
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 runtime2015-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.
Related Issues (20)
- [solarforecast] persisted Solcast Energy data changed after 2 days (in the past)
- [nest] Add support for WebRTC streaming HOT 1
- [hue] Discussion: is there any need/benefit in implementing new v2 API resource types? HOT 3
- [bosesoundtouch] Metadata fields are not parsed correctly
- [kostalinverter] Exception HOT 1
- [jellyfin] - API deserialization problems after update to latest Jellyfin Server Version 10.9 HOT 8
- [hue] Managing automations HOT 3
- [wled] Brightness not synced across channel and power not turned on HOT 2
- [enphase] Monitor battery HOT 1
- [bluetooth] Provide serviceData as part of Bluetooth discovery data HOT 3
- [gree] Bind operation does not work with Gree Clivia
- [mybmw] enable start and stop charging for EVs
- [boschshc] Bosch devices do not get battery level updates HOT 1
- [mercedesme] Socket error if command state is *unrecognized*
- [openhabcloud] Support new notification features HOT 53
- Update to Groovy 4.0.21 HOT 2
- [aWATTar] Update prices more than once a day HOT 1
- [homematic] Invalid configuration possible that disables updates from CCU3 HOT 1
- [smartthings] Links to SmartThings developer documentation are broken HOT 1
- [gree] Unable to connect to AC
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openhab-addons.