上周二晚上八点，安全组同事突然在群里@我——"你们终端到服务端的数据是明文传输的，Wireshark一抓就看到了完整的用户数据。"我当时心里一紧，赶紧打开抓包工具一看，果然，终端上报的数据全是明文JSON，连用户手机号和地址都清清楚楚。那天晚上加班到十一点，把整个传输链路的加密方案重新设计并落地了一遍。这篇记录下整个排查和改造过程。

## 一、先搞清楚：为什么数据会明文传输

这个终端应用是两年前开发的，当时为了快速上线，数据传输直接用了HTTP+JSON，没有做任何加密。后来虽然加了HTTPS，但终端到服务端的业务数据本身还是明文的——HTTPS只保护传输通道，不保护业务数据。

```txt
// 原始代码：明文传输
String data = "{\"userId\":\"12345\",\"phone\":\"13800138000\",\"address\":\"北京市朝阳区\"}";
httpClient.post(url, data); // 明文JSON直接发送
```

这段代码的问题在于：
1. 业务数据是明文JSON，任何人抓包都能看到完整内容
2. 虽然有HTTPS，但HTTPS只保护传输通道，服务端收到后数据还是明文
3. 没有数据签名，中间人可以篡改数据
4. 没有密钥管理，即使加密了密钥也可能泄露

更严重的问题是，这个终端应用运行在公共WiFi环境下，攻击者可以很容易地进行ARP欺骗和中间人攻击，截获所有传输数据。

## 二、第一步：AES-256加密业务数据

解决明文传输的第一步是对业务数据进行加密。我们选择了AES-256-CBC模式，这是目前业界标准的对称加密算法，安全性高且性能好。

```txt
// AES-256-CBC加密
public String encrypt(String data, byte[] key, byte[] iv) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
    SecretKeySpec keySpec = new SecretKeySpec(key, "AES");
    IvParameterSpec ivSpec = new IvParameterSpec(iv);
    cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);
    byte[] encrypted = cipher.doFinal(data.getBytes("UTF-8"));
    return Base64.getEncoder().encodeToString(encrypted);
}
```

加密参数说明：
1. 密钥长度256位（32字节），安全性足够
2. CBC模式，每个明文块与前一个密文块异或后再加密，安全性高于ECB
3. IV（初始化向量）16字节，每次加密随机生成，不重复
4. PKCS5Padding，自动填充到16字节的整数倍

踩坑提醒：
- IV必须每次随机生成，不能固定，否则相同明文会产生相同密文
- IV不需要保密，可以和密文一起传输
- 密钥不能硬编码在代码里，必须从安全的密钥管理系统获取
- 加密后的数据要Base64编码，否则二进制数据无法在JSON中传输

## 三、第二步：密钥轮换，防止密钥泄露

加密解决了数据保密性，但如果密钥泄露了，所有加密数据都能被解密。所以必须定期轮换密钥，即使某个密钥泄露了，影响范围也有限。

我们的密钥轮换策略：
1. 主密钥每90天轮换一次
2. 数据加密密钥（DEK）每天轮换一次
3. 旧密钥保留30天，用于解密历史数据
4. 密钥版本号随密文一起传输，服务端根据版本号选择对应密钥解密

```txt
// 密钥版本化加密
public class EncryptedData {
    private int keyVersion;      // 密钥版本号
    private String iv;           // 初始化向量(Base64)
    private String encryptedData; // 加密后的数据(Base64)
    private String signature;    // 数据签名
}

// 服务端根据版本号选择密钥
byte[] key = keyManager.getKey(encryptedData.getKeyVersion());
```

踩坑提醒：
- 密钥版本号必须随密文一起传输，否则服务端不知道用哪个密钥解密
- 旧密钥不能立即删除，要保留足够长时间解密历史数据
- 密钥轮换要平滑，不能中断服务，新旧密钥要并行一段时间
- 密钥存储要用专门的密钥管理系统（如KMS），不能存在数据库或配置文件里

## 四、第三步：证书校验，防止中间人攻击

加密和密钥轮换解决了数据保密性和密钥安全，但还有一个问题——中间人攻击。攻击者可以伪装成服务端，让终端把加密数据发给攻击者，攻击者再转发给真正的服务端。

防止中间人攻击的方法是SSL证书校验——终端必须验证服务端的证书，确保证书是可信的CA签发的，且证书域名与请求域名一致。

