257 与 SET 电子交易
257 的登记名是 set，对应 Secure Electronic Transaction（安全电子交易），由 Visa 与 MasterCard 在 1990 年代联合推动。它的信任模型压在客户端：用户先在本机安装电子钱包与数字证书，交易时分别对订单信息与支付信息签名，商户与收单行按证书链逐级验证身份。规范本身设计完整，但要求卡组织、发卡行、收单行、商户与用户同时到位，部署成本高、体验也重，市场最终选择了服务端 TLS 加发卡行风控的组合，也就是后来的 3-D Secure 路线。
基本信息
| 服务名 | set（Secure Electronic Transaction） |
|---|---|
| 传输层 | TCP/UDP |
| 推动方 | Visa / MasterCard（卡组织联合规范） |
| 信任模型 | 客户端电子钱包 + 数字证书链 |
| 现状 | 被 TLS 与 3-D Secure 路线取代 |
支付安全路线对照
| 方案 | 信任模型 | 结果 |
|---|---|---|
| SET | 客户端电子钱包 + 证书链 | 部署成本高，生态未成形 |
| TLS + 支付表单 | 传输层加密 | 实现门槛低，成为行业基线 |
| 3-D Secure | 发卡行参与验证 | 兼顾风控与责任转移 |
典型使用场景
- 支付类资产核查：排查仍标注 SET 组件的历史中间件与端口
- 合规审计：说明历史支付通道的现状与替代路径，形成书面结论
- 架构对比参考：理解客户端信任与服务端信任两种模型的取舍
- 安全基线：历史支付相关端口不应保留在公网可达范围
- 变更评估：下线前确认没有对账、批量代扣等后台任务仍依赖老通道
现状核查
现状核查
sudo ss -lntup 'sport = :257' # 是否还有监听
getent services set # 系统服务名到端口的映射
sudo lsof -i :257 # 占用进程
# 历史支付中间件资产：先用流量采样确认对端与协议特征，再确认业务是否仍依赖
# 确认无依赖后按变更流程下线，不要在业务高峰直接断开SET 常被当作支付安全演进的案例：把信任压在客户端证书与电子钱包上，最终让位于服务端 TLS 与银行侧风控的组合。资产处置按历史注册项处理即可，不必为此单独保留端口。
遗留支付通道的处置顺序建议固定为：流量采样确认对端、核对业务依赖、排替换窗口、灰度下线、观察期后再关闭端口。跳过前两步容易造成对账中断这类难以立刻发现的问题。