https通信原理

作用

不使用 SSL/TLS 的 HTTP 通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

• 窃听风险（eavesdropping）：第三方可以获知通信内容。
• 篡改风险（tampering）：第三方可以修改通信内容。
• 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS 协议是为了解决这三大风险而设计的，希望达到：

• 所有信息都是加密传播，第三方无法窃听。
• 具有校验机制，一旦被篡改，通信双方会立刻发现。
• 配备身份证书，防止身份被冒充。

基本的运行过程

SSL/TLS 协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

• 如何保证公钥不被篡改
  解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

• 公钥加密计算量太大，如何减少耗用的时间
  解决方法：每一次对话（session），客户端和服务器端都生成一个对话密钥（session key），用它来加密信息。由于对话密钥是对称加密，所以运算速度非常快，而服务器公钥只用于加密对话密钥本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS 协议的基本过程是这样的：

• 客户端向服务器端索要并验证公钥。
• 双方协商生成"对话密钥"。
• 双方采用"对话密钥"进行加密通信。

上面过程的前两步，又称为握手阶段（handshake）。

握手阶段的详细过程

"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。

客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做 ClientHello 请求。

在这一步，客户端主要向服务器提供以下信息：

• 支持的协议版本，比如 TLS 1.0 版。
• 一个客户端生成的随机数，稍后用于生成"对话密钥"。
• 支持的加密方法，比如 RSA 公钥加密。
• 支持的压缩方法。

这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。2006年，TLS 协议加入了一个 Server Name Indication 扩展，允许客户端向服务器提供它所请求的域名。

服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做 SeverHello。服务器的回应包含以下内容。

• 确认使用的加密通信协议版本，比如 TLS 1.0 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
• 一个服务器生成的随机数，稍后用于生成"对话密钥"。
• 确认使用的加密方法，比如 RSA 公钥加密。
• 服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供 USB 密钥，里面就包含了一张客户端证书。

客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

• 一个随机数。该随机数用服务器公钥加密，防止被窃听。
• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
• 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

为什么一定要用三个随机数，来生成"会话密钥"：

不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于 SSL 协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于 RSA 密钥交换算法来说，pre-master-key 本身就是一个随机数，再加上 hello 消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master secret 的存在在于 SSL 协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么 pre master secret 就有可能被猜出来，那么仅适用 pre master secret 作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master secret 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

同时需要注意前两个随机数都是明文传输的，窃听者是可以轻易获取到的，只有最后一个 pre master secret 是加密传输的，只有拥有服务器私钥才能解密，一旦 pre master secret 泄露，那么本次通信就就完全可被破解了。

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

服务器的最后回应

服务器收到客户端的第三个随机数 pre-master key 之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息：

• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
• 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用"会话密钥"加密内容。

简易过程

• 客户端向服务端发送请求
• 服务端返回数字证书
• 客户端用自己的CA（主流的CA机构证书一般都内置在各个主流浏览器中）公钥去解密证书，如果证书有问题会提示风险
• 如果证书没问题，客户端会生成一个对称加密的随机秘钥然后再和刚刚解密的服务器端的公钥对数据进行加密，然后发送给服务器端
• 服务器端收到以后会用自己的私钥对客户端发来的对称秘钥进行解密

• 之后双方就拿着这个对称加密秘钥来进行正常的通信

   

  

签名

1. 对对称加密的通俗理解：
   即通信的双方都使用同一个秘钥进行加解密

2. 对非对称加密算法的通俗理解：

• 私钥 + 公钥 = 密钥对
• 即用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密
• 其实这个很容易理解，因为通信双方的手里都有一套自己的密钥对，通信之前双方会先把自己的公钥都先发给对方。然后对方再拿着这个公钥来加密数据响应给对方，等到到了对方那里，对方再用自己的私钥进行解密，就这么简单
• 公钥和私钥都可以进行加密和解密

1. 非对称加密所造成的速度慢的问题解决办法：

• 先生成一个对称加密算法的密钥，用 RSA 的方式先安全的发给对方
• 随后就不再用 RSA 了，只用这个对称加密的密钥来互相通信

