OrientDB over SSL

[eduardoejp]

Are there plans to have the binary protocol go over SSL?

I'd feel better knowing nobody can sniff my server<-->DB communications.

[Emrul Islam]

Nobody? Have you read the Snowden leaks in the news recently? ;)

For my own servers I prefer to setup VPN between them rather than rely on SSL protocols for a number of reasons:

- usually more efficient (built into OS kernel in most cases) & can compress all traffic

- encrypts all traffic between machines, not just any one protocol. This is useful if you use remote logging & monitoring tools

- if there's a hole in the SSL library its a headache to go update every piece of software you have that uses SSL

- avoids the overhead of having to create a secure session for each connection

Not suggesting that VPN is invulnerable, but it is a more secure setup in my opinion with lots of advantages.

[odbuser]

@Emrul : I agree about the VPN except there's also a need to do orientdb ssl intercommunication even over a VPN.  In any case, it has been mentioned that inter orientdb communication can use SSL (not sure if this is 1.6 and up or if it has been implemented...) but the client connections (remote client) can't use SSL yet.

LVC, please expound on this.  SSL is critical for my application.  It it's not available, I'll have to use a combination of secure orientdb clusters (if available) and colocated an https server with each orientdb node that accesses orientdb using a non-ssl connection.  I'd rather eliminate the extra https server but I'd need the remote client connections to be secure.

[Luca Garulli]

Hi,

right now OrientDB hasn't an integrated SSL support. By a quick look at SSL support in Java 1.6+ seems very simple to implement a new listener based on secure socket:

http://stilius.net/java/java_ssl.php

Could you open a new issue for this? In the meanwhile does anyone know a wrapper/proxy to use SSL connections?

Lvc@

--
 
---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ena]

Hi Luca, any news about this topic? We'd like to use OrientDb as database+application server (all in one solution). Problem is that basic authentication without https isn't secure at all...

[Luca Garulli]

Hi,

we've a prototype but not ready for the production. In the meanwhile why don't you setup an Apache HTTPD in front to OrientDB?

Lvc@

[Ena]

Hi Luca, I think we will. 

We wanted to get advantage of the out-of-the-box load balancing of OrientDB without adding possible bottlenecks.

But we will study this solution.

Thanks,

Elena

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "OrientDB" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/orient-database/64qSj2mn3m4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to orient-databa...@googlegroups.com.

[Luca Garulli]

Ciao Elena,

maybe as soon as we've a beta version of the new HTTP engine we could involve you on testing?

Lvc@

[odbuser]

Will the remote:/ connection be secured as well?

As an aside, Hazelcast (used for clustering/replication) can be secured.  Some of the configuration doesn't work as expected (like strict protocol and cipher limiting).  Once I figure it out I'll submit it to Hazelcast.  That leaves the Rest and remote: ports that lack security.  Both of these should be relatively easy to address as they probably only need a configurable SSLSocketFactory.

[Luca Garulli]

Hi,

we've a new native SSL support: https://github.com/orientechnologies/orientdb/wiki/Using-SSL-with-OrientDB.

Lvc@

On 14 February 2014 21:35, odbuser <odbu...@gmail.com> wrote:

Will the remote:/ connection be secured as well?

As an aside, Hazelcast (used for clustering/replication) can be secured.  Some of the configuration doesn't work as expected (like strict protocol and cipher limiting).  Once I figure it out I'll submit it to Hazelcast.  That leaves the Rest and remote: ports that lack security.  Both of these should be relatively easy to address as they probably only need a configurable SSLSocketFactory.

--