Configuring SSL with trusted certificates

[Ben Jones]

Hey guys,

I am a bit of a noob when it comes to SSL and certificates etc. I have users and passwords enabled for external connections but I would like to use trusted SSL certificates to really beef up my security, since access to openHAB gives someone complete control over my house (including security system)!

I have read the details at https://code.google.com/p/openhab/wiki/Security and tried to follow the instructions at http://wiki.eclipse.org/Jetty/Howto/Configure_SSL but if I am honest, I get lost after the first paragraph!

Is there a set of easy to follow instructions for creating a trusted certificate, installing so openHAB uses it, and how to install on my Android/iOS devices so they use them.

Also - there is a couple of options in HABDroid to ignore certificate validation and handshake checking - if I setup a proper trusted certificate will these options effectively render them useless since HABDroid will bypass them - or am I completely misunderstanding things!

Any help would be greatly appreciated from those that know a bit more about this stuff!

Cheers,

Ben

[Till Klocke]

The safest way is to use certificate pinning. So not to just trust every certificate issued by a "trusted" CA, but just trust one specific certificate. HABSweetie asks you about certificates which aren't automatically trusted (i.e. all self signed certificates). You can then carefully check the used certificate and always only trust this one. That way someone had to fake your certificate, which is pretty unlikely without access to your private key.

I think HABDroid copied my approach of certificate handling, so you can this client too, but don't disable any certificate checks.

I currently don't use the Jetty SSL connector but route all external traffic through a reverse proxy, I realized with nginx. This gives you even a little bit more control since you can specify the SSL ciphers and hash mechanisms to use so you can disable weak ciphers and hashes. This in combination with a self signed certificate should give you currently a pretty high level of security. 

Btw. your question gave me the idea to implement certificate pinning in HABSweetie so you prevent HABSweetie from trusting "trusted" CAs, thanks for that idea.

[Pauli Anttila]

Ben, do you want to prevent unauthorized users to connect your openhab or prevent you to connect fake openhab?

If you don't trust passwords, client authentication with TLS certificates might be the only real option to avoid unauthorized users, meaning that client (HABDroid) provide certificate which is signed with OH trusted certificate.

-Pali

2013/12/11 Till Klocke <till....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Jones]

 I just want to prevent unauthorised users from gaining access. I have a pretty strong passwords set for my users but I would like to be extra vigilant if possible, since gaining access to openHAB would open up my house completely to anyone wanting to get inside!

So from what you are saying Pali - HABDroid would have to be updated to handle this type of TLS certificate handling? And probably core openHAB as well to allow the option to only accept TLS authenticated connections?

I have this setup for my MQTT broker (overkill I know but it was an exercise in how this stuff works). I got a great deal of help from a guy who specialises in TLS/MQTT so I am still a little unsure how it all fits together!

[Ben Jones]

Hey Till,

Have you got instructions/examples of how to setup a connection using a reverse proxy?

BTW - I am just using the certificate that ships with openHAB. Should I really be generating a new, unique, one?

Cheers,

Ben

[Pauli Anttila]

Hi Ben,

HABDroid would have to be updated to handle this type of TLS certificate handling? And probably core openHAB as well to allow the option to only accept TLS authenticated connections?

Jetty seems to support client authentication.

• needClientAuth–Default is false
• wantClientAuth–Defaults is false.

But most probably HABDroid does not nor any other native OH client app I guess. But modern web browsers support client authentication, so one possibility could be to use phone browser when access OH remotely.

Br,
Pali

2013/12/11 Ben Jones <ben.j...@gmail.com>

[Ben Jones]

Seems to me like this is something worth beefing up. Are you guys not a little worried about someone gaining unauthorised access to your system? Or do you feel the user/password authentication is enough?

I might do some more digging to see what is involved. I would sleep a lot better knowing only clients with a TLS certificate I issued could access openHAB!

[Ben Jones]

I have just been suggested stunnel as an alternative to using Jetty for SSL authentication.

Has anyone used this before? Any idea if this would work with openHAB and the iOS/Android clients?

I am off to bed now but will look to have a play with this tomorrow. 

[Till Klocke]

Hi Ben,

you should never use the certificate shipped with openHAB. It is nice for testing, but can't be trusted. I would use a self signed certificate or setup my own CA and sign the certificate there.
Stunnel is similiar to using nginx as an encrypting reverse proxy. Imho using stunnel or nginx to handle encryption is the better approach. You can implement things like certificate authentication (client needs to support this, too) or you can authenticate yourself against other sources via ldap. I think with nginx it should even be possible to check headers of a request etc.
I use nginx to let openHAB support SPDY and let it encrypt my connection. Also I use to exclude weak ciphers. There are plenty of tutorials on how to use nginx as an encrypting reverse proxy. The configuration also depends on what you want achieve in the end (what security measures you want to implement).

[Ben Jones]

Ok - so I need to generate my own certificate. I think I understand it correctly when I say this will stop someone 'spoofing' my home server - meaning I would be certain I am actually connecting to my openHAB instance once I accept the new (personal) certificate on my clients/browers?