1. 不过，以上方式存在明显的中间人问题：
   假设，此时在客户端和服务器之间存在一个中间人，这个中间人只需要把原本双方通信互发的公钥，换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据

2. 为解决上述中间人问题,于是后来就出现了证书，简单来讲就是找了一个大家公认的中介，来证明我就是我，你就是你的问题，防止中间被篡改：
   证书中就包括个人的基本信息和最重要的公钥

3. 乍一眼看去，上面的方案貌似还不错，但证书在传输的过程中如果被篡改了呢，所以后来就又出现了数字签名：

• 简单来讲，就是将公钥和个人信息用一个 Hash 算法生成一个消息摘要
• 这个过程是不可逆的，也就是说无法通过 Hash 值得出原来的信息内容；并且只要输入数据有一点点变化，那生成的消息摘要就会有巨变，能有效防止别人篡改数据
• 在把信息发送出去时，把这个 Hash 值（消息摘要）和信息一起发出去。 接收方在收到信息后，会重新计算信息的 Hash 值，并和信息所附带的 Hash 值（解密后）进行对比，如果一致，就说明信息的内容没有被修改过，因为这里 Hash 计算可以保证不同的内容一定会得到不同的 Hash 值，所以只要内容一被修改，根据信息内容计算的 Hash 值就会变化
• 但这还是有个问题，如果中间人修改信息内容的同时也修改 Hash 值（也就是消息摘要），从而让它们可以相匹配？为了防止这种情况，Hash 值一般都会加密后（也就是签名）再和信息一起发送，以保证这个 Hash 值不被修改。但是客户端如何解密呢？这就涉及到数字证书了
• CA 用它的私钥对消息摘要加密，形成签名，并把原始信息和数据签名进行合并，即所谓的数字证书
• 这样，当别人把他的证书发过来的时候，我再用同样的 Hash 算法，再次生成消息摘要
• 然后用 CA 的公钥对数字签名解密，得到 CA 创建的消息摘要，两者一比，就知道中间有没有被人篡改了

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

解析HTTPS

网络前端http

 阅读约 17 分钟

本文主要是对HTTPS做一个总结，主要讲解HTTPS的实质、HTTPS加密原理、HTTPS的通信过程等。

HTTPS是什么

HTTP存在问题

由于HTTP协议过于简单：

• 通信使用明文（不加密），内容可能会被窃听。
• 不验证通信方的身份，因此可能遭遇伪装
• 无法验证报文的完整性，所以有可能已遭篡改。

为了解决诸多问题，HTTPS应运而生。

HTTPS的实质

HTTP加上加密处理、认证机制、以及完整性保护后的就是HTTPS。

需要知道的是，HTTPS并非是应用层的一种新的协议。只是HTTP通信接口部分用SSL或TLS协议代替而已。也就是说，所谓的HTTPS，其实就是身披SSL协议外壳的HTTP。

值得一提的是，SSL是独立于HTTP协议的，也就是说其他运行在应用层的协议均可配合SSL协议使用。现今SSL是最为广泛的网络安全技术。

SSL和TLS

HTTPS中使用了SSL和TLS这两个协议。

TLS以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。当前主流的版本是SSL3.0和TLS1.0。

TLS是以SSL为原型开发的协议，有时候会统称该协议为SSL。

HTTPS的加密原理

近代的加密算法中加密算法是公开的，而密钥是保密的。通过这种方式来保持加密方法的安全性。

加密和解密要用到密钥，如果没有密钥就没有办法对密码解密。换句话来说，任何人只要持有密钥就能够对密文进行解密。

HTTPS在加密过程中使用了非对称加密技术和对称加密技术。

对称加密算法

采用单钥密码系统的加密方式，同一个密钥可以同时做信息的加密和解密，这种加密的方法称为对称加密，也称为单密钥加密。

下面会把对称加密算法称为共享密钥加密算法。

假如现在，SSL在通信过程中，使用了对称加密算法，也就是说客户端和服务器同时共享一个密钥。

