HTTPS网关代理HTTP微服务：流量加密性及安全实践问询

网关到微服务的流量是否加密？ #

不加密。底层原理很直接：你的微服务采用HTTP协议，网关转发请求时会以明文HTTP形式与微服务通信——哪怕是同一台机器，流量在本地网络栈中也是明文状态（跨进程通信时数据会经过操作系统网络层，并非完全隔离）。

这种做法是否属于不良实践？ #

分场景判断：

• 如果所有微服务和网关都在同一台物理机/虚拟机内，且主机本身处于安全状态（无未授权进程、无入侵风险），这种做法不算严重的不良实践。本地进程间的明文传输风险相对可控，加上防火墙限制了微服务的外部访问，进一步降低了暴露风险。
• 但存在潜在隐患：比如主机被入侵后，恶意进程可监听本地端口抓取明文请求；若未来微服务扩容到多台机器，当前未加密的架构会直接导致跨主机流量明文传输，风险陡增；同时这种架构也不符合“默认加密”的安全最佳实践。

如何提升代理通信的安全性？ #

方案1：用私有CA实现内部HTTPS加密 #

无需给微服务配置公网证书，搭建私有CA给内部微服务签发证书即可——因为网关和微服务都由你控制，私有CA的证书可被网关信任，完美解决之前的证书链问题。步骤如下：

1. 生成私有CA根证书（仅需一次）
2. 用私有CA给每个微服务签发证书（CN可填微服务内部域名，如service1.local或localhost）
3. 网关代理请求时，配置信任私有CA根证书并启用证书验证

示例代码（网关侧，基于http-proxy-middleware）：

const https = require('https');
const fs = require('fs');
const { createProxyMiddleware } = require('http-proxy-middleware');

// 读取私有CA根证书
const privateCaCert = fs.readFileSync('./private-ca-root.crt');
const httpsAgent = new https.Agent({
  ca: privateCaCert,
  rejectUnauthorized: true // 强制验证证书，防范中间人攻击
});

// 代理到HTTPS微服务
app.use('/service1', createProxyMiddleware({
  target: 'https://service1.local:3001',
  changeOrigin: true,
  agent: httpsAgent
}));

方案2：Unix域套接字（仅适用于同一台机器） #

完全绕开TCP网络栈，用Unix域套接字实现进程间通信——流量不经过网络层，安全性极高且性能更好。

微服务侧代码：

const express = require('express');
const app = express();
const fs = require('fs');
const socketPath = '/tmp/service1.sock';

// 启动前清理已存在的套接字文件
if (fs.existsSync(socketPath)) {
  fs.unlinkSync(socketPath);
}

app.get('/', (req, res) => {
  res.send('Service 1 response');
});

// 监听Unix套接字
app.listen(socketPath, () => {
  console.log(`Service 1 listening on ${socketPath}`);
  // 设置套接字权限为仅当前用户可访问，避免其他进程窃取数据
  fs.chmodSync(socketPath, 0o600);
});

网关侧代理配置：

const { createProxyMiddleware } = require('http-proxy-middleware');
const socketPath = '/tmp/service1.sock';

app.use('/service1', createProxyMiddleware({
  target: `unix:${socketPath}`,
  changeOrigin: true,
  onProxyReq: (proxyReq) => {
    // 手动设置Host头，适配内部服务
    proxyReq.setHeader('Host', 'localhost');
  }
}));

方案3：修复公网证书链问题（若坚持用公网证书） #

之前配置微服务HTTPS时遇到证书链问题，大概率是两个原因：

1. 证书的SAN（Subject Alternative Name）字段未包含微服务的访问域名（如localhost或内部域名）
2. 微服务未配置完整的证书链（缺少中间证书）

解决方法：

• 申请证书时，将微服务的内部访问域名添加到SAN列表中
• 配置微服务HTTPS时，传入完整的证书链（服务器证书+中间证书）

示例代码（微服务侧）：

const https = require('https');
const fs = require('fs');
const express = require('express');
const app = express();

const httpsOptions = {
  key: fs.readFileSync('./server-private-key.pem'),
  cert: fs.readFileSync('./server-cert.pem'),
  ca: fs.readFileSync('./intermediate-cert.pem') // 加入中间证书，补全证书链
};

https.createServer(httpsOptions, app).listen(3001, () => {
  console.log('Service 1 running on HTTPS port 3001');
});

内容的提问来源于stack exchange，提问作者Aarick-F