企业官网建设流程全解析

说到前后端加密通信，AES+RSA混合加密是绕不开的一套经典方案。它解决的是一个非常现实的问题：HTTP请求在传输链路上是明文，即使上了HTTPS，业务数据到达服务端之后，依然可能在网关日志、运维平台、数据库流水里以可读形式存在。我在实际项目里不止一次遇到接口报文被中间环节记录后直接拼出业务明文的情况，所以才整理出这套前后端应用层加密通信方案，核心思路很直接：用RSA保护AES密钥的传输，用AES加密真正的业务数据，两边各取所长。这篇文章会从方案选型讲到完整代码落地，再到我踩过的坑和排查思路，适合正在做登录接口、订单接口、隐私数据上报等场景的开发者参考。

1. 为什么需要AES+RSA混合加密

1.1 HTTPS都上了，为什么还要再多一层加密

很多人的第一反应是：都上HTTPS了，数据在传输过程中不是已经加密了吗？从TLS握手到证书校验，HTTPS确实解决了数据在网络上传输时的机密性和完整性。但这里有几个容易被忽略的点。第一，HTTPS加密的终止点在服务端网关或负载均衡器，数据一旦进入内部网络，比如经过日志采集、反向代理转发、微服务之间的调用链路，很多环节都能看到明文。我在某个跨平台系统里排查过一个问题：接口文档里明明写着敏感字段加密，结果在运维平台的访问日志里直接能看到用户名和手机号，就是因为应用层根本没做加密，而TLS在网关就已经终止了。

第二，HTTPS的保护范围是"传输过程中"，它管不到请求到达服务器之后的事情。如果服务端代码里不小心把请求体打印到日志，或者把数据原样存入数据库，这些泄露途径HTTPS完全无能为力。第三，在某些企业内网场景里，客户端和服务端之间还可能经过多层代理，有些代理需要做内容审计，这时候TLS流量本身就是被解密的。所以，对真正敏感的数据，在应用层再做一次加密，让业务数据在整个生命周期内都保持密文状态，是更稳妥的做法。

1.2 对称加密与非对称加密的取舍

要理解混合加密为什么合理，得先看清两种加密方式各自的脾气。对称加密，比如AES，最大的优点是快，同样一段数据，AES加密比RSA快几个数量级，适合加密大量业务数据。但它的核心难题是密钥分发：加密和解密用的是同一个密钥，这个密钥怎么安全地传给对方？直接明文传，等于把保险柜钥匙贴在柜门上；走TLS传，又回到了“依赖传输层安全”的原点。

非对称加密，比如RSA，解决了密钥分发问题：公钥可以公开，私钥留在服务端，客户端用公钥加密的内容只有服务端私钥能解开。但RSA的短板也很明显，一是慢，二是对明文长度有严格限制。2048位的RSA密钥，用PKCS1填充时最多只能加密245字节，用它直接加密动辄几百字节的业务JSON报文根本不现实。

所以，把两者结合是顺理成章的思路：客户端每次请求生成一个随机的AES会话密钥，用这个密钥加密业务数据；再用服务器的RSA公钥加密这个AES密钥；服务端收到后，先用自己的RSA私钥解出AES密钥，再用AES密钥解出业务数据。RSA只负责加密一段16到32字节的密钥，既绕开了长度限制，又保证了密钥的机密传输，AES则负责真正的大数据量加密，性能开销也完全可以接受。

1.3 混合加密解决的核心问题

这套方案解决的不只是"传输加密"一个问题，它还顺带带来几个额外的好处。

第一，数据防窥探。接口报文在网关、日志、监控系统里看到的都是密文，即使被抓包，攻击者拿到的也是无意义的字符。

第二，防篡改。AES-CBC模式下，密文的任何一个分组被改动，解密后的明文都会出现不可预期的乱码，服务端可以通过校验解密结果或者附加校验值来发现异常。更进一步，配合消息认证码或者签名机制，可以做到完整的完整性校验。

第三，密钥动态化。每个请求都使用新生成的AES密钥，即使某一次请求的密钥被破解，也影响不了其他请求，攻击者无法通过历史报文反推后续通信内容，降低了密钥泄露的爆炸半径。

