4

I'm already using AWS Elasticache Redis but without "Encryption in-transit". I've created a new small/temp cluster with this Encryption Enabled but I can't connect to it -

redis-cli error: Connection reset by peer

eg: redis-cli -h aws.host.name -p 6379

Note: connects fine when In-Transit Encryption isn't enabled on a Redis Cluster.

I'm sure this is because I'm not using TLS Encryption from the EC2 instance:

"To connect to an in-transit encryption enabled cluster, a database must be enabled for transport layer security (TLS). To connect to a cluster that is not in-transit encryption enabled, the database cannot be TLS-enabled."

Questions:

  • I'm really not sure how to enable TLS encryption on EC2. How to I do this? Do I need to use an stunnel or can I use AWS SSL Certs?
  • What impact on performance would/could this have?
  • I'm also looking at Redis AUTH Password. Is this a big performance hit? I'm guessing if Redis is frequency hit it could well do.

thanks so much.

  • I observed the same issue: 'Connection reset by peer' errors when trying to reach Redis elasticache from a Lambda function within a VPC. I assume my security group and subnet settings were correct, because when I disabled encryption, it worked. – bjmc Dec 5 '17 at 11:41
4

The standard client, redis-cli doesn't support encryption. There is a list of redis clients which support ssl/TLS encryption at https://redislabs.com/blog/secure-redis-ssl-added-to-redsmin-and-clients/

| improve this answer | |
0
  • You don't need to use stunnel. The standard redis-cli -h aws.host.name -p 6379 should work from your EC2 instance. Check that you can connect to the host and port (simply telnet host 6379). If there is no connection, then check the security group settings of your ElastiCache cluster (you need to have inbound port 6379 rule, its configured in EC2 tab, Security Groups section).
  • There is some network overhead (see https://stackoverflow.com/questions/1615882/how-much-network-overhead-does-tls-add-compared-to-a-non-encrypted-connection) and additional CPU (see HTTPS overhead compared to HTTP). I don't expect this to be significant for most applications. All depends on how you using it, so run your own tests.
  • Redis AUTH exchange only happens when you establish the session. Should be no additional overhead thereafter.
| improve this answer | |
0

The standard redis client (aka the redis-cli which comes with the redis server) does not support TLS.

That's why when in-transit encryption is disabled is connects successfully to the server. You should use a client that supports TLS.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.