New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Jedis SSL support for redis cache communication #50

Open
yuriyz opened this Issue Sep 25, 2017 · 12 comments

Comments

Projects
None yet
5 participants
@yuriyz
Contributor

yuriyz commented Sep 25, 2017

No description provided.

@yuriyz yuriyz added the enhancement label Sep 25, 2017

@yuriyz yuriyz added this to the CE 3.2.0 milestone Sep 25, 2017

@yuriyz yuriyz self-assigned this Sep 25, 2017

@yuriyz

This comment has been minimized.

Contributor

yuriyz commented Sep 25, 2017

@nynymike let me know if we need it in 3.1.1

@tecoholic tecoholic changed the title from Add SSL support to jedis to Add Jedis SSL support for cache communication Sep 26, 2017

@tecoholic

This comment has been minimized.

tecoholic commented Sep 26, 2017

Presently oxAuth via Jedis, communicates in plain TCP with redis cache. In order to secure the communication, use the SSL support available in Jedis and send the data to redis via SSL.

@tecoholic tecoholic changed the title from Add Jedis SSL support for cache communication to Add Jedis SSL support for redis cache communication Sep 26, 2017

@afroDC

This comment has been minimized.

afroDC commented Nov 7, 2017

If Jedis can send communications via SSL to redis, and redis has no SSL capabilities out of the box, how would this be implemented? Does it store the data encrypted?

@yuriyz

This comment has been minimized.

Contributor

yuriyz commented Nov 8, 2017

@afroDC then it will not work I guess. Redis must have SSL configured. SSL is transport, it has nothing to do with data storage.

@afroDC

This comment has been minimized.

afroDC commented Nov 8, 2017

I'm curious as to what Jedis SSL is even for.

@yuriyz

This comment has been minimized.

Contributor

yuriyz commented Nov 8, 2017

@afroDC It's for secure connection. Please check redis docs. It clearly suggest to use proxy for SSL, see here
https://redis.io/topics/security
http://www.tarsnap.com/spiped.html

@afroDC

This comment has been minimized.

afroDC commented Nov 8, 2017

Right, we're using stunnel for our cluster manager application to handle all over the internet communications. I suppose you would only need to install an stunnel client on 1 end, vs both ends if we used Jedis SSL.

@nynymike

This comment has been minimized.

Contributor

nynymike commented Nov 8, 2017

We already looked at these options and decided to use stunnel.

@yuriyz yuriyz modified the milestones: CE 3.1.2, Future Nov 9, 2017

@yuriyz

This comment has been minimized.

Contributor

yuriyz commented Nov 9, 2017

Right, with this SSL support stunnel would be required only on one end. Anyway, if I got @nynymike it's not priority because we have solution, unscheduled it from 3.1.2 milestone and put it for future. We can schedule it at any time if required.

@yuriyz

This comment has been minimized.

Contributor

yuriyz commented Jun 22, 2018

As requested by @afroDC I've added two more parameters to RedisConfiguraiton class

  • useSsl - specified whether to use ssl connection
  • sslTrustStoreFilePath - path to trust store file. It is optional, if not specified, native java trust store is used.

yuriyz added a commit that referenced this issue Jun 22, 2018

yuriyz added a commit that referenced this issue Jun 22, 2018

clean up #50
(cherry picked from commit 5437b42)
@yurem

This comment has been minimized.

Contributor

yurem commented Jul 4, 2018

Is it implemented?

@yurem yurem modified the milestones: Future, 4.0 Jul 4, 2018

@yuriyz

This comment has been minimized.

Contributor

yuriyz commented Jul 4, 2018

It is partly done. Main use case is cluster connection. Jedis does not support SSL with cluster however there is PR here. So in future with next version of jedis that contains that PR we should be able to finish it. For now we stick to stunnel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment