38

I have a front end web server running over HTTPS - this is public facing - i.e. port is open.

I also have a backend API server that my webserver makes API requests to - this is public facing and requires authentication - port is open.

These 2 servers run over HTTPS.

Behind the API server, there are lots of other servers. The API server reverse proxies to these servers. Ports for these other servers are not open to incoming traffic. They can only be talked to via the API server.

My Question ... 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?

I thought this would be a common question but I could not find an answer to it. Thanks. If this is a dupe please point me to the right answer.

Improve this question
8
  • 35
    In light of how the NSA tapped into the overseas links that Google and Yahoo used to communicate in between their data centers unencrypted, I'd recommend that you always assume that a connection is suspect. You never know where someone might be listening in, and it's better to be safe than sorry. The only time I would I would consider using HTTP alone is a service running on the same machine that uses it, open only to local connections.
    – childofsoong
    Aug 29, 2016 at 18:20
  • 7
    This is known as ssl offloading and ssl termination if you want to do further research.
    – Esben Skov Pedersen
    Aug 29, 2016 at 20:19
  • 31
    It's like asking "do all doors need locks, or just outside-facing doors"? Only you can answer this question when considering threats within and without your network.
    – Ryan Griggs
    Aug 29, 2016 at 21:31
  • 5
    As the Security.SE faq says: "Security is a very contextual topic: threats that are deemed important in your environment may be inconsequential in somebody else's, and vice versa. Are you trying to protect something of global value against Advanced Persistent Threats? Or are you looking for a cost-effective approach for a low-profile small business? To get the most helpful answers you should tell us: what assets you are trying to protect; who uses the asset you're trying to protect, and who you think might want to abuse it (and why); ...
    – D.W.
    Aug 29, 2016 at 22:58
  • 2
    what steps you've already taken to protect that asset; what risks you think you still need to mitigate." This kind of context is essential. I suggest you edit your question to include this information.
    – D.W.
    Aug 29, 2016 at 22:58

6 Answers 6

Reset to default
50

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.

Improve this answer
11
  • 1
    it's better to start there - the words that gave you the points :)
    – danday74
    Aug 29, 2016 at 19:23
  • 12
    This is a Good Idea. You don't want the NSA making goofy drawings of your network topology.
    – Kevin
    Aug 30, 2016 at 3:03
  • 3
    Encrypting all your communications also safeguards against internal eavesdropping -- whether that be in the form of the intern's computer that picked up a trojan while browsing cat pictures, or a small sniffer plugged into a network port behind an unused desk, or a wifi password shared a little too loosely.
    – Doktor J
    Aug 30, 2016 at 4:24
  • 8
    "We'd set the expiration date nice and far into the future to avoid unnecessary changes." and please add a rule to your preferred monitoring suite to warn you when it's about to expire. Please!
    – GnP
    Aug 30, 2016 at 14:54
  • 2
    @GnP I do that as well - if it's a cert with a 10 year period our policy always mandates the backend server is replaced within that period.. Makes it a bit redundant and didn't seem necessary to mention in the answer.
    – Tim Brigham
    Aug 30, 2016 at 14:59
19

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:

Improve this answer
16

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?

Improve this answer
13

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).

Improve this answer
3
  • Wheather data might be sensitive enough: Someone might base their wrong decisions on tampered wheather data.
    – Hagen von Eitzen
    Sep 1, 2016 at 9:47
  • 1
    Fair enough, it does depend on what you're using the weather data for. I was trying to come up with something innocuous. :)
    – Katherine Villyard
    Sep 1, 2016 at 15:04
  • 1
    @HagenvonEitzen or the attacker would inject malware/ads in there, so grandma gets pwned when she checks the weather using her Windows XP machine.
    – André Borie
    Sep 2, 2016 at 3:15
8

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.

Improve this answer
1
  • Nice thought process
    – danday74
    Aug 31, 2016 at 4:28
5

The only reason to disable encryption that I can think of is performance. However, in your case internal servers are interfaced via HTTP, meaning they already bear the performance cost of running a web server, supporting HTTP protocol and encoding data in HTTP/JSON/whatever. Disabling encryption will free perhaps 100KB of RAM and earn you a few microseconds per KB of transmitted data, which will have no visible impact on overall performance. On the other hand, you'll have to pay significantly more attention to security since you run HTTP in your intranet now. In fact, it's possible that more strict firewall configuration will slow things down more than disabling encryption have speeded them up, resulting in worse performance perceived by end users.

It will be like putting a spoiler on a tractor: you gain next to nothing theoretically, and a lot of inconvenience practically.

Improve this answer

You must log in to answer this question.

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