1

I have an internet isolated EC2 instance which is a Ruby client and it is connecting with multiple EC2 servers of mine in the same network having different sub-domain names. These EC2 servers are protected with forced SSL whenever they are accessed from the internet.
But since the Ruby client is isolated from the internet, can I connect with my EC2 servers with SSL verification flag turned off? I am using Faraday client and for development I have done Faraday::Connection.new host, { ssl: { verify: false } }

My reasoning behind this is that there will be two types of ssl certificates for different use cases, one will be our production ssl certificate and other one will be self signed ones on developer systems. And maintaining all those different ca paths on this one client server can be a roadblock.

What can go wrong if I disable client side ssl verification off on this internet isolated instance?

This is different from this question because the connection between the client and server is happening on an internal network.

Improve this question
3
  • If someone can listen to your internal traffic (e.g. an attacker who who compromised an employee's machine), they see all data unencrypted. It's a bad idea to use plain text communication these days.
    – user163495
    Commented Apr 9, 2020 at 13:11
  • Does this answer your question? What are practical risks of http (not https) in server-to-server communications
    – user163495
    Commented Apr 9, 2020 at 13:12
  • 1
    I think that since the OP mentions that all components are withing the same AWS EC2 network, I think that makes it a different question than the linked one; and "employee's machine" because employees should absolutely not have a personal machine within a prod EC2 network.
    – Mike Ounsworth
    Commented Apr 9, 2020 at 13:41

1 Answer 1

Reset to default
1

If you are considering routing back-end microservice traffic over HTTP, then the question you should ask are:

  • Who can sniff this traffic? How much effort is involved in pulling off that attack? What data will they be able to see? Does that violate your security model?
  • Who can intercept, modify, or spoof traffic? How much effort is involved in pulling off that attack? What data will they be able to modify? Does that violate your security model?

You mention that your microservices are running in AWS EC2 in the same network. Is this is a production quality EC2 network / VPC? What software components are running there? Is there any software components that you don't trust, for example, open source of questionable origin / quality? Which humans have ssh access to this network? If your EC2 environment is driven by strong deployment automation then maybe no people have SSH access, or only a small number of trusted admins.

Summary

It's common in cloud environments to have TLS of incoming requests to terminate at the front-end load balancer and then propogate through your backend as HTTP.

So do your security analysis, and if you decide that it's low risk to have your backend microservices communicate with each other over HTTP, then you will be using a common design pattern!

TLS terminating at the front-end load balancer

[Image source from this Medium article]

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .