前言:在一个app运行时期,由于android进程隔离的原因,每个应用都有自己独立的内存空间,其他应用是无法直接访问的,当然除非该APP对外提供接口,这样的话,在app运行时主要的安全隐患就在于对外的通讯上,而最主要的通讯也就是网络通讯,在网络通讯中数据从客户端发送到服务端,中间会通过多个网络节点,如何保证数据的安全需要考虑.
本章主要通过两个方面来理解https
1.一步步还原https的设计过程
2.根据设计过程来分析SSL在握手时所做的事情
在开始之前需要明白几个知识点:
1.什么是第三方网络节点?
当我们通过网络传递数据时,数据不是直接从客户端传递到服务端的,而是会经过一些网络节点,比如说路由器,代理服务器等,他们都属于网络节点.
打个简单的比方:当我们寄信件时,我就相当于客户端,而收件人就相当于服务端,中间经过的所有快递员都属于第三方的网络节点.
2.如何保证数据的安全?
保证数据的安全需要从三方面,数据内容的加密,通讯双方的身份校验,检查数据的完整性
数据内容的加密:通讯双方协定一组加密算法,所有通讯的内容通过这套算法加密后再进行传输.相当于在将信件的内容加密,从而防止快递员获取信件上的内容.
通讯双方的身份校验: 接到消息以后需要检查发送方的身份.相当于在接到信件时检查寄件人的签名,防止快递员将信件调包.
数据内容的完整性:保证数据不被篡改,就算被篡改,也可以察觉.相当于检查信件的内容是被修改,防止快递员对信件内容进行修改.
有了以上的保证,可以满足一条数据传递的安全性.
3.常用的加密算法
对称加密:AES,DES等加密算法通过一个密钥进行加密和解密,计算速度快.但如果中介人获取密钥,则整个通讯就是不安全的.
非对称加密:DES算法,生成公钥和私钥,客户端通过公钥加密,服务其通过私钥解密,同理服务端通过私钥加密,客户端通过公钥解密.好处相比与对称加密更安全,但是运算速度慢.
HASH加密算法:MD5,SHA1 加密得到一32位或者64位的值,也叫做数字指纹,这个过程是不可逆的.
有了以上的知识点,我们来通过抽象的角度来模拟还原https的设计过程.
1.为了保证数据的安全性,server端要求在发送数据包时的使用通过一套加密规则对内容进行加密,保证数据不会被泄露.
问题:服务器和客户端如果通过AES进行加密.由于客户端数量太多,如果所有的客户端对服务器都使用同一套加密方法的话,整个通讯就显得不安全了.
2.为了解决以上问题,需要服务端为每个客户端采用不同的加密规则,
问题:但是如何协商这个规则又成了问题,服务器不能直接将加密规则发送给客户端,因为这样会让中间人(网络结点获取到加密规则).中间人一样可以通过获取的加密规则破解信息.
3.这时候我们不能将加密规则继续加密,否则就会进入死循环进入鸡生蛋,蛋生鸡的问题上了.为了解决这个问题,用一套非对称加密的算法给加密规则进行加密.首先服务器为每个客户端生成一个公钥,将公钥发送给客户端,然后客户端选择一个支持的加密算法通过接受到的公钥进行加密发送给服务器,之后的通讯就按照这套加密算法来完成.这样做的好处是:即使中间人获取到了公钥,他也无法获取客户端用公钥加密的加密算法
问题:但是却由于一个问题就是中间人可以将服务器发送的公钥调包,而客户端无法辨别发送到的公钥是中间人的还是服务器的公钥,这样就造成中间人攻击的漏洞.
4.为了解决以上问题,需要解决身份校验的问题,而在HTTPS中解决身份校验问题则使用权威的第三方机构也就是CA机构向安全的服务器来颁发证书证明身份的合法性,服务器通过CA办法的证书将自己服务器的公钥加密生成一个数字证书发送给客户端,客户端接受到数字证书以后通过第三方机构的公钥将数字证书解密,获取服务器的公钥,然后继续走刚才说的上面的流程.这样就保证了这一次通讯的安全性.
这里涉及到两个问题:
4.1客户端如何得到第三方机构的公钥?
一般在浏览器和操作系统上都会存放一些权威的第三方机构的公钥.
4.2如果恶意中间人得到第三方CA机构的认证会怎么办?
如果恶意服务器获取到CA颁发的证书的话,则这个CA机构颁发的所有证书都会被视为不安全的,所以CA在颁发证书的时候一定特别小心.
5.由于CA机构的认证是收费的,所以我们也可以自己制作证书,客户端将证书的公钥放入资源文件中,在验证数字证书合法性时通过自己制作的证书,而不是通过系统提供的CA颁发的公钥,在使用自己证书的时候由于是在客户端的包下,有可能会被一些不法的网站获取后进行中间人攻击,所以需要对数字证书进行数字签名的验证,验证数字证书的方法很简单,数字证书中包含证书编号,而这个证书编号是通过服务器的网址和证书的内容通过加密算法得到的,客户端只需要通过这个加密算法对证书进行再一次的计算以后,然后与证书编号比对是否一样.这样就可以得知是否被篡改.
通过以上的了解相信大家对HTTPS的流程会有一点的了解,那么我们通过TLS/SSL建立链接时的握手过程来进一步理解https
我们都知道Http的数据都是通过明文传输的,而在HTTPS中真正起到加密的是TLS/SSL协议,而这个协议在网络分层模型处于绘画层的也就是在传输层TCP协议建立链接以后,在http协议传递数据之前.所以对于上层协议HTTP来他是无感知的.这就是网络分层模型的优点.
我们通过上面的图来分析一下SSL/TLS握手的过程
1.从蓝色部分可以看出先通过TCP协议的三次握手建立TCP/IP的链接.SSL是在TCP链接之上进行的.
2.Client Hello.:握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密算法和 SSL Version 等信息
3.ServerHello:服务器收到客户端的Hello Client请求,取出Random1以及支持的加密算法,并生成一个随机数Random2,然后从客户端支持的加密算法中选出一种,发送给客户端ServerHello.
4.Certificate:这一步是让客户端对服务器进行身份校验,服务端通过将自己的公钥通过数字证书的方式发送给客户端
5.Client Key Exchange:客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。并将PreMaster Key发送到服务端,服务端通过私钥将PreMaster Key解密获取到Random3,此时客户端和服务器都持有三个随机数Random1 Random2 Random3,双方在通过这三个随即书生成一个对称加密的密钥.双方根据这三个随即数听过相同的算法生成一个密钥,而以后应用层传输的数据都使用这套密钥进行加密.
6.Change Cipher Spec:告诉客户端以后的通讯都使用这一套密钥来进行.
以上就是一个简单的TLS/SSL握手过程.其实https就是在Http的基础上加入TLS/SSL来保证数据的安全性.
用一句话总结https的的工作方式就是:
https要使客户端与服务端通讯的安全保障,必须通过对称加密来对内容进行处理,但是在协商对称加密算法时需要用到不对称加密来保障协商过程的安全,但是非对称加密本身也是不安全的,可能会被中间人篡改公钥而进行中间人攻击,而只能通过数字证书签发机构来对非对称加密时的身份校验来保证非对称加密本身的安全性,通过这套机制来协商出一套对称加密的算法,而使http通讯时通过这套算法来对内容进行加密.
