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

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

1. 数据裸奔时代

=========

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

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

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

wireshark简单捕获就能看到明文隐私数据

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

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

=============================

2.1. https加密传输

---

• Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。 使用TCP端口默认为443
• SSL协议即用到了对称加密也用到了非对称加密(公钥加密)，在建立传输链路时，SSL首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL对传输内容使用对称加密。

2.1.1. 对称加密和非对称加密

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

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

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

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

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

2.1.2.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配置

<Connector port="8443" proto-col="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLE-nabled="true" scheme="https" secure="true" clientAuth="false" sslPro-tocol="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网站的数据

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

String path = "https://10.0.3.2:8443/Test/Hlloer";

   try {  
       //获取证书  
       InputStream stream = getAssets().open("skxy.cer");  

       SSLContext tls = SSLContext.getInstance("TLS");  
       //使用默认证书  
       Key-Store keystore = KeyStore.getInstance(KeyStore.getDefaultType());  
       //去掉系统默认证书  
       keystore.load(null);  
       Certificate certificate =  
               CertificateFacto-ry.getInstance("X.509").generateCertificate(stream);  
       //设置自己的证书  
       keystore.setCertificateEntry("skxy", certificate);  
       //通过信任管理器获取一个默认的算法  
       String algorithm = TrustManagerFactory.getDefaultAlgorithm();  
       ……
       URL url = new URL(path);  
       HttpsURLConnec-tion conn = (HttpsURLConnection) url.openConnection();  
       //设置ip授权认证：如果已经安装该证书，可以不设置，否则需要设置  
       conn.setHostnameVerifier(new HostnameVerifier() {  
           @Override  
           public boolean verify(String hostname, SSLSession session) {  
               return true;  
           }  
       });  
……

单向认证过程：

2.1.2 Https双向认证机制

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

双向认证过程：

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

---

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

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

（2）https认证过程

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

• 证书校验过程

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

• 数据解密过程

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

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

• 解密向量
  

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

2.3. 安全隐患

---

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

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

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

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

2.3.3 中间人攻击

• 原理。在密码学和计算机安全领域中，中间人攻击 （ 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证书进行校验；

  ②没有对域名进行校验；

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

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

===========================

3.1. Java Security 背景知识

---

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

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

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

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

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

3.2. JCE的介绍

---

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

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

4. issue

========

• 不要忽略证书校验
• 保护好自己的密钥
• 尽量使用规范的https协议

5. 参考

=====

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

微信公众号文章地址链接：
https://mp.weixin.qq.com/s/CdeePQh1j9SKtnKEKVqycA
欢迎大家沟通交流，也可以点赞打赏，以资鼓励。哈哈，谢谢。继续加油。