xingliuhua
文章 标签 分类
xingliuhua

目录

HTTPS

xingliuhua 收录于 笔记
   约 4007 字   预计阅读 8 分钟 

为什么要有https

  1. http是明文，容易被监听拦截。
  2. 加密呗，用对称加密，秘钥传输的时候明文传输，会被监听拦截。
  3. 可以使用非对称加密，但是非对称加密过程慢，可以采用非对称+对称加密组合的方式，即用非对称加密方式来协商对称加密秘钥。 具体是这样子的： 服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全着得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。 最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。如图：

./pic1.png

毫无疑问，在这个过程中，中间人获取了对称加密中的密钥，在之后服务器和客户端的对称加密传输中，这些加密的数据对中间人来说，和明文没啥区别。 4. 非对称加密之所以不安全，是因为客户端不确定这个公钥是来自正确的服务器，解决了这个问题就好办了。数字证书登场。 5. 我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。 服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。如图

./pic2.png

并且，最后还会把原来没Hash算法之前的个人信息以及公钥 和 数字签名合并在一起，形成数字证书。如图

./pic3.png

  1. 当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。如图：

./pic4.png

什么是https

https简单来说就是https = http + ssl(tls)

./1538991377849.png

这样，http在到达tcp层之前就加密一次 简单一句话就是：https先利用非对称加密（RSA等）来协商对称秘钥，后续就用对称加密算法（AES等）来加密传输。

数字证书

服务端如果直接把公钥明文传输给客户端，容易被中间人接收。客户端必须知道接收的公钥是合法的。为了解决这个问题，把公钥告诉权威机构，来生成数字证书以便客户端验证。 验证证书的过程如下：

./1538992031195.png

通过 HTTPS 建立了一个安全 Web 事务之后，现代的浏览器都会自动获取所连接服 务器的数字证书。如果服务器没有证书，安全连接就会失败。

浏览器收到证书时会对签名颁发机构进行检查。如果这个机构是个很有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装很多签名颁发机构的证书)。

如果对签名颁发机构一无所知，浏览器就无法确定是否应该信任这个签名颁发机构， 它通常会向用户显示一个对话框，看看他是否相信这个签名发布者。签名发布者可 能是本地的 IT 部门或软件厂商。

数字证书校验一般是校验公钥是否正确，域名、有效期和是否被吊销等。 具体的证书生成及验证流程：

  1. CA 把有效日期，服务端公钥等基础信息hash取数据摘要，并对摘要进行CA私钥加密生成数字签名，签名和基础信息一同组成数字证书。
  2. 客户端一般有知名的CA公钥，先判断是否有对应的CA公钥，如果没有直接弹框不信任。如果有则对证书的签名进行CA公钥解密，然后按照和CA相同的hash方法对基础信息取得摘要，摘要和CA公钥解密的结果对比发现是一致的，则说明数据没有篡改过，顺利取得了服务端的公钥。这个方法很巧妙，即获得了公钥，而且还知道公钥是靠谱的。

数字签名

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。 数字签名的过程如下： 明文 –> hash运算 –> 摘要 –> 私钥加密 –> 数字签名

数字签名有两种功效： 一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。 二、数字签名能确定消息的完整性。

注意： 数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

ca数字证书

我们知道了服务端端的数字证书是来自ca的。验证服务端证书的时候需要用ca的公钥进行解密，然后校验。 怎么知道ca的公钥是安全的，不是伪造的？

世界上的CA认证中心不止一家，

./2009010823213641.jpg

CA认证中心之间是一个树状结构，根CA认证中心可以授权多个二级的CA认证中心，同理二级CA认证中心也可以授权多个3级的CA认证中心…如果你是数字证书申请人(比如说：交通银行)，你可以向根CA认证中心，或者二级，三级的CA认证中心申请数字证书，这是没有限制的，当你成功申请后，你就称为了数字证书所有人。值得注意的是，根CA认证中心是有多个的，也就是说会有多棵这样的结构树。

实际上每个CA认证中心/数字证书所有人，他们都有一个数字证书，和属于自己的RSA公钥和密钥，这些是他们的父CA认证中心给他们颁发的。

CA的数字证书和服务端的数字证书差不多，上一级Ca的秘钥对Hash(自己的ca信息)的结果进行加密。校验的时候需要上一级的公钥来解密，以此来验证该ca的证书是真的，那上一级的公钥怎么保证是安全的呢？就要再找上上一级的公钥，这样递归了，直到找到根证书，那根证书怎么保证呢，一般操作系统中都内置了根证书。

SSL握手流程

./1538992510114.png

握手阶段分成五步。

第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。

第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。

第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。

第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。

第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

注意： 整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。

服务端对客户端验证

对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

抓包原理

HTTPS即使安全，也是能够被抓包的，常见的抓包工具有：Charles、fildder等。 常用的HTTPS抓包方式是作为中间人，对客户端伪装成服务端，对服务端伪装成客户端。简单来说：

截获客户端的HTTPS请求，伪装成中间人客户端去向服务端发送HTTPS请求 接受服务端返回，用自己的证书伪装成中间人服务端向客户端发送数据内容。

具体过程如下图所示： ./169c44ac0ae69a06.jpg

反抓包策略

为了防止中间人攻击，可以使用SSL-Pinning的技术来反抓包。 可以发现中间人攻击的要点的伪造了一个假的服务端证书给了客户端，客户端误以为真。解决思路就是，客户端也预置一份服务端的证书，比较一下就知道真假了。 SSL-pinning有两种方式： 证书锁定（Certificate Pinning） 和公钥锁定（ Public Key Pinning）。

  • 证书锁定 需要在客户端代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的CA根证书对应的任何证书，通过这种授权方式，保障了APP与服务端通信的唯一性和安全性，因此客户端与服务端（例如API网关）之间的通信是可以保证绝对安全。但是CA签发证书都存在有效期问题，缺点是在 证书续期后需要将证书重新内置到APP中。
  • 公钥锁定 提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性。制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题，一般推荐这种做法。

没有绝对的安全，这不能挡住逆向反编译。

问题

  1. HTTPS和HTTP的区别 https协议需要到CA申请证书。 http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。 http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。 http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

  2. 抓包 Q: 使用 HTTPS 会被抓包吗？ A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。 我们使用抓包工具的第一步就是在你自己设备中信任 Charles 的 CA 证书，在自己的设备中添加了一个 CA，请求的时候，Charles 通过自己的 CA 签名了一个自己的公钥，发送给客户端，客户端就误以为是服务器了，这样之后的流程都会先走到 Charles 然后才会走到目标服务器。 Charles 扮演了一个中间人的角色，而且这个中间人是我们自己设置的。 因此要想防止抓包，应用应该自己做处理。

  3. 为什么一定要用三个随机数来生成”会话密钥”呢？ 机器产生的随机数也许是一个范围的伪随机数，容易被猜到破解，如果随机数不随机，那么premaster secret就有可能被猜出来，那么仅适用premaster secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上premaster secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机数可能完全不随机，可是三个伪随机数就十分接近随机了。

参考资料： http://www.wxtlife.com/2016/03/27/%E8%AF%A6%E8%A7%A3https%E6%98%AF%E5%A6%82%E4%BD%95%E7%A1%AE%E4%BF%9D%E5%AE%89%E5%85%A8%E7%9A%84%EF%BC%9F/ https://mp.weixin.qq.com/s?__biz=Mzg2NzA4MTkxNQ==&mid=2247485216&idx=1&sn=fd119ae8e9d184a81cc1dd2984e8d4b8&scene=21#wechat_redirect

更新于 2017-01-01
 网络
返回 | 主页