JMeter RSA加密接口测试实战：5分钟搞定OAEP/PKCS#1加解密
1. 为什么RSA接口测试总卡在“加密失败”这一步？
JMeter实战：5分钟搞定RSA加密接口测试（附完整代码）——这个标题里藏着太多人踩过的真实坑。我第一次接到银行系支付接口压测任务时，也是被这句话骗进来的：「后端已启用RSA公钥加密，前端JS加密后传参」。结果在JMeter里跑通第一个请求就报错：javax.crypto.BadPaddingException: Data must start with zero。不是密钥格式不对，不是Base64解码失败，而是根本没搞清RSA加解密的上下文边界：JMeter默认不带任何密码学上下文，它只认字符串、JSON、HTTP头；而RSA加密要求你明确指定填充方案、密钥编码格式、字节序处理、甚至PKCS#1 v1.5和OAEP之间的语义鸿沟。
很多人直接去搜“JMeter RSA插件”，结果装了一堆第三方jar包，发现要么只支持旧版Bouncy Castle，要么和JMeter 5.6+的模块化类加载器冲突，最后在ClassNotFoundException里反复横跳。更隐蔽的问题是：你以为你在加密明文，其实你在加密JSON字符串的UTF-8字节数组；你以为公钥是PEM格式，其实JMeter读取时会把换行符当普通字符吞掉；你以为加密后Base64编码就能直接发，却忽略了URL安全Base64和标准Base64的+///=替换差异。
这篇内容不是教你怎么点几下鼠标配个BeanShell PreProcessor就完事，而是带你从Java密码学原语出发，用JMeter原生支持的JSR223 + Groovy（非BeanShell，后者已废弃且性能差），实现在5分钟内完成可复现、可调试、可维护的RSA加密流程。核心关键词就三个：JMeter、RSA加密、接口测试——不涉及任何密钥生成、证书管理、HTTPS握手，只聚焦「如何让JMeter像浏览器一样，把登录密码字段用服务端给的公钥加密后发出」这一具体动作。适合所有需要对接金融、政务、医疗等强安全要求系统的测试工程师、质量保障工程师，以及想绕过前端JS逆向、直击接口层做自动化压测的开发者。你不需要懂椭圆曲线，但得知道PKCS#1和OAEP不是同一种东西；你不需要写C语言，但得会看Java异常堆栈定位到哪一行Groovy代码出了问题。
2. RSA加密的本质不是“套公式”，而是“选对上下文”
2.1 为什么不能直接用JavaScript里的crypto.subtle？
因为JMeter不是浏览器。很多测试同学看到前端用window.crypto.subtle.encrypt()做RSA-OAEP加密，就想当然地以为JMeter也能跑同样代码。错。crypto.subtle是Web Crypto API，依赖浏览器沙箱环境、Web Worker线程模型、以及由TLS证书链背书的密钥导入机制。JMeter运行在JVM里，它没有window对象，没有SubtleCrypto实例，更没有importKey()所需的CryptoKey抽象。你硬塞一段JS进去，只会得到ReferenceError: window is not defined。这不是JMeter不行，而是场景错配——就像试图用Excel公式计算量子纠缠态，工具没错，只是问题域根本不匹配。
2.2 JMeter能用的唯一正统路径：JSR223 + Groovy + Bouncy Castle
JMeter官方明确推荐JSR223作为脚本扩展机制，而Groovy是其默认支持的语言（比BeanShell快3~5倍，且完全兼容Java语法）。关键在于：JMeter自带的Bouncy Castle版本（bcprov-jdk15on）必须与你使用的RSA参数严格匹配。我们实测发现，JMeter 5.6自带的是bcprov-jdk15on-170.jar（对应Bouncy Castle 1.70），它原生支持PKCS#1 v1.5（最常见于老系统）和RSA-OAEP（新系统主流），但不支持RSA/ECB/OAEPWithSHA-256AndMGF1Padding这种带MGF1参数的完整写法——必须简化为RSA/ECB/OAEPWithSHA-256AndMGF1Padding，否则抛NoSuchAlgorithmException。
提示：不要手动下载新版Bouncy Castle覆盖JMeter lib目录！JMeter 5.6+采用模块化类加载，强行替换会导致
SecurityException: class "org.bouncycastle.crypto.params.RSAKeyParameters" does not match trust level of other classes in the same package。正确做法是——用JMeter原生支持的版本，通过Groovy代码显式指定算法参数。
2.3 公钥加载的三大陷阱：PEM解析、Base64解码、KeyFactory选择
服务端给你的公钥，99%是PEM格式，形如：
-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu... -----END PUBLIC KEY-----但JMeter不会自动识别-----BEGIN这种分隔符。你必须手动剥离头尾，并对中间内容做Base64解码。这里有两个致命细节：
- 换行符处理：PEM内容里的
\n或\r\n在字符串中是真实字符，必须先replaceAll("[\\r\\n]", "")，否则Base64解码会失败； - KeyFactory选择：不能用
KeyFactory.getInstance("RSA")，必须用KeyFactory.getInstance("RSA", "BC")，强制指定Bouncy Castle提供者，否则JDK默认的SunRsaSign实现不支持OAEP； - X.509 vs PKCS#8：公钥PEM如果是
BEGIN PUBLIC KEY，则是X.509格式（DER编码）；如果是BEGIN RSA PUBLIC KEY，则是PKCS#1格式。两者ASN.1结构不同，X509EncodedKeySpec只能解析前者，RSAPublicKeySpec只能解析后者。绝大多数现代系统用X.509，所以统一用X509EncodedKeySpec。
我们实测过27个不同来源的公钥文件，其中3个因格式混用导致InvalidKeySpecException。解决方案是：写一个健壮的解析函数，先尝试X.509，失败则自动补全PKCS#1头尾再试。
2.4 加密前的明文预处理：不是“字符串加密”，而是“字节数组加密”
这是最反直觉的一点。RSA加密操作的对象永远是byte[]，不是String。当你写cipher.doFinal("123456".getBytes())时，你实际加密的是[49,50,51,52,53,54]这6个ASCII字节。但如果服务端期望的是UTF-8编码（比如中文密码），而你本地系统默认是GBK，"密码".getBytes()就会产生错误字节序列。因此必须显式指定编码："123456".getBytes(StandardCharsets.UTF_8)。
更隐蔽的问题是填充方案对明文长度的硬性限制。以2048位RSA密钥为例：
- PKCS#1 v1.5最多加密
2048/8 - 11 = 245字节； - OAEP（SHA-256）最多加密
2048/8 - 2*32 - 2 = 190字节。
如果你要加密一个300字节的JSON字符串，两种方案都会抛javax.crypto.IllegalBlockSizeException。此时必须切分明文或改用混合加密（RSA加密AES密钥，AES加密数据），但接口测试场景极少需要——因为真实业务接口的密码字段通常<50字节。所以我们的代码里会加入长度校验，超长时直接报错并提示最大允许字节数，避免在压测中途才发现失败。
3. 5分钟落地：从零配置到可运行的完整Groovy脚本
3.1 环境准备：三步确认，省去90%排错时间
在动代码前，请花2分钟确认以下三点，这比写100行代码还重要：
确认JMeter版本与Bouncy Castle兼容性
打开JMeter安装目录下的lib/文件夹，检查是否存在bcprov-jdk15on-*.jar。JMeter 5.4+默认带1.69或1.70版本。若不存在，从 JMeter官网依赖列表 下载对应版本，放入lib/后重启JMeter。切勿使用1.71+版本，因其引入了模块化签名，与JMeter类加载器冲突。确认公钥格式为X.509 PEM
用文本编辑器打开公钥文件，第一行必须是-----BEGIN PUBLIC KEY-----（注意是PUBLIC KEY，不是RSA PUBLIC KEY）。如果不是，请联系后端同事重新导出，或用OpenSSL转换：openssl rsa -in old_key.pem -pubout -out new_key.pem确认接口文档指定的加密算法
查阅接口文档，找到类似“加密方式：RSA/ECB/OAEPWithSHA-256AndMGF1Padding”或“填充方案：PKCS#1 v1.5”的描述。这是后续Groovy代码中Cipher.getInstance()的参数依据，填错一个字符就失败。
注意：如果文档没写，抓包分析前端JS代码。搜索
encrypt调用，看algorithm.name属性值。常见值有"RSA-OAEP"（对应OAEP）、"RSAES-PKCS1-v1_5"（对应PKCS#1 v1.5）。
3.2 JSR223 PreProcessor配置：位置、语言、作用域
在JMeter中，右键点击你要加密的HTTP请求 →Add→Pre Processors→JSR223 PreProcessor。关键配置项如下：
- Language: 选择
groovy（不是java、javascript或beanshell）； - Script: 粘贴下方完整代码；
- Target: 保持默认
"Variable Name"，即脚本结果存入JMeter变量； - Parameters: 留空（我们用vars.get()获取变量，不依赖此字段）；
- Execute for: 选择
"Every Iteration"（每次请求都执行，符合测试逻辑）。
提示：PreProcessor必须放在HTTP请求上方，且在同一层级（不能放在Thread Group里全局生效，必须绑定到具体请求）。否则变量
vars.put("encrypted_pwd", ...)不会被该请求读取。
3.3 完整可运行Groovy代码（含详细注释）
import javax.crypto.Cipher import java.security.KeyFactory import java.security.spec.X509EncodedKeySpec import java.util.Base64 import java.nio.charset.StandardCharsets import org.bouncycastle.util.encoders.Base64 as BCBase64 // ==================== 配置区：根据你的接口修改 ==================== // 1. 从JMeter变量获取原始明文（如登录密码） def plainText = vars.get("password") ?: "123456" // 2. 从JMeter变量或直接写死公钥PEM内容（推荐放入User Defined Variables） // 若放User Defined Variables，变量名设为"public_key_pem" def publicKeyPem = vars.get("public_key_pem") ?: """-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuVZz... -----END PUBLIC KEY-----""" // 3. 指定加密算法（严格按接口文档填写） // PKCS#1 v1.5: "RSA/ECB/PKCS1Padding" // OAEP (SHA-256): "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" def algorithm = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" // 4. 最大允许明文字节数（根据密钥长度自动计算，此处为2048位RSA的OAEP上限） def maxPlainTextBytes = 190 // ==================== 核心逻辑：公钥加载与加密 ==================== try { // 步骤1：清理PEM格式，提取Base64内容 def pemContent = publicKeyPem.replaceAll(/-----BEGIN PUBLIC KEY-----|-----END PUBLIC KEY-----|\s/g, "") // 步骤2：Base64解码为字节数组 def keyBytes = BCBase64.decode(pemContent) // 步骤3：构造X.509密钥规范 def keySpec = new X509EncodedKeySpec(keyBytes) // 步骤4：使用Bouncy Castle提供者生成公钥对象 def keyFactory = KeyFactory.getInstance("RSA", "BC") def publicKey = keyFactory.generatePublic(keySpec) // 步骤5：初始化Cipher（关键：指定提供者"BC"） def cipher = Cipher.getInstance(algorithm, "BC") cipher.init(Cipher.ENCRYPT_MODE, publicKey) // 步骤6：明文UTF-8编码，并校验长度 def plainBytes = plainText.getBytes(StandardCharsets.UTF_8) if (plainBytes.length > maxPlainTextBytes) { throw new RuntimeException("明文长度(${plainBytes.length}字节)超过RSA-OAEP最大允许${maxPlainTextBytes}字节") } // 步骤7：执行加密，返回字节数组 def encryptedBytes = cipher.doFinal(plainBytes) // 步骤8：Base64编码为字符串（标准Base64，非URL安全） def encryptedBase64 = Base64.getEncoder().encodeToString(encryptedBytes) // 步骤9：存入JMeter变量，供HTTP请求引用 vars.put("encrypted_pwd", encryptedBase64) log.info("RSA加密成功：原文'${plainText}' → 密文前10字符'${encryptedBase64[0..9]}...'") } catch (Exception e) { log.error("RSA加密失败：${e.getMessage()}", e) // 强制中断当前线程，避免发送错误请求 prev.setSuccessful(false) prev.setResponseMessage("RSA加密异常: ${e.getMessage()}") }3.4 在HTTP请求中引用加密结果
假设你的登录接口是POST/api/login，Body为JSON：
{ "username": "testuser", "password": "${encrypted_pwd}" }在JMeter中，将Body Data设置为：
{ "username": "${username}", "password": "${encrypted_pwd}" }其中${username}和${password}是JMeter用户定义的变量（或CSV Data Set Config读取），${encrypted_pwd}是上一步Groovy脚本生成的变量。注意：变量名必须完全一致，Groovy里是vars.put("encrypted_pwd", ...)，这里就必须用${encrypted_pwd}。
实测技巧：首次调试时，在View Results Tree监听器里勾选
"Show request"，展开请求Body，直接看到${encrypted_pwd}是否被正确替换为Base64字符串。如果还是变量名本身，说明PreProcessor未执行或变量名拼错。
4. 踩坑实录：那些让测试停摆3小时的“小问题”
4.1 坑位1：公钥PEM末尾多了一个空格，导致Base64解码失败
现象：Groovy脚本抛IllegalArgumentException: invalid base64 data，堆栈指向BCBase64.decode()。
排查过程：
- 第一步：在Groovy脚本开头加日志
log.info("Raw PEM: '${publicKeyPem}'")，复制日志中的字符串到在线Base64解码网站； - 第二步：发现解码网站报错，但手动删除PEM末尾空格后正常；
- 第三步：确认是JMeter User Defined Variables里粘贴公钥时，编辑框自动在末尾加了换行符。
根因：replaceAll(/\s/g, "")会清除所有空白符，包括末尾换行，但若PEM字符串本身包含不可见Unicode空格（如U+200B零宽空格），正则\s无法匹配。
修复方案：在清理PEM时增加Unicode空格过滤：
def pemContent = publicKeyPem.replaceAll(/[\s\u200B\u200C\u200D\uFEFF]/g, "")4.2 坑位2：加密后Base64字符串含+和/，被HTTP服务器当作路径分隔符截断
现象：请求发出去，服务端返回400 Bad Request，日志显示Invalid character '+' in parameter value。
排查过程：
- 第一步：用Wireshark抓包，发现HTTP Body里的密文确实含
+； - 第二步：查RFC 3986，确认URL中
+表示空格，/需编码为%2F； - 第三步：对比前端JS代码，发现其用
encodeURIComponent()对Base64结果二次编码。
根因：前端为适配URL传输，对Base64做了URL安全转义；而我们的Groovy脚本输出标准Base64，未做URL编码。
修复方案：在Groovy脚本末尾添加URL编码：
def urlSafeEncrypted = URLEncoder.encode(encryptedBase64, "UTF-8").replaceAll("\\+", "%20") vars.put("encrypted_pwd", urlSafeEncrypted)注意：
URLEncoder.encode()会把+转成%2B，但某些老服务端框架（如Spring MVC）默认将+解为空格，所以用replaceAll("\\+", "%20")更稳妥。
4.3 坑位3：JMeter并发时，多个线程共用同一个Cipher实例导致加密结果错乱
现象：单用户测试100%成功，但50线程并发时，约5%请求返回BadPaddingException，且失败请求的密文长度不一致。
排查过程：
- 第一步：在Groovy脚本中加线程ID日志：
log.info("Thread ${Thread.currentThread().getId()} encrypting...")； - 第二步：发现多个线程日志交错，且同一时刻有多个线程调用
cipher.doFinal()； - 第三步：查阅JDK文档，确认
Cipher对象不是线程安全的，必须每个线程独立创建实例。
根因：我们在脚本开头def cipher = Cipher.getInstance(...)是局部变量，看似安全，但若JMeter内部复用Groovy脚本引擎实例，可能造成状态污染。
修复方案：将Cipher创建移至try块内，确保每次执行都新建：
// 移除顶部的cipher声明 // 在try块内，keyFactory.generatePublic(...)之后立即创建： def cipher = Cipher.getInstance(algorithm, "BC") cipher.init(Cipher.ENCRYPT_MODE, publicKey)4.4 坑位4：服务端公钥更新后，JMeter未同步，加密结果服务端无法解密
现象：某天所有加密请求突然全部失败，错误信息为Decryption error，但公钥文件没变。
排查过程：
- 第一步：用OpenSSL命令行验证公钥有效性：
openssl rsa -pubin -in key.pem -text -noout； - 第二步：发现输出中
Modulus字段与上周不同； - 第三步：联系运维，确认昨晚灰度发布了新密钥对，旧公钥已停用。
根因：公钥是有时效性的，但测试人员习惯把公钥硬编码在JMeter脚本里，缺乏更新机制。
修复方案：建立公钥管理流程——
- 将公钥存入JMeter的
User Defined Variables，变量名public_key_pem； - 每次上线前，由开发提供新公钥，测试组长统一更新；
- 在Groovy脚本开头加校验：计算公钥模长（
publicKey.getModulus().bitLength()），若不等于2048则报错； - 进阶：用JSR223 Sampler在测试启动时，从配置中心API拉取最新公钥并存入vars。
5. 进阶技巧：让RSA测试真正融入CI/CD流水线
5.1 参数化公钥与算法：一份脚本适配多环境
生产、预发、测试环境的公钥不同，算法也可能不同（如测试用PKCS#1，生产用OAEP）。硬编码显然不可维护。解决方案是：用JMeter的__P()函数动态读取属性。
在User Defined Variables中定义：
env=prodpublic_key_prod=-----BEGIN PUBLIC KEY-----...public_key_test=-----BEGIN PUBLIC KEY-----...rsa_algorithm=RSA/ECB/OAEPWithSHA-256AndMGF1Padding
Groovy脚本中改为：
def env = props.get("env") ?: "test" def publicKeyPem = props.get("public_key_${env}") ?: vars.get("public_key_pem") def algorithm = props.get("rsa_algorithm") ?: "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"运行命令行时指定：
jmeter -n -t login.jmx -l result.jtl -p jmeter.properties -Denv=prod这样，同一份JMX脚本，通过不同-Denv参数即可切换环境，无需修改脚本。
5.2 加密结果断言：不只是“能跑”，还要“加得对”
光加密成功不够，还要验证加密结果符合服务端预期。我们加一层断言：
- 用JSR223 PostProcessor，在请求响应后，用相同公钥和算法，对响应体中的
encrypted_field进行二次加密，比对是否一致（仅用于调试，生产禁用）； - 或更实用的：用JSR223 Assertion，检查响应JSON中是否有
"code":0且"msg":"success"，同时"data"字段不为空。
5.3 性能监控：RSA加密耗时是否成为压测瓶颈？
在高并发场景下，RSA加密是CPU密集型操作。我们在Groovy脚本开头记录时间戳，结尾计算耗时：
def startTime = System.nanoTime() // ... 加密逻辑 ... def durationMs = (System.nanoTime() - startTime) / 1_000_000 if (durationMs > 50) { log.warn("RSA加密耗时${durationMs}ms，可能影响TPS") }实测数据（Intel i7-10875H, 2048位OAEP）：
| 并发数 | 平均加密耗时 | 占请求总耗时比 |
|---|---|---|
| 1 | 3.2ms | <1% |
| 100 | 4.8ms | ~2% |
| 1000 | 12.5ms | ~8% |
结论：1000并发时，RSA加密本身不会成为瓶颈，但若密钥升级到4096位，耗时将翻4倍，需提前评估。
5.4 安全加固：禁止明文密码出现在JMeter日志中
默认情况下，JMeter会把所有变量（包括password）打印到jmeter.log，存在泄露风险。必须在jmeter.properties中关闭：
# 关闭变量日志 log_level.jmeter.util.JMeterUtils=ERROR # 或更彻底：禁用所有变量日志 jmeter.save.saveservice.print_field_names=false同时，在Groovy脚本中，所有涉及明文的日志都用log.debug()而非log.info()，并在jmeter.properties中设置：
log_level.jmeter.protocol.http.sampler.HTTPSamplerBase=DEBUG log_level.jmeter.util.JMeterUtils=DEBUG然后通过-LDEBUG参数控制是否输出，生产压测时用-LINFO屏蔽敏感日志。
我在实际项目中，曾因忘记关日志，导致测试报告PDF里意外包含了管理员密码的Base64密文（虽已加密，但违反安全审计条款）。后来我们把这条写进了团队《JMeter安全红线清单》第一条：任何含密码、密钥、token的变量，禁止在INFO及以上日志级别输出。
6. 最后分享一个真实场景的扩展思路
上周帮一个医保平台做压测，他们有个特殊需求：同一账号在不同终端（APP/小程序/H5）登录，需用不同公钥加密。APP用2048位PKCS#1，小程序用2048位OAEP，H5用4096位OAEP。如果为每个终端建一套JMX，维护成本爆炸。
我的解法是：在CSV Data Set Config里，为每行用户数据增加一列client_type（值为app/mini/h5），然后Groovy脚本根据该列动态选择公钥和算法：
def clientType = vars.get("client_type") ?: "app" def keyMap = [ "app": [pem: props.get("public_key_app"), algo: "RSA/ECB/PKCS1Padding"], "mini": [pem: props.get("public_key_mini"), algo: "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"], "h5": [pem: props.get("public_key_h5"), algo: "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"] ] def config = keyMap[clientType] if (!config) throw new RuntimeException("未知client_type: ${clientType}") def publicKeyPem = config.pem def algorithm = config.algo这样，一份JMX脚本，一个CSV文件，就能模拟全渠道真实流量。上线后，他们用这套方案发现了H5端因4096位密钥导致的加密延迟毛刺——这是单测根本测不出的问题。
这个思路的本质，是把加密逻辑从“静态配置”升级为“动态策略”。它不增加JMeter复杂度，反而让测试更贴近真实业务流。如果你也在对接多端系统，不妨试试。