General question on secure channels and implementations

Question

1. In the modern world of fast CPUs and large memory blocks should we use TLS encrypted channels outside of the browser/server paradigm ? One of the examples would be to establish TLS connection across internal micro services. For example two microservices inside the same AWS VPC subnet ? Or the general routing policies are enough to guarantee the security ?
2. Why TSL/SSL termination is required ? Is there any reason of its existence aside from supporting pure HTTP software, such as Varnish ?

Disclaimer: please note that I have absolutely zero knowledge in secure infrastructures and their protection, hence explanations in layman terms are appreciated.

Answer 1

1. The current practice assumes that general routing policies are sufficient. This is mostly for ease of use for Ops (content-based traffic shaping, automated intrusion detection, etc, work easier on unencrypted traffic) more than anything else. It isn't a BAD assumption - if someone owns a machine sufficient to have access to traffic sniffing, they probably could access the ssl certs for that machine. It does mean that things are less contained than they could be. It is a risk-management decision - do you add security and slow down your ops team? Or go a little more open and make their life easier.

2. One advantage of SSL/TLS termination at the border and HTTP internally is easier access to content for intrusion detection purposes. It is also a lot easier to have SSL dealt with in one place, rather than having to ensure trusts using wildcard certs (if using an external CA) or self-signed certs for the individual hosts (if using an internal self-signed CA). It gets harder to do TLS internally with scaling - hosts are appearing and disappearing. Clear is easier. Again, this is a trade off - you need to make a decision for your environment, your content, your need for scaling and fast changes, your ops team.