【刷题】面筋-网络-HTTPS抓包原理与charles抓包步骤

http为何不安全？

• http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通讯双方也没有进行任何认证，通讯过程很是容易遭遇劫持、监听、篡改，严重状况下，会形成恶意的流量劫持等问题，甚至形成我的隐私泄露（好比银行卡卡号和密码泄露）等严重的安全问题。

• 能够把http通讯比喻成寄送信件同样，A给B寄信，信件在寄送过程当中，会通过不少的邮递员之手，他们能够拆开信读取里面的内容（由于http是明文传输的）。A的信件里面的任何内容（包括各种帐号和密码）都会被轻易窃取。除此以外，邮递员们还能够伪造或者修改信件的内容，致使B接收到的信件内容是假的。

• 好比常见的，在http通讯过程当中，“中间人”将广告连接嵌入到服务器发给用户的http报文里，致使用户界面出现不少不良连接； 或者是修改用户的请求头URL，致使用户的请求被劫持到另一个网站，用户的请求永远到不了真正的服务器。这些都会致使用户得不到正确的服务，甚至是损失惨重。

https如何保证安全？

• 引入对称加密和非对称加密

  • 要解决http带来的问题，就要引入加密以及身份验证机制。

  • 若是Server（之后简称服务器）给Client（之后简称 客户端）的消息是密文的，只有服务器和客户端才能读懂，就能够保证数据的保密性。同时，在交换数据以前，验证一下对方的合法身份，就能够保证通讯双方的安全。那么，问题来了，服务器把数据加密后，客户端如何读懂这些数据呢？这时服务器必需要把加密的密钥（对称密钥，后面会详细说明）告诉客户端，客户端才能利用对称密钥解开密文的内容。可是，服务器若是将这个对称密钥以明文的方式给客户端，仍是会被中间人截获，中间人也会知道对称密钥，依然没法保证通讯的保密性。可是，若是服务器以密文的方式将对称密钥发给客户端，客户端又如何解开这个密文，获得其中的对称密钥呢？

  • 说到这里，你们是否是有点儿糊涂了？一下子密钥，一下子对称密钥，都有点儿被搞晕的节奏。在这里，提早给你们普及一下，这里的密钥，指的是非对称加解密的密钥，是用于TLS握手阶段的； 对称密钥，指的是对称加解密的密钥，是用于后续传输数据加解密的。下面将详细说明。

  • 这时，咱们引入了非对称加解密的概念。在非对称加解密算法里，公钥加密的数据，有且只有惟一的私钥才可以解密，因此服务器只要把公钥发给客户端，客户端就能够用这个公钥来加密进行数据传输的对称密钥。客户端利用公钥将对称密钥发给服务器时，即便中间人截取了信息，也没法解密，由于私钥只部署在服务器，其余任何人都没有私钥，所以，只有服务器才可以解密。服务器拿到客户端的信息并用私钥解密以后，就能够拿到加解密数据用的对称密钥，经过这个对称密钥来进行后续通讯的数据加解密。除此以外，非对称加密能够很好的管理对称密钥，保证每次数据加密的对称密钥都是不相同的，这样子的话，即便客户端病毒拉取到通讯缓存信息，也没法窃取正常通讯内容。

• 小结：

  • 服务器把公钥发给客户端
  • 客户端用这个公钥来加密进行数据传输的对称密钥。
    • 客户端利用公钥将对称密钥发给服务器时，即便中间人截取了信息，也没法解密，由于私钥只部署在服务器，其余任何人都没有私钥，所以，只有服务器才可以解密。
  • 服务器拿到客户端的信息并用私钥解密以后，就能够拿到加解密数据用的对称密钥，经过这个对称密钥来进行后续通讯的数据加解密。
  • 后续传输数据时可用前几步的对称密钥来进行加解密。