But what is to stop someone breaking in using a brute force password attack (I do have user/passwords configured)? This is where the certificate authentication in the client comes in - correct?

I am sorry for the stupid questions, this stuff is very foreign to me so I am struggling to get my head around it. I have done a lot of reading but it is a very complex topic!

I guess the end result I want is to only allow clients that I authorise to connect to my openHAB server. That is my primary concern. I am not convinced simple user/password accounts is enough to ensure this. My understanding was I could achieve that with TLS authentication - i.e. I install a certificate on each device I want to authorise, and that is used during the authentication process to check against the server certificate. I 'think' that is how my MQTT broker is configured, which is what gave me the idea to do something similar for openHAB.

Am I making any sense or have I got it all completely wrong?!?

[Till Klocke]

Cryptography is a very complex subject on its own. In combination with IT security it is even more complex.

Generating your own certificate is important so no one else has the private key and can therefore listen on your connection. Using username and password can be secure enough, they just have to be complex enough to withstand also sophisticated brute force attacks (like word book attacks) und shouldn't be guessable with public available info about you.

Using client certificates offers even more security (if done right), but you will need a save way to transfer your certificate to all systems you are using as a client. Therefore just using your buddies PC to turn up your heating before you go home isn't possible with client certificate based authentication. 

I for myself am satisfied with username and password (but then again, openHAB isn't connected to my security system). 

The problem with certificate based authentication is also,that currently except from browser no openHAB client supports this, so you always need to use the webUI (which can be a hassle on slow connections). I will probably implement certificate based auth in HABSweetie, but this will take some time.

More important than using certificate based auth is the secure and correct setup of TLS. So avoid weak ciphers such as RC4 (easily breakable), use certificate pinning (don't trust any certificate other than your own) and make sure that no unecrypted connections are allowed.

[Jan-Piet Mens]

Till,

Could you post your nginx.conf, respectively the rev proxy detail you use for openHAB?

I'm trying to help Ben get this working, but I think I'm seeing openHAB return a broken (as in incorrect) URI to the sitemap when using habDroid and the iOS app.

Are you rewriting URLs in nginx?

FWIW, accessing OH from a Web browser through either Stunnel or nginx works.

Thanks,

-JP

[Ben Jones]

Hey Till,

I have been working with JP to try and get TLS authentication using Stunnel. I have created a new pair of certificates and configured Stunnel to use these. I have also installed the CA certificate on my phone. 

When I browse to my external IP address in a Chrome browser on my phone I get a nice green padlock icon and can access everything just fine. I can send commands and item states are updated.

If I try to access openHAB using HABDroid I see the toast messing saying 'Connection to configured URL' but then nothing happens. The UI is blank. In my stunnel logs I am seeing;

    SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request

In the iOS client it is a little different. When opening the app pointing at the external IP address I see the sitemap correctly rendered. I can navigate to different pages, but as soon as I try and send a command - i.e. switch a light on - I get an error message pop up "Error - The network connection was lost." and the same SSL error in the stunnel logs as above.

According to the stunnel FAQs;

If you get the following error message in stunnel:

2003.01.18 17:46:07 LOG3[6093:32770]: SSL_accept: 1407609C: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request

then your stunnel runs in server mode (without client = yes) and your web browser is connecting to it as if it is a normal webserver, ala http://example.com/.

If stunnel is supposed to be running as a client, then fix your stunnel.conf. If you do mean to be running as an SSL server then point your browser at https://host:port/ instead of http://host:port/.

Do you (or anyone else) have any idea what could be going wrong here? It looks like it is something to do with the openHAB apps themselves, since everything works just fine using a Chrome browser over stunnel. 

Is it possible the apps (in different places since the behaviour is slightly different) are sending http requests even when configured to connect using SSL? This would explain the error in the stunnel logs and corresponds with what the stunnel FAQs are saying.

I am a bit of a loss to explain it otherwise. Open to any other suggestions!

Best regards,

Ben

[Till Klocke]

Hi Ben,

sorry, I forgot to post my nginx config. I will do that as soon as I cleaned it up a bit.

Chrome and other browser have TLS authentication build in so they can handle this. Apps like HABDroid, HABSweetie and the iOS-Client usually don't have this authentication mechanism build in. It depends on the library they use to connect how they handle such a situation. If this authentication method is not implemented at least an error should be shown (probably you can test HABSweetie, I don't know what it will do). iOS probably this a little bit better, since things like connecting to URLs are "deeper embedded" in the OS and probably use the iOS keystore to retrieve a matching client certificate. Getting TLS authentication to work could be quite a bit of work. I need to have look at this closer.

But with TLS authentication you are currently stuck with using the browser based clients. You could try and deactivate TLS authentication, then all clients should work. This would at least make certain, that your basic stunnel configuration (apart from the authentication part) is working with all clients.

[Ben Jones]

Hi Till,

I was under the impression that using something like stunnel would alleviate the issue of the apps not handling TLS, since stunnel would handle all the certificates etc and the apps would just continue to work as normal, effectively sitting 'above' the stunnel layer.

Sounds like that is not the case. 

I guess I will just have to rely on strong passwords until the apps are updated to include TLS.

Thanks for your help with this.

Regards,

Ben

[Jan-Piet Mens]

Till,

we're not talking about TLS client authentication, just about access
over TLS. :-) It is understood that TLS client auth (with X.509
certificates) means a lot more work.

