面试中的Https
在Http协议中有可能存在信息窃听或身份伪装的安全问题。使用HTTPS通信机制可以有效地防止这些问题。
Https
Http的缺点
- 通信使用明文(不加密)，内容可能会被窃听。
- 不验证通信方的身份，因此有可能遭遇伪装。
- 无法验证报文的完整性，所以有可能已遭篡改。
这些问题不仅在Http上出现，其他未加密的协议中也会存在这类问题。
什么是Https
Https并非是应用层的一种新的协议。只是Http通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议而已。
通常，Http直接和TCP通信。当使用SSL时，则演变成先和SSL协议通信，再由SSL和TCP通信了。简言之，所谓Https，就是身披SSL这层协议外壳的Http。
Https有什么作用
Http+加密+认证+完整性保护 = Https
Https有以下作用：
- 内容加密 建立一个信息安全通道，来保证数据传输的安全。
- 身份认证 确认网站的真实性。
- 数据完整性 防止内容被第三方冒充或者篡改。
下面就是Https的整个架构，现在的https基本都使用TLS了，因为更加安全。
Https 加密
对称加密
对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。
但是我们使用对称加密加密Http通信内容会有一个问题，因为客户端和服务器在通信过程中都必须知道秘钥，而在发送秘钥的过程中又有可能被第三方监听，从而获取到秘钥。
非对称加密
非对称加密很好地解决了对称加密的困难。
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey），并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。 用公钥加密的只能用私钥解开，用私钥加密的只能用公钥解开。
非对称加密的特性决定了服务器用私钥加密的内容并不是真正的加密，因为公钥所有人都有，所以服务器的密文能被所有人解析。但私钥只掌握在服务器手上，这就带来了两个巨大的优势:
- 服务器下发的内容不可能被伪造，因为别人都没有私钥，所以无法加密。强行加密的后果是客户端用公钥无法解开。
- 任何人用公钥加密的内容都是绝对安全的，因为私钥只有服务器有，也就是只有真正的服务器可以看到被加密的原文。
注意：
想要根据密文和公钥，恢复信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。
因此，Https采用对称加密和非对称加密两者并用的混合加密机制。
也就是说，Https通过非对称加密来传递对称加密的秘钥。
那为什么不直接采用非对称加密来加密通信内容？
非对称加密处理起来比对称加密更为复杂，因此若在通信时使用非对称加密，效率比较低。
证书的私钥加密公钥
遗憾的是，非对称加密还是存在一些问题的。那就是无法保证公钥本身就是货真价实的公钥。比如，正准备和某台服务器建立非对称加密下的通信时，如何证明收到的公钥就是原来预想的那台服务器发行的公钥。或许在公开秘钥传输过程中，真正的公钥已经被人替换了。
那怎么办？
再加密一次。
每一个使用 HTTPS 的服务器都必须去专门的证书机构注册一个证书，证书中存储了用数字证书机构私钥加密的公钥。这样客户端用数字证书机构的公钥解密就可以了。
而数字证书机构的公钥会直接内置在各大操作系统(或者浏览器)的出厂设置里。所以各个公司要先去数字证书机构认证，申请证书，然后操作系统只会存储数字证书机构的公钥。因为数字证书机构数量有限，所以操作系统厂商相对来说容易管理。
总结：
Https通过非对称加密(通常是RSA算法)加密对称加密的秘钥，然后使用证书机构的私钥加密非对称加密的公钥，而证书机构的公钥会内置在浏览器里，从而保证即使被第三方监听，也可以保证安全。
SSL 与 TLS
SSL (Secure Socket Layer，安全套接字层)
SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3.0版本。
SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
TLS (Transport Layer Security，传输层安全协议)
用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。
SSL/TLS协议作用
- 认证用户和服务器，确保数据发送到正确的客户机和服务器；
- 加密数据以防止数据中途被窃取；
- 维护数据的完整性，确保数据在传输过程中不被改变。
TLS比SSL的优势
- 对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
- 增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
- 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
- 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
- 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。
SSL/TLS的握手过程
SSL与TLS握手整个过程如下图所示，下面会详细介绍每一步的具体内容：
客户端首次发出请求
由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。
客户端需要提供如下信息：
- 支持的协议版本，比如TLS 1.0版
- 一个客户端生成的随机数，稍后用于生成”对话密钥”
- 支持的加密方法，比如RSA公钥加密
- 支持的压缩方法
服务端首次回应
服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端，这里的随机数是整个过程的第二个随机数。
服务端需要提供的信息：
- 协议的版本
- 加密的算法
- 随机数
- 服务器证书
客户端再次回应
客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。
服务器再次响应
服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
后续客户端与服务器间通信
确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。
值得特别提出的是：
SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。
session的恢复
有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。
session ID
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。
session ticket
客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。
目前只有Firefox和Chrome浏览器支持。
Https的劣势
对数据进行加解密决定了它比http慢。需要进行非对称的加解密，且需要三次握手。首次连接比较慢点，当然现在也有很多的优化。
出于安全考虑，浏览器不会在本地保存HTTPS缓存。实际上，只要在HTTP头中使用特定命令，HTTPS是可以缓存的。Firefox默认只在内存中缓存HTTPS。但是，只要头命令中有Cache-Control: Public，缓存就会被写到硬盘上。 IE只要http头允许就可以缓存https内容，缓存策略与是否使用HTTPS协议无关。
HTTPS和HTTP的区别
- https协议需要到CA申请证书。
- http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
- http默认使用80端口，https默认使用443端口
Python等爬虫怎么处理Https
https拿爬虫毫无办法，或者说https就不是为了反爬虫的。https的作用是保证服务源授信。比如你访问支付宝，网络被劫持了，你看到的就是个假网站，一旦你登录，账号就泄露了。但用https就能保证你访问的一定是真的支付宝网站，这是由CA证书保证的。回过来再说爬虫，爬虫伪造的是客户端，https是不能保证客户端是授信的，你只要按照ssl协议进行通信，该怎么爬数据还是怎么爬。
https协议里数据的传输是需要经过加密的,在这个过程中，就给爬虫带来了抓包问题，抓出来的数据也是经过加密的，不能解析。
理论上是不行了，因为https保证的就是数据在传输过程中不会被盗取。但解决起来也很简单，就是设置个代理伪装一下，代价就是你要安装个假证书，当然这也肯定是无所谓的。
参考文档：