于是，以共享密钥的方式加密，必须将密钥发给对方。这个时候，假如通信过程被监听，密钥被攻击者获取了，那么这个时候也就失去了加密的意义了。

那么，有没有办法解决这个问题呢？答案是肯定的，也就是使用两把密钥。

下面先看使用两把密钥的非对称加密算法。

非对称加密算法

与对称加密算法相反，非对称加密算法需要两个密钥来进行加密和解密，这两个密钥是配对的，分别是公开密钥（公钥）和私有密钥（私钥）。

一般情况下，公钥是可以被公开的，它主要用来加密明文。而相应的，私钥不能被公开，用来解密公钥加密的密文。

值得注意的是：公钥加密后的密文只能通过对应的私钥来解密，而私钥加密的密文却可以通过对应的公钥来解密。

以上，公钥加密私钥解密用来加密，私钥加密公钥解密用来签名。相关用途后面会讲到。

下面会把非对称加密算法称为公开密钥加密算法。

于是现在，假设现在由服务器来生成一对公钥和私钥。

当客户端第一次发请求和服务器协商的时候，服务器就生成了一对公钥和私钥。

紧接着，服务器把公钥发给客户端（明文，不需要做任何加密），客户端接收后，随机生成一个密钥，使用服务器发过来的公钥进行加密。

再接着，客户端把使用公钥加密的密钥发给服务器，服务器接收到了以后，用配对的私钥进行解密，就得到了客户端随机生成的那个密钥。

这个时候，客户端和服务端所持的密钥都是相同的。此时，交换密钥环节就完成了。

于是通信开始时就可进行上面所述的共享密钥加密方式来进行加密。

同时使用

可能，有小伙伴就会问，为什么要大费周章使用非对称加密的方式，然后再得到相同的密钥，进行共享密钥加密的通信呢？

由于公开密钥加密处理起来比共享密钥加密方式更为复杂，因此在通信的时候使用公开密钥加密的方式，效率很低。

于是，我们需要使用非对称加密的方式来保证密钥共享的过程中密钥的安全性，而后在通信的过程中使用对称加密算法，这是最合理的设计方式，在保证安全性的同时又保证了性能。

所以，HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。在交换密钥使用环节使用公开密钥加密方式，之后建立的通信交换报文阶段则使用共享密钥加密方式。

以上，大概就是使用对称加密和非对称加密的过程。看似过程很完美，其实还存在着一个问题，就是：如何保证服务器传过来的公开密钥的正确性。换句话说，就是保证它不被拦截篡改。

使用证书保证公钥的正确性

假如现在正准备和某台服务器建立公开密钥加密方式下的通信，如何证明客户端收到的公开密钥就是原本预想的那台服务器发行的公开密钥呢？或许，在公开密钥传输的过程中，真正的公开密钥可能已经被攻击者替换掉了。

为了解决这个问题，可以使用由数字证书机构和其相关颁发的公开密钥证书。

下面阐述一下数字证书认证机构（简称CA）的业务流程：

首先，服务器的运营人员向数字证书机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。 
我们用白话文来翻译一下上面这段话：

• 首先，CA会向申请者颁发一个证书，这个证书里面的内容有：签发者、证书用途、使用的HASH算法、签名所使用的算法、证书到期的时间等等。
• 紧接着，把上面所提到的内容，做一次HASH求值，得到一个HASH值。
• 再接着，用CA的私钥对这个HASH值和所使用的HASH算法加密，这样就完成了数字签名。而用CA的私钥加密后，就生成了类似人体指纹的签名，任何篡改证书的尝试，都会被数字签名发现。
• 最后，把数字签名，附在数字证书的末尾，传输给服务器。

接下来，服务器会把这份由数字证书认证机构颁发的公钥证书发给客户端。这个时候，客户端可以使用数字证书机构的公开密钥对其进行验证。一旦验证成功，客户端便能够确定这个公开密钥是可信的。
我们再用白话文来翻译一下：