2. 方案设计与参数选型

2.1 RSA密钥长度与填充方式怎么定

RSA的参数选择直接决定安全性和可用性。我自己在正式项目里统一用2048位密钥，不推荐1024位，因为目前业界普遍认为1024位已经不够安全，而4096位虽然更安全，但密钥生成和加解密耗时明显增加，对Web接口的吞吐影响不小。2048位是当前安全性和性能的平衡点。

填充方式上，Java后端默认支持RSA/ECB/PKCS1Padding，它兼容性最好，绝大多数语言和加密库都能互通。但PKCS1Padding本身存在一些理论上的安全隐患，比如Bleichenbacher攻击。如果项目对安全性要求很高，可以考虑OAEP填充，对应Java里的RSA/ECB/OAEPWithSHA-256AndMGF1Padding。我在一个金融模拟项目里就强制用了OAEP，前端配合JSEncrypt也能支持。不过要注意，OAEP对明文长度限制更严格，2048位密钥用SHA-256的OAEP最大只能加密190字节左右，加密一个16字节的AES密钥完全没问题，但加密长内容就绝对不行。

2.2 AES算法模式与密钥长度的选择

AES本身有三个主流密钥长度：128位、192位、256位。对绝大多数业务场景，AES-128已经足够，它的密钥空间是2的128次方，暴力破解在可预见的未来都不现实。AES-256的密钥长度更长，安全性上限更高，但加解密性能会略低一些。前端用CryptoJS生成密钥时，我习惯用128位，也就是16字节，因为后面还要用RSA加密这个密钥，密钥越短，RSA加密的负担越小。

模式选择上，我在跨平台项目中优先选CBC模式。CBC需要初始向量IV，相同明文在不同IV下会产生不同密文，这本身就提供了随机性。前端和后端必须使用相同的IV才行，我通常让前端每次请求随机生成16字节的IV，并把它拼接在密文前面一起传，服务端从中截取IV再解密，这样同一个AES密钥在多次请求中也不会产生相同的密文。

GCM模式是更优的选择，它同时提供加密和完整性校验，还能附带额外的认证数据。我在一个新项目中尝试过前端用Web Crypto API的AES-GCM，后端用Java的AES/GCM/NoPadding，效果很好。但GCM对前端库的支持参差不齐，CryptoJS老版本不支持GCM，如果团队前端技术栈受限制，CBC加手动校验是更稳妥的过渡方案。

2.3 整体加密通信流程设计

整个通信流程我设计成下面这个样子：

• 客户端启动后先从服务端获取RSA公钥，这个接口本身走HTTPS即可，公钥可以在客户端本地缓存，设置一个合理的过期时间，比如24小时。
• 每次请求前，客户端生成一个16字节的随机AES密钥，再生成16字节的随机IV。
• 用AES密钥和IV加密业务数据，得到密文。
• 用RSA公钥加密AES密钥，得到加密后的密钥。
• 把加密密钥、IV、密文一起放到请求体里发给服务端。
• 服务端用RSA私钥解出AES密钥，再用AES密钥和IV解密密文，得到业务数据。
• 响应数据的处理方式和请求对称：服务端用同一个AES密钥加密响应数据，返回加密密钥、IV和密文，客户端用自己生成的AES密钥解密响应。

这样做的好处是，整个会话过程中AES密钥只在客户端和服务端之间以密文形式传递，而且每个请求的密钥都不一样。我在实际落地中发现，把"加密密钥、IV、密文"这个三元组设计成统一的数据结构，前端封装一个方法，后端写一个拦截器或过滤器，后续新增加密接口时基本不用改业务代码，只需要在框架层面统一处理。

3. 核心代码实现：前后端完整落地

3.1 后端：RSA密钥对生成与公钥下发

后端我以Java为例，其他语言思路完全一样。首先需要生成RSA密钥对，生产环境下建议在服务器启动时加载预先生成的密钥文件，不要每次启动都重新生成，否则重启后客户端缓存的公钥就会失效。