• 引入数字证书

  • 可是这样彷佛还不够，若是通讯过程当中，在三次握手或者客户端发起HTTP请求过程当中，客户端的请求被中间人劫持，那么中间人就能够假装成“假冒客户端”和服务器通讯；中间人又能够假装成“假冒服务器”和客户端通讯。接下来，咱们详细阐述中间人获取对称密钥的过程：

  • 中间人在收到服务器发送给客户端的公钥（这里是“正确的公钥”）后，并无发给客户端，而是中间人将本身的公钥（这里中间人也会有一对公钥和私钥，这里称呼为“伪造公钥”）发给客户端。以后，客户端把对称密钥用这个“伪造公钥”加密后，发送过程当中通过了中间人，中间人就能够用本身的私钥解密数据并拿到对称密钥，此时中间人再把对称密钥用“正确的公钥”加密发回给服务器。此时，客户端、中间人、服务器都拥有了同样的对称密钥，后续客户端和服务器的全部加密数据，中间人均可以经过对称密钥解密出来。

  • 为了解决此问题，咱们引入了数字证书的概念。服务器首先生成公私钥，将公钥提供给相关机构（CA），CA将公钥放入数字证书并将数字证书颁布给服务器，此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书，数字证书中加入了一些数字签名的机制，保证了数字证书必定是服务器给客户端的。中间人发送的伪造证书，不可以得到CA的认证，此时，客户端和服务器就知道通讯被劫持了。

• 小结：

  • 非对称加密算法（公钥和私钥）交换对称密钥+数字证书验证身份（验证公钥是不是伪造的）+利用对称密钥加解密后续传输的数据=安全

对称加密算法

• 概述

  • 对称加密是指：加密和解密使用相同密钥的算法。
  • 它要求发送方和接收方在安全通讯以前，商定一个对称密钥。
  • 对称算法的安全性彻底依赖于密钥，密钥泄漏就意味着任何人均可以对他们发送或接收的消息解密，因此密钥的保密性对通讯相当重要。

• 对称加密又分为两种模式：流加密和分组加密

  • 流加密是将消息做为字节流对待，而且使用数学函数分别做用在每个字节位上。使用流加密时，每加密一次，相同的明文位会转换成不一样的密文位。流加密使用了密钥流生成器，它生成的字节流与明文字节流进行异或，从而生成密文。

  • 分组加密是将消息划分为若干个分组，这些分组随后会经过数学函数进行处理，每次一个分组。假设使用64位的分组密码，此时若是消息长度为640位，就会被划分红10个64位的分组（若是最后一个分组长度不到64，则用0补齐以后加到64位），每一个分组都用一系列数学公式进行处理，最后获得10个加密文本分组。而后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终获得明文消息。比较经常使用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，如今已经被证实不安全。而3DES是一个过渡的加密算法，至关于在DES基础上进行三重运算来提升安全性，但其本质上仍是和DES算法一致。而AES是DES算法的替代算法，是如今最安全的对称加密算法之一。

• 对称加密算法的优缺点：

  • 优势：计算量小、加密速度快、加密效率高。

  • 缺点：

    • （1）交易双方都使用一样密钥，安全性得不到保证；
    • （2）每次使用对称加密算法时，都须要使用其余人不知道的唯一密钥，这会使得发收信息双方所拥有的钥匙数量呈几何级数增加，密钥管理成为负担。

非对称加密算法那

• 非对称加密算法

  • 在非对称密钥交换算法出现之前，对称加密的最主要缺陷就是不知道如何在通讯双方之间传输对称密钥，而又不让中间人窃取。非对称密钥交换算法诞生以后，专门针对对称密钥传输作加解密，使得对称密钥的交互传输变得很是安全了。

  • 非对称密钥交换算法自己很是复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等等一系列极其复杂的过程，。常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题。其中，最经典也是最经常使用的是RSA算法。

  • RSA：诞生于1977年，通过了长时间的破解测试，算法安全性很高，最重要的是，算法实现很是简单。缺点就是须要比较大的质数（目前经常使用的是2048位）来保证安全强度，极其消耗CPU运算资源。RSA是目前惟一一个既能用于密钥交换又能用于证书签名的算法，RSA 是最经典，同时也是最经常使用的是非对称加解密算法。