• 客户端拿到这个数字证书以后，用CA私钥对应的公钥，可以解密数字证书末尾的数字签名，得到HASH值和所采用的HASH算法。
• 紧接着，客户端按照解密到的这个HASH算法，对证书的内容求HASH值。如果通过CA公钥解密的HASH和通过计算求得的HASH值相同，那么认证通过，否则失败。
• 如果认证通过，就可以取得服务器的公开密钥。

那客户端上面的CA公钥是从哪里来的呢？

其实，CA除了给申请者发布证书，它自己本身也有自己的证书。CA自身的数字证书（一般由它自己生成）在我们操作系统刚安装好的时候，这些CA自身的数字证书就已经被微软（或者其它操作系统的开发机构）安装在操作系统中了。而CA的公钥就包含在其中。这样，CA就可以通过自身的私钥对发布的数字证书进行签名，而在客户端就能够用对应的公钥来对其进行解密。

其具体过程是这样子的（图中简化了数字签名的过程）：

这里其实就用到了非对称加密算法，只不过现在这个加密算法用来签名而不是加密。

使用私钥加密，公钥解密，用于公钥的持有者验证通过私钥加密的内容是否被篡改，但是不用来保证内容是否被他人获得。

而使用公钥加密，私钥解密，则是相反的，它不保证信息被他人截获篡改，但是保证信息无法被中间人获得。

客户端证书

HTTPS中不仅可以使用服务器证书，还可以使用客户端证书。以客户端证书进行客户端认证，它的作用与服务器证书是相同的。

由于客户端获取证书需要用户自行安装客户端证书，同时也面临着费用的问题。

因此，现状是，安全性极高的认证机构可办法客户端证书但是仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。

例如，银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。

HTTPS通信的过程

现在我们来理清一下SSL建立的过程：

1. 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。 
   注意：客户端还会附加一个随机数，这里记为A。
    
2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。 
   注意：这里服务器同样会附加一个随机数，发给客户端，这里记为B。
    
3. 之后服务器发送Certificate报文。报文中包含公开密钥证书。（具体的数字签名请看证书一节）
    
4. 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
    
5. SSL第一次握手结束后，客户端会对服务器发过来的证书进行验证，如果验证成功，解密取出证书中的公钥。（具体查看证书一节） 
   接着，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文使用从证书中解密获得的公钥进行加密（其实就是服务器的公钥）。 
    
6. 客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
    
7. 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值（也就是HASH值），用来供服务器校验。
    
8. 服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器同样发送Change Cipher Spec报文。
    
9. 服务器同样发送Finished报文，用来供客户端校验。
    
10. 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
     
11. 应用层协议通信，即发送HTTP响应。
     
12. 最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

读到这里，你可能会对上面的一些细节产生很多疑惑，现在我们一个个来理清楚？

问题一

为什么最后客户端和服务端都要发送一个Finish报文？

上面已经提及，Finish报文是对至今全部报文的整体校验值（也就是HASH值）。当客户端把这个值通过得到的公钥进行加密的时候，服务器得到之后对其进行解密，然后再对全部报文进行一个HASH求值。如果这个值跟解密得到的值相等的话，那么说明客户端是可信赖的。
同样的，服务器发送这样的一个整体校验值，用来客户端验证服务器是否是真正要进行通信的那一个。
综上，这个Finish报文就是用来校验双方的身份的。

问题二

整个过程中产生的三个随机数有什么用呢？还有，后面进行HTTP通信的时候，是用哪一个密钥进行加密，还有怎么保证报文的完整性。

看下面这张图。

对于客户端： 
当其生成了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。

对于服务端： 
当其解密获得了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。

在客户端和服务端的 master secret是依据三个随机数推导出来的，它是不会在网络上传输的，只有双方知道，不会有第三者知道。同时，客户端推导出来的 session secret和 hash secret与服务端也是完全一样的。

那么现在双方如果开始使用对称算法加密来进行通讯，使用哪个作为共享的密钥呢？过程是这样子的：

双方使用对称加密算法进行加密，用hash secret对HTTP报文做一次运算生成一个MAC，附在HTTP报文的后面，然后用session-secret加密所有数据（HTTP+MAC），然后发送。

