Do all servers need to use the HTTPS protocol or just public facing servers?
Solution 1:
This is a matter of opinion, and also has to do with regulatory issues (if you face any).
Even if it's not currently necessary I am a big advocate of keeping the HTTPS enabled between any application level firewalls / load balancers / front end servers and the back end servers. It's one less attack surface. I've contracted with places that needed to convert over as more sensitive information began being passed - it's better to start there.
What I generally would suggest is using an internal CA (if available) or self sign (if no internal CA) the back end servers. We'd set the expiration date nice and far into the future to avoid unnecessary changes.
Solution 2:
TL;DR you should encrypt the traffic unless it's on the same host.
You can't trust your network. Malwares in your own network can intercept/modify http requests.
It's not theoretical attacks, but real life example:
Routers (probably hacked) inside the network of some websites injecting ads: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild-A-Large-Scale-Study-wp.pdf
Indian network sniffing between cloudfare and back-end: https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.hymc3785e
The now famous "SSL Added and removed here :-)" from the NSA
Solution 3:
Do the "lots of other servers" need to run over HTTPS or, given that they cannot be accessed externally, can they run over HTTP safely instead?
This really depends on what you are trying to accomplish. Understand the purpose of using HTTPS is to protect data in transit between two points. If you are concerned about the data being sniffed inside your network then maybe that should be taken care of first. If you need to protect the data in transit inside your network what you are saying is that you either have a concern about the security of data traversing your systems inside your network or there is some compliance related reason for you to encrypt the data in transit.
This is really more of an opinion question, but the answer is it depends. What are you trying to do? What kind of data are you encrypting? What threats are you trying to defend from? Do you have a legal requirement (e.g. PCI-DSS, HIPAA, etc.) that says you need to encrypt the data in transit? If the data is sensitive and you are concerned it could be misused when it is being transmitted inside your network then I would suggest getting together with management to fix the problem. So in the end, what are you trying to protect and why are you trying to protect it?
Solution 4:
Back in the day, people assumed that internal networks were safe as houses. I once got into a dispute with a supervisor who was appalled that my internal-facing servers were running their built-in firewalls. "If you can't trust your internal network, who can you trust?" I pointed out that we had student laptops on our internal network, and that there was no firewall between the student laptops and my servers. He, being new to academia, appeared to have his universe in tatters at this information.
Internal networks are no longer considered that safe, even if you don't have student laptops on your network. See Tom's answer for some examples.
That said, yes, it depends on what information is being transmitted, any legal compliance issues, etc. You might decide that you don't care if someone sniffs, say, weather data. That said, it's possible that even if the data sent isn't sensitive now, someone might decide to add features to your application later that are sensitive, so I would recommend greater paranoia (including HTTPS).
Solution 5:
Today with specialized CPU instructions to speed encryption, and new transport protocols that will not operate at all or operate with degraded performance over an unencrypted link (HTTP/2, gRPC, etc...), perhaps the better question is: Is there any reason why you require to downgrade a network link to HTTP? If there's no specific reason, then the answer is stay with HTTPS.