Is anyone kind enough to tell me what actual companies do about the matter? This is assuming the company doesn't run the risk of having insiders sniffing the packets.
2 Answers
In general it is more secure for communications to make use of encrypted (https) communications.
For data, that is PII or financial in nature I alway recommend secure protocol.
However, when you introduce encryption it can make some processes more difficult.
- Debugging - it is harder to analyze network traffic to find issue.
- IDS/IPS - There network appliance analyze traffic and respond to attacks. If they cannot see into traffic they have less info to respond with.
- Latency/ CPU cost - Adding encryption increase the time before first connection and the cpu power needed to communicate (https://istlsfastyet.com/). The intro of http2 has lowered the latency somewhat and modern hardway usually has crypto acceleration built in.
- PKI management - HTTPS Pki management is difficult is using private certificates for local domains.
On a private network, the need for https is greatly reduced but issues such as snippers and accidental leaks do exist. It really depends on the private network, data and risk tolerance. For example:
Log data flowing between two server by a shielded-wire in a datacenter in a locked cage. May not need encryption.
Open wifi with no encryption, I would strongly recommend here.
PKI based tls is more expensive via computations and required more set up. Instead you may want to use encryption that relies on pre-shared keys. If you can securely enter the keys.
![](../../users/profiles/200731.webp)
- 158
- 5
-
Aside from drawbacks of using encryption, one of the first BENEFITS of encryption on an internal network is that threats don't just exist externally, but internally there are also considerations of protecting data from being sent in clear text. Certainly if passwords or salaries or any other sensitive data is being sent between servers, you would want to prevent internal users from reading the data. A major benefit of encrypting internal traffic. – HackneyB Mar 03 '19 at 01:14
Everything Anthony T says, plus:
It really depends on how secure you think your private network is, and the sensitivity of the data involved - which may have legal/regulatory requirements.
Untill a few years ago we generally terminated TLS/SSL at the perimeter and did not encrypt internal communications due to:
Reported CPU overhead of upto 40%
The risk of a service outage due to expired certificate.
Customers generally don't have their own private PKI/CA and don't want to pay for one.
Setting up security was yet another complication that PMs/sales never costed.
Buying 100s of certs from the likes of verisign is expensive and you don't need a public CA for internal comms anyway. It also involves an outage to replace them which means disruption for the customer, and potentially dozens of man hours of weekend effort to take a group of related systems offline, replace some certs, then restart and test all processes. And we often only get 1 or 2 maintenance windows a year.
I am finally seeing a shift in thinking though. CPU overhead now seems much lower, or at least much less noticeable, and some application stuff now routinely reports on certificate validity. We're starting to use long-life internal certs (10 years+) on some less sensitive cases where certificate handling is built into the tools. But the supportability issue remains in many areas though.
![](../../users/profiles/191162.webp)
- 141
- 3