```txt
// SSL证书校验
SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(null, new TrustManager[]{new X509TrustManager() {
    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType)
            throws CertificateException {
        chain[0].checkValidity(); // 检查证书是否过期
        if (!"api.example.com".equals(chain[0].getSubjectDN().getName())) {
            throw new CertificateException("域名不匹配");
        }
    }
    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) {}
    @Override
    public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
}}, new SecureRandom());
```

踩坑提醒：
- 不能跳过证书校验，否则HTTPS等于没加密
- 不能信任所有证书（如设置TrustAllManager），这会让中间人攻击成为可能
- 要校验证书链，确保证书是由可信CA签发的
- 要校验证书域名，确保证书域名与请求域名一致
- 要处理证书过期情况，提前更新证书

## 五、踩坑清单：5个我实际踩过的坑

1. **IV固定导致相同明文相同密文**：我一开始把IV固定成了"1234567890123456"，结果相同的明文每次加密都产生相同的密文，攻击者可以通过密文对比推断明文。后来改成每次随机生成IV，问题解决。

2. **密钥硬编码在代码里**：早期版本把AES密钥直接写在代码里，反编译就能拿到。后来改成从服务端动态获取密钥，密钥用RSA加密传输，终端用私钥解密。

3. **加密后没做签名导致数据被篡改**：只加密不签名，攻击者虽然不能解密，但可以篡改密文，服务端解密后得到错误数据。后来加了HMAC-SHA256签名，服务端验签通过才处理。

4. **证书校验被跳过导致中间人攻击**：测试环境为了方便，设置了TrustAllManager跳过证书校验，结果这个配置被带到了生产环境。后来加了环境判断，生产环境必须严格校验证书。

5. **密钥轮换时旧密钥被立即删除**：第一次做密钥轮换时，新密钥生效后立即删除了旧密钥，结果历史数据无法解密。后来改成旧密钥保留30天，平滑过渡。

这次终端数据传输加密改造是在唯顿收银系统的终端应用上做的，我主要负责AES加密链路和密钥轮换机制，上线后终端到服务端的业务数据全部加密传输，安全扫描从"高危"降到"低危"，再也没有出现过明文抓包的问题。

## 复盘要点

1. AES-256-CBC加密业务数据是基础：密钥256位、CBC模式、IV每次随机、PKCS5填充，加密后Base64编码。
2. 密钥轮换防止密钥泄露：主密钥90天轮换、DEK每天轮换、旧密钥保留30天、密钥版本号随密文传输。
3. 证书校验防止中间人攻击：不能跳过证书校验、不能信任所有证书、要校验证书链和域名、要处理证书过期。

以上是个人实践记录，各平台具体功能以官方实时信息为准。

留个问题：你们终端数据传输加密是用对称加密还是非对称加密？密钥轮换周期是多久？

上周二晚上八点，安全组同事突然在群里@我——"你们终端到服务端的数据是明文传输的，Wireshark一抓就看到了完整的用户数据。"我当时心里一紧，赶紧打开抓包工具一看，果然，终端上报的数据全是明文JSON，连用户手机号和地址都清清楚楚。那天晚上加班到十一点，把整个传输链路的加密方案重新设计并落地了一遍。这篇记录下整个排查和改造过程。

终端数据明文传输被抓包排查：AES-256加密、密钥轮换与证书校验的落地记录

记录终端数据明文传输被抓包排查全过程：原始代码HTTP+明文JSON导致Wireshark可直接看到用户手机号和地址，用AES-256-CBC加密业务数据，密钥90天轮换+DEK每天轮换+旧密钥保留30天，SSL证书校验防止中间人攻击。踩过IV固定、密钥硬编码、没做签名、跳过证书校验、旧密钥立即删除等5个坑。

安全

客户端

后端

AES-256-CBC加密业务数据，密钥轮换+证书校验防中间人攻击，解决终端明文传输问题。分享IV随机、密钥管理、签名防篡改等5个实战踩坑经验，从高危到低危的安全改造全记录。

热销域名限时优惠，新客首年免费！


domain

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

终端数据明文传输被抓包排查：AES-256加密、密钥轮换与证书校验的落地记录-腾讯云开发者社区-腾讯云

终端数据明文传输被抓包排查：AES-256加密、密钥轮换与证书校验的落地记录

终端数据明文传输被抓包排查：AES-256加密、密钥轮换与证书校验的落地记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