移动互联网信息传输安全现状分析

信安之路

发布于 2019-08-20 14:59:45

1.4K0

发布于 2019-08-20 14:59:45

本文作者：Snjezana（信安之路移动安全小组成员）

这是 2017 年 3 月份有关移动市场的统计数据,移动 app 的数量已经突破 10 亿。移动安全也成为了一个全民关注的问题。从最初的 app 只针对功能实现，爆出来了一系列的高危漏洞之后，应运而生了包括移动 app 检测、app 加固保护等工作来保护开发者以及使用者权益。同时，http 的明文数据传输问题也得到了有效解决。我们本篇文章的讨论内容还是从数据传输过程中所引发的一系列安全问题。

数据裸奔时代

使用 HTTP 协议的数据传输方式

HyperText Transfer Protocol: 超文本传输协议，是互联网上使用最广泛的一种协议，所有 WWW 文件必须遵循的标准。HTTP 协议传输的数据都是未加密的，也就是明文的，因此使用 HTTP 协议传输隐私信息非常不安全。

使用TCP端口为：80

最初的移动app开发过程中，使用的大部分http协议来进行客户端跟服务端的通信。这个过程中传输的信息都是明文，继而引发了一系列的信息泄露等漏洞

当然上述极为不安全的数据传输，在 2015 年被大量爆出来之后，立即引起了 app 的开发人员以及使用着的重视。后续的数据传输使用了相对安全的基于 SSL/TLS 加密的安全的超文本传输协议 HTTPS。

你所使用的加密数据传输真的有保证你的数据不被窃取吗？

HTTPS 加密传输

Hyper Text Transfer Protocol over Secure Socket Layer: 安全的超文本传输协议，网景公式设计了 SSL(Secure Sockets Layer) 协议用于对 Http 协议传输的数据进行加密，保证会话过程中的安全性。

使用 TCP 端口默认为 443

SSL 协议即用到了对称加密也用到了非对称加密(公钥加密)，在建立传输链路时，SSL 首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL 对传输内容使用对称加密。

对称加密和非对称加密

对称加密: 采用单钥密码系统的加密算法，同⼀个密钥可以同时用作信息的加密和解密，这种加密方法叫做对称加密。如 DES、3DES、AES、RC2、RC4 等。

非对称加密: ⾮非对称加密算法需要两个秘钥，公钥和私钥。如 RSA 算法。

对称加密算法与非对称加密算法对比：

对称加密： 加解密效率高，算法简单，适合加密大量数据。缺点是对称加密的通信双方使用同一密钥，如果一方密钥泄露，则整个通信信息就会被破解，不安全，且密钥维护复杂。

非对称加密：公钥推不出私钥，每个用户一个非对称密钥对，一个用来加密，一个用来解密，公钥公开，私钥自己保存，不需要像对称加密那样在通信前要先同步密钥，故与对称加密相比，其安全性更好，更适合网络通信中的保密通信要求，如应用于数字签名技术。但是加密效率低。

HTTPS 单向认证机制

单向认证主要是客户端保存有服务端的公钥证书，自己本身是没有私钥证书的。

（1）给服务器生成密钥方式：

keytool -genkeypair -alias skxy -keyalg RSA -validity 3650 -keypass 123456 -storepass 123456 -keystore skxy.keystore

（2）给 Tomcat 服务器配置 Https

tomcat/config/server.xml 修改 connector 配置

<Connectorport="8443"protocol="org.apache.coyote.http11.Http11Protocol"maxThreads="150"SSLEnabled="true"scheme="https"secure="true"clientAuth="false"sslProtocol="TLS"keystoreFile="conf/skxy.keystore"keystorePass="123456"/>

（3）导出证书

keytool -export -alias skxy -file skxy.cer -keystore skxy.keystore -storepass 123456

（4）将证书放在 android 客户端，能够读取的地方比如 assert 目录

（5）代码中执行网络请求，获取证书，读取 https 网站的数据

客户端单向认证代码实现部分