接收方则先用session-secret解密数据，然后得到HTTP+MAC，再用相同的算法计算出自己的MAC，如果两个MAC相等，证明数据没有被篡改。

MAC(Message Authentication Code)称为报文摘要，能够查知报文是否遭到篡改，从而保护报文的完整性。

问题三

为什么要使用三个随机数呢？

网友dog250是这么解释的：

"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。 
对于RSA密钥交换算法来说， pre-master secret本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。 
pre-master secret的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么 pre-master secret就有可能被猜出来，那么仅适用 pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

注：我们在计算机所使用的随机数都是伪随机，而不是物理上所说的真正随机。

另外，黑客可能拦截了这样的一个加密的报文，他不对报文进行修改，而是不停的向报文的接受者发送重复的报文，以扰乱通信的建立。于是，就可以加这么一个随机数。只要任何一个通信方，接收到的报文中的随机数出现重复的情况，就可以知道有中间者对通信的过程进行了扰乱，可以立即中断通信。

问题四

如果黑客拦截了服务器把证书发送给客户端，并对证书进行恶意修改，会出现什么情况？

第一种情况，假如黑客只是单纯的修改数字证书中的内容，那么由于数字签名的存在，客户端会很容易的判断出报文是否被篡改。

第二种情况，黑客不仅修改了数字证书的内容，并且把数字签名替换掉了，由于黑客不可能知道CA的私钥，于是在客户端用CA的公钥进行解密的时候，解密之后得不到正确的信息，也很容易判断出报文是否被修改。

第三种情况，黑客恶意的从相同的第三方CA申请了一个数字证书。由于这个CA是真实存在的，所以客户端是可以用CA的公钥进行解密，得到了黑客提供的数字证书中的公钥。但是，由于数字证书在申请的时候，会绑定一个域名，当客户端比如说浏览器，检测到这个数字证书中的域名和我们现在网页访问的域名不一致，便会发出警告，此时我们也能得知数字证书被替换了。发出的警告如下：

一定要用HTTPS吗

当HTTP披上SSL外壳之后，由于加入了诸多验证的机制，虽然安全性大大提高了，但是它的处理速度会变慢。慢的原因分以下两种：

• 服务器在与客户端协商次数增多，也就是说整体上处理通信量会不可避免的增加。
• SSL进行加密处理，在服务端和客户端都需要进行加密和解密的运算处理。结果会消耗更多的硬件资源，导致负载增加。

可见，使用HTTPS会消耗更多的资源。如果每次通信都加密，那么平摊到一台计算机上，能够处理的请求数量也必定会减少。

同时，使用HTTPS需要向CA购买证书，于是开销也成为考虑是否使用HTTPS的原因之一。

所以，大部分的Web网站都采取了一个折中的方法。对于一些需要隐藏、私密的信息进行加密，而普通的信息不进行加密处理，以节省资源。

fiddler拦截HTTPS请求的原理

很多时候我们可以通过fiddler来进行抓HTTP包，但是当遇到连接采用的是HTTPS的时候，过程可能就不那么愉快了。但实际上实现拦截也十分简单。

fiddler拦截HTTPS请求最核心的地方在于真正的客户端需要安装fiddler的证书。这样子的话，fiddler能够伪造出CA证书，达到欺骗客户端，拿到需要的信息并推算出之后双方正常通信的对称加密密钥。

最后

这学期刚好有《信息安全》这门课程，那就简明的介绍一下公钥密码密码体系RSA算法原理是什么。

它是这样子工作的：

1. 选取两个大素数p和q，相乘得到n。
2. p-1和q-1相乘，得到f(n)。
3. 随机选取一个e与f(n)互质，然后得到公钥(e, n)。
4. 私钥的求法为ed = 1 mod f(n)。 [这是一个等价关系而不是一个表达式！也就是ed模fn(n)的结果是1，这是求模运算的逆运算，可以用欧几里德辗转相除法求得]
5. 最后得到的私钥为(d, n)。

整个RSA公钥密码算法的难度其实在于分解这一个大数 n， pq=n正向运算很容易，逆向运算很困难，随着这个数越来越大，想要逆向分解需要很多年的时间。