• 非对称加密相比对称加密更加安全，但也存在两个致命的缺点：

  • （1）CPU计算资源消耗很是大。一次彻底TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只至关于非对称加密的0.1%。若是后续的应用层数据传输过程也使用非对称加解密，那么CPU性能开销太庞大，服务器是根本没法承受的。赛门特克给出的实验数据显示，加解密同等数量的文件，非对称算法消耗的CPU资源是对称算法的1000倍以上。

  • （2）非对称加密算法对加密内容的长度有限制，不能超过公钥长度。好比如今经常使用的公钥长度是2048位，意味着待加密内容不能超过256个字节。

  • 因此非对称加解密（极端消耗CPU资源）目前只能用来做对称密钥交换或者CA签名，不适合用来作应用层内容传输的加解密。

身份认证

• 概述

  • https协议中身份认证的部分是由CA数字证书完成的，证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证（验证这张证书是不是伪造的？也就是公钥是不是伪造的），若是证书不是伪造的，客户端就获取用于对称密钥交换的非对称密钥（获取公钥）。

• 数字证书有三个做用：

  • 一、身份受权。确保浏览器访问的网站是通过CA验证的可信任的网站。
  • 二、分发公钥。每一个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥）。在SSL握手时会经过certificate消息传输给客户端。
  • 三、验证证书合法性。客户端接收到数字证书后，会对证书合法性进行验证。只有验证经过后的证书，才可以进行后续通讯过程。

• 申请一个受信任的CA数字证书一般有以下流程：

  • （1）公司（实体）的服务器生成公钥和私钥，以及CA数字证书请求。
  • （2）RA（证书注册及审核机构）检查实体的合法性（在注册系统里面是否注册过的正规公司）。
  • （3）CA（证书签发机构）签发证书，发送给申请者实体。
  • （4）证书更新到repository（负责数字证书及CRL内容存储和分发），实体终端后续从repository更新证书，查询证书状态等。

• 数字证书验证

  • 申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手并接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最普遍的SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）。数字签名的制做和验证过程以下：
  • 一、数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，而后使用CA本身的私钥对消息摘要进行加密。
  • 二、数字签名的校验。使用CA的公钥解密签名，而后使用相同的签名函数对签名证书内容进行签名，并和服务端数字签名里的签名内容进行比较，若是相同就认为校验成功。
  • 须要注意的是：
    • （1）数字签名签发和校验使用的非对称密钥是CA本身的公钥和私钥，跟证书申请者（提交证书申请的公司实体）提交的公钥没有任何关系。
    • （2）数字签名的签发过程跟公钥加密的过程恰好相反，便是用私钥加密，公钥解密。（一对公钥和私钥，公钥加密的内容只有私钥可以解密；反过来，私钥加密的内容，也就有公钥才可以解密）
    • （3）如今大的CA都会有证书链，证书链的好处：首先是安全，保持CA的私钥离线使用。第二个好处是方便部署和撤销。这里为啥要撤销呢？由于，若是CA数字证书出现问题（被篡改或者污染），只须要撤销相应级别的证书，根证书依然是安全的。
    • （4）根CA证书都是自签名，即用本身的公钥和私钥完成了签名的制做和验证。而证书链上的证书签名都是使用上一级证书的非对称密钥进行签名和验证的。
    • （5）怎样获取根CA和多级CA的密钥对？还有，既然是自签名和自认证，那么它们是否安全可信？这里的答案是：固然可信，由于这些厂商跟浏览器和操做系统都有合做，它们的根公钥都默认装到了浏览器或者操做系统环境里。

数据完整性验证