Stringpath="https://10.0.3.2:8443/Test/Hlloer";
  try{  
      //获取证书  
      InputStreamstream=getAssets().open("skxy.cer");  
      SSLContexttls=SSLContext.getInstance("TLS");  
      //使用默认证书  
      KeyStorekeystore=KeyStore.getInstance(KeyStore.getDefaultType());  
      //去掉系统默认证书  
      keystore.load(null);  
      Certificatecertificate= 
              CertificateFactory.getInstance("X.509").generateCertificate(stream);  
      //设置自己的证书  
      keystore.setCertificateEntry("skxy", certificate);  
      //通过信任管理器获取一个默认的算法  
      Stringalgorithm=TrustManagerFactory.getDefaultAlgorithm();  
      ……
      URLurl=newURL(path);  
      HttpsURLConnectionconn=(HttpsURLConnection) url.openConnection();  
      //设置ip授权认证：如果已经安装该证书，可以不设置，否则需要设置  
      conn.setHostnameVerifier(newHostnameVerifier() {  
          @Override 
          publicbooleanverify(Stringhostname, SSLSessionsession) {  
              returntrue;  
          }  
      });  
……

单向认证过程：

HTTPS 双向认证机制

首先对于双向证书验证，也就是说，客户端有自己的密钥，并持有服务端的证书，服务端给客户端发送数据时，需要将服务端的证书发给客户端验证，验证通过才运行发送数据，同样，客户端请求服务器数据时，也需要将自己的证书发给服务端验证，通过才允许执行请求。

双向认证过程：

我们身边的 app 中所使用的加密传输是怎样的呢？

某宝（金融类 app）的数据加密分析（https 单向认证）为了更加清晰的了解 https 在实际项目中的应用，特意花了点时间分析了一个 app 的加密认证过程。app 虽然加了部分混淆，但并没有加固，所以也不难分析。

（1）整个发送 https post 请求过程, ip 以及域名都是固定的，证书也写死在 app 里。

（2）https 认证过程

判断代理服务器以及证书校验

证书校验过程

在获取证书的过程中，仅仅读取了证书的信息，并没有实现校验证书是否安全可靠的代码。这里就留下了安全隐患。使用第三方证书一样可以截获数据。

数据解密过程

在数据解密过程也不够严谨，密钥和向量通过简单逆向分析就能获得

解密 key 的获取方式：数据包名的 md5

解密向量

通过这个简单分析，你还敢说你的数据是安全传输的吗？

安全隐患

因为开发方便而信任所有证书

手机银行开发人员在开发过程中为了解决 ssl 证书报错的问题（使用了自己生成的证书后，客户端发现证书无法与系统可信根 CA 形成信任链，出现了 CerException 等异常。）会在客户端代码中信任客户端中所有证书的方式。

而在客户端中覆盖 Google 默认的证书检查机制（X509TrustManager），并在代码中无任何验证 SSL 证书有效性相关代码：

重写了校验机制，但并没有做任何检验SSL证书有效性。

中间人攻击

在密码学和计算机安全领域中，中间人攻击（ Man-in-the-middle attack，通常缩写为 MITM ）是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。简单讲，MiTM 攻击就是现代版的窃听。

分类: 针对 SSL 的中间人攻击方式主要有两类，分别是 SSL 劫持攻击和 SSL 剥离攻击。

（1）SSL 劫持攻击

SSL 劫持攻击即 SSL 证书欺骗攻击，攻击者为了获得 HTTPS 传输的明文数据，需要先将自己接入到客户端和目标网站之间；在传输过程中伪造服务器的证书，将服务器的公钥替换成自己的公钥，这样，中间人就可以得到明文传输带 Key1、Key2 和 Pre-Master-Key，从而窃取客户端和服务端的通信数据；

但是对于客户端来说，如果中间人伪造了证书，在校验证书过程中会提示证书错误，由用户选择继续操作还是返回，由于大多数用户的安全意识不强，会选择继续操作，此时，中间人就可以获取浏览器和服务器之间的通信数据。

（2）SSL 剥离攻击

这种攻击方式也需要将攻击者设置为中间人，之后见 HTTPS 范文替换为 HTTP 返回给浏览器，而中间人和服务器之间仍然保持 HTTPS 服务器。由于 HTTP 是明文传输的，所以中间人可以获取客户端和服务器传输数据

危害, HTTPS 中间人攻击漏洞源于：

没有对 SSL 证书进行校验；

1、没有对域名进行校验；

2、证书颁发机构 (Certification Authority) 被攻击导致私钥泄露等。攻击者可通过中间人攻击，盗取账户密码明文、聊天内容、通讯地址、电话号码以及信用卡支付信息等敏感信息，甚至通过中间人劫持将原有信息替换成恶意链接或恶意代码程序，以达到远程控制、恶意扣费等攻击意图。

扩展 Java Security 安全体系知识延伸

Java Security 背景知识

Java Security 其实是 Java 平台中一个比较独立的模块。除了软件实现上内容外，它实际上对应了一系列的规范。从 Java2 开始，Java Security 包含主要三个重要的规范：

1、JavaCryptography Extension（简写为 JCE），JCE 所包含的内容有加解密，密钥交换，消息摘要（Message Digest，比如 MD5 等），密钥管理等。本文所涉及的大部分内容都属于 JCE 的范畴。

2、JavaSecure Socket Extension（简写为 JSSE），JSSE 所包含的内容就是 Java 层的 SSL/TLS。简单点说，使用 JSSE 就可以创建 SSL/TLS socket 了。

3、JavaAuthentication and Authorization Service（简写为 JAAS），JSSA 和认证/授权有关。这部分内容在客户端接触得会比较少一点，所以本文不拟讨论它。

在上述三个子模块或规范中，JCE 是 JavaSecurity 的大头，其他两个子模块 JSSE 和 JAAS 都依赖于它，比如 SSL/TLS 在工作过程中需要使用密钥对数据进行加解密，那么密钥的创建和使用就依靠 JCE 子模块了。另外，既然和安全相关，那么对安全敏感的相关部门或政府肯定会有所干涉。Java 是在美国被发明的，所以美国政府对于 Java Security 方面的出口（比如哪些模块，哪些功能能给其他国家使用）有相关的限制。例如，不允许出口的 JCE（从软件实现上看，可能就是从 Java 官网上下载到的几个 Jar 包文件）支持一些高级的加解密功能（比如在密钥长度等方面有所限制）。

JCE 的介绍

JCE 最初是作为 JCA 的扩展包开发的，旨在提供受美国出口控制条例管制的加密服务 API 和实现。JCE 提供一个提供者实现和一组相关的 API 和包，以支持加密和解密，密钥的生成和协商以及消息验证算法，其中对加密和解密的支持包括对称加密、非对称加密、块加密和流加密。JCE还支持安全流和封装流对象。

JCE的架构模型如下图所示：

issue

1、不要忽略证书校验

2、保护好自己的密钥

3、尽量使用规范的 https 协议

参考

http://blog.csdn.net/xdd19910505/article/details/51926540
https://www.cnblogs.com/xiekeli/p/5607107.html
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2014/0607/1621.html
https://www.waitalone.cn/bank-ssl-cap.html

本文参与腾讯云自媒体分享计划，分享自微信公众号。

原始发表：2018-09-14，如有侵权请联系 cloudcommunity@tencent.com 删除

SSL 证书