Android HTTPS导读
概述：在客户端和服务器之间协商出一套对称秘钥，每次发送信息之前将内容加密，收到之后解密，达到内容的加密传输。
写这篇的目的，本来是想研究 Android 的签名机制，其中涉及到数字签名和数字证书，于是索性把 HTTPS 也研究下。
本文主要是对其他文章的一个理解注释。
对称加密
非对称加密
消息摘要
数字签名
数字证书
以上这几个概念需要提前理解，可参考这几篇文章：Android安全加密专题 ，Android 应用程序签名过程分析
正文
为什么需要 https？客户端与服务器之间通过 http 协议传输数据，这本身没问题，但是网络环境不是安全可靠的，总会有不法分子想要窃取篡改数据。那么如何防止这种情况呢？我们第一想法把数据加密起来，这样别人就看不懂了。那么怎样的加密是安全的呢，我们不管，有高人会。他们的做法就是 https，https 是什么？http 是一个应用层协议，会把要发送的消息交给 TCP 传输层，将消息可靠的交付出去。这个时候我们想把应用层的数据进行加密后再传输，怎么做？简单，再加一层协议好了，于是这一层叫 TLS（Transport Layer Security 传输层安全），这一层是在应用层和传输层之间的。这样子 https 就出来了。
确保可靠通信的原则
确定消息的来源确实是其申明的那个人。
保证信息在传递过程中不被篡改，即使被篡改了，也可以发觉出来。
那么 TLS 层是怎么进行加密的？
在客户端和服务器之间协商出一套对称秘钥，每次发送信息之前将内容加密，收到之后解密，达到内容的加密传输。
也就是说是通过对称加密来实现的，那这个对称秘钥怎么保证安全呢？
在客户端与服务器通过非对称加密交换秘钥。
非对称加密中，接收方如何保证公钥的正确性呢？
通过 数字签名 + 数字证书。
Android 安全加密：数字签名和数字证书 在这篇文章中 签名过程 那个图，可以很好的理解数字签名到底是怎么回事的。
“发送报文时，发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己的私钥对这个摘要进行加密，这个加密后的摘要将作为报文的数字签名和报文一起发送给接收方，接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要，接着再用发送方的公钥来对报文附加的数字签名进行解密，如果这两个摘要相同、那么接收方就能确认该数字签名是发送方的。
数字签名有两种功效：一是能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。二是数字签名能确定消息的完整性。因为数字签名的特点是它代表了文件的特征，文件如果发生改变，数字摘要的值也将发生变化。不同的文件将得到不同的数字摘要。一次数字签名涉及到一个哈希函数、发送者的公钥、发送者的私钥。”
问题：在发送过程中，被第三方攻击者拦截了怎么办。攻击者能干嘛？接收方如何通过数字签名校验是否被拦截了。
攻击者直接修改消息（明文）。由于有数字签名的存在，接收方最后计算出的 Hash 值肯定与发送方的不一致，因此接收方可以判断出消息有问题。
攻击者直接修改签名。接收方用发送方的公钥肯定解不开，因此也能判断。
攻击者修改消息（明文），然后利用自己的私钥做签名，同时把自己的公钥给接收方。这时接收方无法判断出消息有问题了。
由此可见，在数字签名这种机制中，最重要的一件事就是接收方必须持有正确的公钥，否则一切白搭。
那么如何保证呢？数字证书
数字证书也用到了数字签名的技术，只不过要签名的内容是发送方的公钥。发送方通过把自己的公钥进行数字签名发送给接收方，这样可以防止第三方修改发送方公钥。那么谁来对这个公钥进行签名呢？CA。CA 用自己的私钥对发送方的公钥进行签名，那么接收方需要 CA 的公钥来对这个数字证书进行验证。 又回到了公钥的问题上，CA 的公钥哪来呢？一般来说，CA 的根证书已经在设备出厂前预先就安装到你的设备上了的。所以这就保证了 CA 的公钥是正确的。
由此我们可以知道数字签名+数字证书可以保证 发送方的身份以及发送方所发数据的完整性。而数字签名中又用到了非对称加密以及消息摘要。
因此我们可以保证公钥能够被正确的发送到客户端手中。
为什么不全程使用非对称加密？
非对称加密由于使用了复杂的数学原理，因此计算相当复杂，如果完全使用非对称加密来加密通信内容，会严重影响网络通信的性能。