What Ben is saying is that the Stunnel connection fails after first
successfully being able to access the openHAB installation.

Short tests (I'll do more on Thursday) against nginx show that the
client appears to be redirected to an incorrect URI (in my case I saw
the sitemap name being tacked on twice -- no idea if that's part of the
OH REST API or not).

I'd very much appreciate getting a glance at your nginx.conf, and I'll
gladly test more and report back.

Regards,

-JP

[Jan-Piet Mens]

FWIW, I think proxying to openHAB will work only if openHAB 'thinks'
it's being contacted via HTTPS. The reason is that it is building links
to "elements" (sorry: don't know a better term) with an 'http' scheme
from within the REST API, and the clients are directed to 'http'
resources whereas they should be directed to 'https' resources.

I've been able to get this working for both HABdroid and iOS' openHAB
apps using nginx. (See my scribbled notes at
https://gist.github.com/jpmens/8027912), but the result is, ah,
unsatisfactory: for example, flicking a switch in one of the apps,
doesn't 'flick' the switch in the other. (This is possibly due to
keepalive issues, I don't know.)

Due to the required URL rewriting, which nginx (or Apache) can do, but
Stunnel cannot, I consider it unlikely that we'll get Stunnel to work
with openHAB.

-JP

[Ben Jones]

I hope JP doesn't mind me sharing this but he has written a very easy-to-follow guide about how to configure openHAB to use your own set of SSL/TLS certificates. 

https://gist.github.com/jpmens/8029383

A big thanks to JP for spending the time to write this!! 

Beer credit increasing daily...

[Kai Kreuzer]

Very nice indeed!

I would pledge for moving this to the official wiki - or is there any reason not to put it there?

Regards,

Kai

[Ben Jones]

I have added a link to JPs post in the security page of the openHAB WIKI.

[Marcel Verpaalen]

Nice indeed... would have saved me a lot of time trying to figure out how this SSL certificate install works...
Maybe for others that also would search a lot, I used this site to create trusted certificates for free http://www.startssl.com

Op vrijdag 20 december 2013 04:17:31 UTC+1 schreef Ben Jones:

[oliver_...@gmx.de]

Today I encountered the same problem. I just wonder why it is like that. Is it a "bug" in openhab's REST impementation or is an nginx configuration issue?

It's not a clean solution to connect to the openhab instance via https://loalhost:8443. SSL connection on localhost are just useless. I reallly would like to connect to http://localhost:8080, but the all the links in the rest answers use http as the scheme instead of https.

Are there any additonial ideas in order to fix this. I just don't know how to start ;-)

[Klaus Maria Pfeiffer]

hi!

On 09/18/2014 10:02 AM, oliver_...@gmx.de wrote:
> On Wednesday, December 18, 2013 8:14:48 PM UTC+1, Jan-Piet Mens wrote:
>> FWIW, I think proxying to openHAB will work only if openHAB 'thinks'
>> it's being contacted via HTTPS. The reason is that it is building links
>> to "elements" (sorry: don't know a better term) with an 'http' scheme
>> from within the REST API, and the clients are directed to 'http'
>> resources whereas they should be directed to 'https' resources.

> Today I encountered the same problem. I just wonder why it is like that.
> Is it a "bug" in openhab's REST impementation or is an nginx
> configuration issue?

it will be both. on one side nginx needs to add a certain HTTP header to
give OpenHAB the chance to detect it should build links with httpS scheme.

if I go for proxying something my nginx config looks like
;===
server {
listen 80;
server_name openhab.example.org;
rewrite ^ https://$http_host$request_uri? permanent;
}
server {
listen 443;
server_name openhab.example.org;

ssl on;
ssl_certificate /etc/pki/certs/openhab.example.org.pem;
ssl_certificate_key /etc/pki/private/openhab.example.org.key;

location / {
# proxy_pass https://localhost:8443;
proxy_pass http://localhost:8080;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Protocol $scheme;
}
}
;===

the magic is in X-Forwarded-Protocol $scheme. :-)

> It's not a clean solution to connect to the openhab instance via
> https://loalhost:8443. SSL connection on localhost are just useless. I
> reallly would like to connect to http://localhost:8080, but the all the
> links in the rest answers use http as the scheme instead of https.

in the meantime we can accept it as a workaround.

> Are there any additonial ideas in order to fix this. I just don't know
> how to start ;-)

I would prefer to fix it by evaluating the additional
X-Forwarded-Protocol header, but I do not have any idea where in the
REST API.

any hints where this could have been fixed?

gre3tings, Klaus

--
Klaus Maria Pfeiffer
chat: xmpp:hoedl...@jabber.rekmp.net
blog: http://blog.kmp.or.at/
twitter: @hoedlmoser
pgp: 0xeb7a9021