我正在设计一个软件 ATM，我想将必要的加密操作隐藏在一个“加密守护进程”后面，它访问磁盘上的加密密钥并为这些操作提供一个高级的、特定于应用程序的接口。
其他程序必须：
我有通过 localhost 使用 TCP 进行这些操作的想法。在进行 TCP 握手之后，程序必须向守护进程进行身份验证，并且 - 如果成功 - 可以向守护进程发出加密命令。
至少有两个假设必须成立，否则这在设计上是不安全的：
这些假设是真的吗？为什么？为什么不？还有什么缺陷吗？
环回连接通常不受中间人攻击（来自同一盒子上的其他非根进程，或来自盒子外部）。
如果您打算将环回用作穷人的传输安全（而不是 TLS），则必须确保连接的两端都受到适当的保护：
在客户端，允许未经授权的低权限进程连接到服务器的后果是什么？如果客户端访问受明文密码保护，您可能会考虑对该密码进行暴力攻击，并通过密码复杂性和故障审核来解决此问题。
在服务器端，是否可以想象一个低权限进程导致服务器终止（例如，由于输入格式错误或资源耗尽而导致服务器崩溃），并将其替换为木马侦听器，该侦听器会从客户端窃取密码或返回误导结果？您可能会考虑使用 Unix 的低端口号保护来阻止这种情况（但您必须担心以 root/setuid/fork 身份运行）。
这取决于您的威胁模型对防止本地访问的关注程度；您可能会认为您的基础设施和监控足以消除攻击者获得低权限帐户的情况。但在一般情况下，您最好还是硬着头皮选择众所周知的 TLS 解决方案。
除了内核和在 localhost 中运行的其他应用程序之外，它对所有内容都是安全的。如果您可以信任这些，那么它就是安全的。如果不是，则不是。
如果地址是 localhost，TCP 数据包将在 IP 层本身被路由回。由于它不通过电线，因此不可能被劫持/更改。
来自维基百科，强调相关信息。
Internet 协议套件的实现包括一个虚拟网络接口，当在同一台机器上运行时，网络应用程序客户端和服务器可以通过该接口进行通信。计算机程序发送到环回 IP 地址的任何流量都可以简单地立即传回网络软件堆栈，就好像它是从另一个设备接收的一样。
类 Unix 系统通常将此 LOopback 接口命名为 lo 或 lo0。
各种 IETF 标准为此保留了 IPv4 地址块 127/8（其中最常用的是 127.0.0.1）、IPv6 地址 ::1 和名称localhost。