ssl劫持问题

---

今天webview中被检测出有ssl劫持的危险。
检测的方法是：

1. app连上vpn(流量被引流到某服务器上)；
2. 在该服务器上使用抓包工具抓包（该抓包工具中内置有权威机构颁发的某ssl证书）；

• 结果：在抓包工具中能看到app中webview发给web服务器的明文请求数据；
• 原因分析：webview中只设置了检验证书，未设置检验证书持有者的common name与请求的域名是否一致
  （结合php的curl，相当于只设置了CURLOPT_SSL_VERIFYPEER未1，却设置CURLOPT_SSL_VERIFYHOST为0 （默认为2 验证common name是否有值且与当前域名相匹配））
• 解决方式，既验证ssl证书的权威性又需验证证书的common name与请求地址相匹配（自签名证书需要信任的话，结合php的curl，设置CURLOPT_CAINFO(path to Certificate Authority (CA) bundle 文件路径，默认为系统路径，文件中可以保存1个或多个用来让server验证的证书 )或CURLOPT_CAPATH (保存CA证书的目录)。(CURLOPT_SSL_VERIFYPEER为1时这两个参数才有意义））。安全要求更高的如金融机构，需进行双向认证，即client验证server ,server也要验证client（银行发给用户的U盾就是用于双向认证）结合php的curl，设置CURLOPT_SSLCERT(client端证书地址)，CURLOPT_SSLCERTPASSWD(有密码的话需要设置密码)，CURLOPT_SSLCERTTYPE(client端证书类型，默认为pem)(php的curl只支持pem格式、der、eng格式)） ^[1]
  有另外几个配置我不清楚在什么情况下需要设置：CURLOPT_SSLKEYTYPE：(私钥类型，默认为pem)，CURLOPT_SSLKEY(私钥存放路径)，CURLOPT_KEYPASSWD(私钥密码)，

由此问题，简单了解一下ssl劫持的常见方法：

参考了csdn上一篇清晰易懂的博文（点击前去）^[2]

1. 引流（ARP欺骗、DNS欺骗、浏览器数据重定向等方式）
2. • 对于使用浏览器的用户：
     • 浏览器会提示用户，该证书有问题并非权威机构颁发，但同时显示该证书在有效期内，该证书名称与用户请求的网页地址匹配，询问用户是否继续；
     • 若用户点击继续，则用户的client端与冒充真正服务器的Middleman建立了连接，Middleman能够看到并修改用户发送给Server的信息，同时也可以冒充用户向真正的Server发请求，也能看到并修改Server给用户的返回。
   • 对于webview的用户，则需要app进行相应设置，既校验证书的权威性、有效性又校验证书的name存在且与请求的地址匹配。
     可参考阿里云的一篇文章（点击前去
   • 对于 存在http跳转到https的网站，Middleman将Server返回的302状态码的response内容进行替换（主要有消息头中的location的https替换为http,并指定Middleman上一个端口如https://xxx.com替换为http://xxx.com:8081,消息体中的相关链接也进行如是替换）。这样Middleman就与client建立起http连接，与Server建立起https连接，能看到并修改用户发送的数据和服务器返回的数据。

参考文章：

---

1. 使用 curl 进行 ssl 认证 ↩

2. 分析两种实现SSL会话劫持的典型技术 ↩