• 数据传输过程当中的完整性使用MAC算法来保证。为了不网络中传输的数据被非法篡改，或者数据比特被污染，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性（因为MD5在实际应用中存在冲突的可能性比较大，因此尽可能别采用MD5来验证内容一致性）。 MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的做用下，利用MAC算法计算出消息的MAC值，并将其添加在须要发送的消息以后，并发送给接收者。接收者利用一样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。若是两者相同，则报文没有改变；不然，报文在传输过程当中被修改或者污染，接收者将丢弃该报文。 SHA也不能使用SHA0和SHA1，山东大学的王小云教授（很牛的一个女教授，你们有兴趣能够上网搜索一下她的事迹）在2005年就宣布破解了 SHA-1完整版算法，并得到了业内专家的承认。微软和google都已经宣布16年及17年以后再也不支持sha1签名证书。

https 通讯流程

• 一、客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其余服务器和客户端之间通信所须要的各类信息。

• 二、服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其余相关信息，同时服务器还将向客户端传送本身的证书。

• 三、客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过时，发行服务器证书的CA 是否可靠，发行者证书的公钥可否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。若是合法性验证没有经过，通信将断开；若是合法性验证经过，将继续进行第四步。

• 四、用户端随机产生一个用于后面通信的“对称密码”，而后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中得到）对其加密，而后将加密后的“预主密码”传给服务器。

  • 4.一、若是服务器要求客户的身份认证（在握手过程当中为可选），用户能够创建一个随机数而后对其进行数据签名，将这个含有签名的随机数和客户本身的证书以及加密过的“预主密码”一块儿传给服务器。
  • 4.二、若是服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥可否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验若是没有经过，通信马上中断；若是验证经过，服务器将用本身的私钥解开加密的“预主密码”，而后执行一系列步骤来产生主通信密码（客户端也将经过一样的方法产生相同的主通信密码）。

• 五、服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL 协议的安全数据通信的加解密通信。同时在SSL 通信过程当中还要完成数据通信的完整性，防止数据通信中的任何变化。

• 六、服务器向客户端发出信息，指明后面的数据通信将使用的步骤5中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

• 七、SSL 的握手部分结束，SSL 安全通道的数据通信开始，客户和服务器开始使用相同的对称密钥进行数据通信，同时进行通信完整性的检验。

charles抓包原理

• 客户端向服务器发起HTTPS请求

• Charles拦截客户端的请求，假装成客户端向服务器进行请求

• 服务器向“客户端”（其实是Charles）返回服务器的CA证书

• Charles拦截服务器的响应，获取服务器证书公钥，而后本身制做一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥）

• 客户端接收到“服务器”（其实是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）

• Charles拦截客户端的响应，用本身的私钥解密对称密钥，而后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥）

• 服务器用本身的私钥解密对称密钥，向“客户端”（Charles）发送响应

• Charles拦截服务器的响应，替换成本身的证书后发送给客户端

• 至此，链接创建，Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥，以后就能够解密或者修改加密的报文了。

• HTTPS抓包的原理仍是挺简单的，简单来讲，就是Charles做为“中间人代理”，拿到了 服务器证书公钥 和 HTTPS链接的对称密钥，前提是客户端选择信任并安装Charles的CA证书，不然客户端就会“报警”并停止链接。这样看来，HTTPS仍是很安全的。

charles抓包过程

• 一、安装抓包工具charles

• 二、在电脑安装证书
  
  

• 三、查看IP地址和端口
  

• 四、手机wifi配置电脑代理地址和端口（注意：电脑的IP地址与手机WIFI所链接的须要在同一局域网，否则会链接不上）
  

• 五、手机浏览器输入网址http://chls.pro/ssl网址下载charles证书

• 六、就能够开始抓包了

• 七、若是还不能抓包，把电脑防火墙关闭试一下看看，若是还不行，根据问题百度

参考连接

• https协议 和 Charles 进行https抓包原理
• charles抓包步骤整理
• Charles的HTTPS抓包方法及原理分析
• HTTPS抓包分析

END