import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.PrivateKey; import java.security.PublicKey; import java.util.Base64; public class RsaKeyManager { public static void generateAndPrintKeys() throws Exception { KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA"); generator.initialize(2048); KeyPair keyPair = generator.generateKeyPair(); PublicKey publicKey = keyPair.getPublic(); PrivateKey privateKey = keyPair.getPrivate(); // 公钥可以下发给前端 String publicKeyBase64 = Base64.getEncoder().encodeToString(publicKey.getEncoded()); // 私钥必须保存在服务端，绝不能泄露 String privateKeyBase64 = Base64.getEncoder().encodeToString(privateKey.getEncoded()); System.out.println("公钥: " + publicKeyBase64); System.out.println("私钥: " + privateKeyBase64); } }

公钥下发接口很简单，就是把Base64编码的公钥字符串返回给前端。需要注意一点：公钥是公开的，可以直接放在接口响应里，不需要加密。但如果企业安全规范要求更高，也可以对公钥做签名，前端用内置的验签公钥来校验下发的公钥没有被篡改，防止中间人替换公钥。我在一个金融模拟项目里就实现过公钥签名机制，流程稍微复杂，但安全性确实更完整。

RSA解密AES密钥的方法如下：

import javax.crypto.Cipher; import java.security.PrivateKey; import java.util.Base64; public class RsaHelper { public static byte[] decryptByPrivateKey(String encryptedKeyBase64, PrivateKey privateKey) throws Exception { byte[] encryptedKeyBytes = Base64.getDecoder().decode(encryptedKeyBase64); Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding"); cipher.init(Cipher.DECRYPT_MODE, privateKey); return cipher.doFinal(encryptedKeyBytes); } }

3.2 前端：AES密钥生成与双重加密请求

前端这里我用CryptoJS做AES加密、JSEncrypt做RSA加密，这两个库比较老牌，兼容性好，几乎什么环境都能跑。如果用原生Web Crypto API也可以，代码稍多一点，但性能更好、更安全。

前端核心封装代码示例如下：

import CryptoJS from 'crypto-js'; import JSEncrypt from 'jsencrypt'; // 获取RSA公钥并缓存 let cachedPublicKey = ''; async function getPublicKey() { if (cachedPublicKey) { return cachedPublicKey; } const res = await fetch('/api/public-key'); const data = await res.json(); cachedPublicKey = data.publicKey; return cachedPublicKey; } // 加密请求数据 async function encryptRequest(payload) { // 1. 生成随机的AES密钥和IV const aesKey = CryptoJS.lib.WordArray.random(16); // 16字节 = 128位 const iv = CryptoJS.lib.WordArray.random(16); // 2. AES加密业务数据 const encryptedData = CryptoJS.AES.encrypt(JSON.stringify(payload), aesKey, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); // 3. RSA加密AES密钥 const publicKey = await getPublicKey(); const encryptor = new JSEncrypt(); encryptor.setPublicKey(publicKey); const encryptedKey = encryptor.encrypt(aesKey.toString()); // 4. 拼接请求体 return { encryptedKey: encryptedKey, iv: CryptoJS.enc.Base64.stringify(iv), data: encryptedData.toString() }; }

这段代码里有几个细节非常关键。CryptoJS的WordArray.random(16)生成的是16字节的随机数据，作为AES-128密钥；在调用AES.encrypt时，如果key传的是WordArray对象，CryptoJS会直接使用它作为密钥，不会走默认的密码派生逻辑。这一点特别容易踩坑：如果传的是字符串，CryptoJS会把它当作密码用OpenSSL的EVP_BytesToKey算法派生出真正的密钥，前后端就永远对不上了。

CryptoJS.AES.encrypt返回的对象调用toString()时，默认输出Base64格式的密文，这正好适合放进JSON里。IV也转成Base64传给后端，后端从Base64解码成字节数组。注意IV必须和密文一起传，缺少IV，CBC模式无法解密。

3.3 后端：解密请求与加密响应

后端拿到前端三元组之后，先解出AES密钥，再解出业务数据。完整流程如下：

import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.util.Base64; public class DecryptHelper { public static String decryptRequest(String encryptedKeyBase64, String ivBase64, String dataBase64, PrivateKey rsaPrivateKey) throws Exception { // 1. RSA解密得到AES密钥 byte[] aesKeyBytes = RsaHelper.decryptByPrivateKey(encryptedKeyBase64, rsaPrivateKey); SecretKeySpec aesKeySpec = new SecretKeySpec(aesKeyBytes, "AES"); // 2. 从Base64还原IV byte[] ivBytes = Base64.getDecoder().decode(ivBase64); IvParameterSpec ivSpec = new IvParameterSpec(ivBytes); // 3. AES解密业务数据 Cipher aesCipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); aesCipher.init(Cipher.DECRYPT_MODE, aesKeySpec, ivSpec); byte[] plainBytes = aesCipher.doFinal(Base64.getDecoder().decode(dataBase64)); return new String(plainBytes, StandardCharsets.UTF_8); } }

响应加密的逻辑和请求相反，服务端用同一个AES密钥加密响应数据，然后返回给前端。这里有一个设计决策：响应体里要不要再放一次加密后的AES密钥？我的做法是不放。因为AES密钥本来就是前端生成的，前端自己就持有明文密钥，直接在本地解密响应即可。如果后端需要重新生成响应密钥，就必须把新密钥再用前端的某种方式安全传递回去，这在纯后端无法实现，除非让前端也持有一对RSA密钥并把公钥注册到服务端，但那样方案就重了。所以我在实践里都是让请求密钥延续到响应阶段，一个请求一个密钥，响应结束密钥即废弃。

public static Map<String, String> encryptResponse(String plainText, byte[] aesKeyBytes, byte[] ivBytes) throws Exception { SecretKeySpec aesKeySpec = new SecretKeySpec(aesKeyBytes, "AES"); IvParameterSpec ivSpec = new IvParameterSpec(ivBytes); Cipher aesCipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); aesCipher.init(Cipher.ENCRYPT_MODE, aesKeySpec, ivSpec); byte[] encryptedBytes = aesCipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); Map<String, String> result = new HashMap<>(); result.put("data", Base64.getEncoder().encodeToString(encryptedBytes)); result.put("iv", Base64.getEncoder().encodeToString(ivBytes)); return result; }

3.4 前端：响应报文解密

前端收到响应后，直接从本地拿到之前生成的AES密钥和IV，解密响应数据。

function decryptResponse(encryptedDataBase64, aesKey, ivBase64) { const iv = CryptoJS.enc.Base64.parse(ivBase64); const decrypted = CryptoJS.AES.decrypt(encryptedDataBase64, aesKey, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); return decrypted.toString(CryptoJS.enc.Utf8); }

解密时同样要传相同的IV和mode，decrypted.toString(CryptoJS.enc.Utf8)返回的就是明文JSON字符串。这里有一个常见问题：如果解密时IV对不上或者密钥被篡改，toString(CryptoJS.enc.Utf8)会返回空字符串，不会抛异常，所以前端一定要做空值判断，否则页面会显示空白数据，排查起来很迷惑。

为了让这套逻辑不侵入业务代码，我在项目中把加密逻辑封装成一个统一的请求钩子和响应拦截器，业务层只需要调用一个encryptRequest方法或全局封装的http.post，进来的是普通对象，出去的是解密后的对象，对业务代码完全透明。说实话，这个封装的工作量大概占整个方案的30%，但价值很大，后续团队其他成员接手时，不需要理解加密细节，直接用就行。

4. 常见问题与排查心得

4.1 前端加密结果后端解不开

这是我在多个项目中被问得最多的问题，几乎每次都是同一个原因：前端传的AES密钥不是原始密钥字节，而是CryptoJS的WordArray对象或字符串经过某种转换后的结果。CryptoJS在AES.encrypt时如果传入的是WordArray，就直接作为密钥；但如果代码里写成aesKey.toString()，WordArray转成字符串时默认是Hex编码，也就是32个字符的十六进制串，后端如果直接把这32个字符的UTF-8字节当成AES密钥，密钥就变成了32字节，和前端用的16字节密钥完全不是一回事。

正确做法是：前端提取密钥时用aesKey.toString(CryptoJS.enc.Hex)，后端用Hex解码还原成16字节；或者干脆不改，把WordArray对象直接用，但明确后端解的是Hex格式。我在代码里习惯加注释标注"此处传Hex格式的AES密钥"，避免后人误改。

后端的SecretKeySpec构造时，传入的字节数组长度必须是16、24或32字节，对应AES-128/192/256。如果头尾对不上，Java通常会抛异常；如果长度恰好碰对了但内容不对，解密会成功但产出乱码。排查顺序一般是：先确认密钥字节数组的长度，再确认IV字节数，最后确认密文是否做了正确的Base64解码。

4.2 RSA加密报错长度过长

RSA/ECB/PKCS1Padding用2048位密钥时，单次加密的最大明文是245字节，OAEP加SHA-256的话变成190字节左右。有的同事图省事，直接用RSA加密整个JSON报文，跑到线上就报Data must not be longer than 245 bytes。这类报错本质不是代码问题，是方案设计问题。RSA天生不适合加密大数据，它就是用来保护密钥、摘要这类短内容的。

解决办法有两个方向。一是严格遵守混合加密的套路，RSA只加密16字节的AES密钥，业务数据全部交给AES。二是如果非要RSA加密较长内容，就得分段加密，但分段会显著增加密文长度和耗时，而且容易引入填充边界问题，我强烈不建议。我在某个模拟项目X里见过一个野生实现：前端把报文切成几段分别RSA加密，后端再按顺序拼起来解密，中间只要一段损坏整个报文就废了，而且调试极其痛苦。

4.3 中文乱码与Base64细节

中文乱码的问题几乎都会经历一遍。根源在于字符编码在各个环节没有统一。我总结了一个固定搭配：前端用JSON.stringify序列化对象，按UTF-8编码后交给CryptoJS加密；解密后调用toString(CryptoJS.enc.Utf8)还原字符串；Java后端解密后new String(plainBytes, StandardCharsets.UTF_8)。只要这两端都明确走UTF-8，就不会出现乱码。

另一个细节是Base64。前端CryptoJS.AES.encrypt返回的对象toString()得到的是Base64，直接放进JSON没问题；Java后端用Base64.getDecoder()解码也没有问题。但要注意，如果引入的库是Apache Commons Codec或者Spring的Base64工具，它们默认可能不处理换行符，而实际传输的JSON字符串不会带换行，大多数情况下没事。只有在从日志复制密文去本地调试时可能出现换行问题，这时候去掉换行符再解码即可。

4.4 重放攻击防护与时间戳校验

加密只解决了密文问题，还没解决重放问题。攻击者虽然解不开密文，但他可以把整个加密请求原样重新发送一遍，如果这个请求是"转账""下单"这类有副作用的操作，服务端会再次执行，这就造成严重问题。我最早在项目里没做重放防护，结果测试环境出现过重复下单的bug，后来补上了时间戳加随机数机制。

具体做法是：请求体里增加一个timestamp字段，前端用当前时间戳；服务端解密后校验时间戳与服务器时间之差，超过正负五分钟直接拒绝。同时携带一个nonce随机字符串，服务端把这个nonce缓存到Redis并设置五分钟过期，同一个nonce再次出现就拒绝。这样既防止了时间窗口内的重放，又通过nonce去重保证了同一请求只能执行一次。

// 伪代码示意 long serverTime = System.currentTimeMillis(); long diff = Math.abs(serverTime - request.getTimestamp()); if (diff > 5 * 60 * 1000) { throw new SecurityException("请求已过期"); } if (!nonceService.checkAndStore(request.getNonce(), 5 * 60)) { throw new SecurityException("重复请求"); }

时间戳和nonce本身也必须放在加密的JSON里，不能放在明文请求头，否则攻击者篡改或重放时依然可以伪造。

4.5 密钥轮换与缓存策略

RSA私钥一旦泄露，整个系统的加密防线就崩塌了。所以密钥轮换不是一个可选项，而是必选项。我见过有的项目上线两年没换过一次RSA密钥，这是很大的隐患。合理的做法是：密钥对定期轮换，比如每三个月更换私钥，使用中的旧密钥保留一个过渡期，比如一周，用于解密过渡期内产生的请求，过了过渡期再彻底销毁。

实现上，密钥可以存在数据库或配置中心里，带上版本号和生效时间，服务端根据版本号选择对应的私钥去解密。前端获取公钥时自然拿到最新版本。当前端缓存了旧公钥时，用旧公钥加密的请求，服务端旧私钥还能解开，不会造成业务中断。这个设计在实战中非常重要，直接换密钥而没做兼容，线上会出现一批解密失败的报错。

公钥的缓存策略也应该注意平衡。缓存时间太短，前端每次请求都要重新拉公钥，RSA密钥对生成和网络请求都费时；缓存时间太长，密钥轮换后前端还拿着旧公钥，服务端旧私钥已销毁就会出问题。停在24小时通常比较合适。

5. 方案边界与进一步加固建议

5.1 实测性能与体积数据

我在某个跨平台系统里对这方案做过一轮压测，供大家参考。纯HTTPS请求的TPS大概是每秒2500左右；加上AES+RSA混合加密后，TPS降到每秒1600左右，主要开销集中在RSA解密上，RSA公钥加密和私钥解密都比AES慢好几个数量级。请求体的体积也会增加，原本3KB的JSON，加上Base64编码后变成4KB左右，其中主要是Base64带来的33%膨胀，以及加密密钥和IV的额外开销，总体可以接受。

如果对性能有极致要求，还有两个优化方向。一是会话密钥复用：前端在首次握手时生成AES密钥，后续多个请求都复用同一个密钥，只在密钥轮换或有效期到期时重新生成，这样RSA加解密只在建立会话时发生一次。二是升级到更快的非对称算法，比如国密SM2或者基于椭圆曲线的算法，它们在同安全级别下密钥更短、运算更快。

5.2 还需要补强的安全手段

混合加密只解决了"机密性"和一定程度的"完整性"，它不能解决所有安全问题。

身份认证还是得靠独立的登录态机制，比如JWT或服务端Session，AES+RSA不负责识别用户是谁。完整性校验可以叠加HMAC或者数字签名，防止密文在传输过程中被篡改后服务端仍然尝试解密，虽然CBC模式下篡改会导致解密乱码，但服务端不能只依赖"乱码"来判断数据是否被篡改，显式的校验更可靠。防御方面，接口层面还需要配合频率限制、风控策略和异常监控，加密只是安全体系的一部分，不是全部。

前端密钥的保存也值得注意。Web端密钥最终存在于浏览器内存中，XSS攻击可以直接拿到内存里的明文密钥，所以必须同时做好XSS防护，比如严格的内容安全策略、输入输出编码。如果安全等级要求极高，可以考虑把加解密放到Web Worker或者使用隔离环境，但成本会比较高，普通项目做好XSS防护就够了。

5.3 最后分享一点个人体会

我在实际项目里落过好几套不同方案的加密通信，最后发现做这套东西真正难的其实不是算法本身，而是工程上的细节。比如AES密钥在前后端之间的格式一致性，IV的传递方式，Base64编码在日志和数据库之间的流转，还有密钥轮换期间的兼容处理，每一个细节不注意，线上就是一堆解不开的密文。调试的时候，建议先把RSA这一层单独验证，确认能解出AES密钥；再把AES这一层单独验证，确认能解出业务明文。两层都通了再拼在一起，问题定位会快很多。

另外有一个小小的建议：不要给所有接口都上这套加密，成本不低。登录、支付、个人信息这类高敏感操作可以全量加密，普通列表查询和公开数据接口保持HTTPS即可。我在某个模拟项目中因为图省事把所有接口都套了加解密，结果排查问题时日志里全是密文，追踪一个数据问题要多花一倍时间。为了安全性牺牲一定可观测性，要权衡好比例。

这套方案的代码框架搭好之后，后续新增接口的成本实际上很低，核心的加解密逻辑都收敛在两个方法里，业务代码不需要感知。我在一个新的跨平台系统初始化阶段就把这套方案写进了基础框架，后续所有涉及隐私数据的接口都是"顺手加密"，长期来看收益很明显。如果你正准备给自己负责的系统加上应用层加密，建议从登录接口开始，验证完整的加解密流程之后再推广到其他敏感接口，循序渐进地铺开，比一次性全部改造要稳妥得多。