Is TLS necessary for security in a properly secured network?

Reasons to use TLS everywhere:

TLS no longer has the performance implications it once had. So that’s not an excuse not to use it. Yes there is an initial connection setup costs and especially for web browsing that can introduce a (small) initial delay but on an internal network that isn’t noticeable.

Certain software (particularly web browsers) work better with TLS and certain features (e.g. location services, HTTP/2... etc.) only work when used with TLS and more will join this list. So TLS absolutely should be used on internal intranet sites and dev environments. Additionally browsers will not differentiate between intranet and internet sites and will be adding more and more warnings for non-HTTPS sites. You do not want to get into the habit of telling users to ignore those warnings for your internal sites!

There is no such thing as a “secure network” in this modern, interconnected world - just varying degrees of insecurity. If a piece of malware gets into the secure network (either by accident or by malicious intent!) then it can potentially sniff network traffic and read passwords and the like which puts your systems at risk and also others (like it or not people do reuse passwords).

Reasons not to use TLS:

Saying that I don’t believe in absolutes and there are reasons not to use it.

For a start it does have a cost - particularly in setup and management. People can talk all about LetsEncrypt all they want and internal CAs - both of which are great things btw and highly recommended - but the very nature of TLS certificates expiring and the complexity in setting them up (particularly with Java keystores!) mean there is a cost to using TLS. Getting the certificates can be manual as LetsEncrypt is often not an option for internal servers and in my experience the toolset for automating issuance from an internal CAs is just not there usually (bring on ACME support please!) and then recognising any internal CAs takes effort.

TLS loses its value if the private keys are not kept well, private! So getting one wildcard certificate, to solve the issuance problem discussed above, and using it everywhere and making the private key relatively freely available to allow it to be used kind of defeats the purpose. So back to the issuance problem.

It also requires managing for the config: both in configuring it appropriately and then managing it going forward. Insecure protocols (e.g. SSLv3 and now even TLSv1.0) should be switched off and similarly for insecure ciphers. On top of that libraries kept up to date to allow secure config and new protocols/ciphers to continue to be used. Knowing what all the settings are and what should be used is a specialist job! And even if you know this, actually configuring this across many different pieces of software and infrastructure can be difficult.

Many web setups still use TLS offloading in a web server (e.g. Apache, Nginx) and then proxy unencrypted HTTP to backend app servers like Tomcat, Wildfly, NodeJS...etc. to simplify the management of TLS. This is a perfectly valid model within a secure network (though see points above about that term!). Especially when the web server and app server reside on the same host (and so the network traffic does not leave the server) or within a segregated network area (e.g. a DMZ or VPC).

Conclusion

To me the going on position should be to use TLS and then come up with a good reason why not to, rather than the other way around (and just cause “it takes effort should not be just accepted as a valid reason). However if you can justify why not to use it (e.g. as in the examples in the last paragraph above) and made a conscious decision for that and you (any any other stakeholders!) are comfortable with that then that might be what’s right and appropriate. That will not be as secure as using TLS of course, but that’s by to say it’s not the right choice.