从HTTP到HTTPS

Brief

：https为什么安全，证书在https流程中是什么角色，什么是中间人攻击。

HTTP缺陷

通信使用明文可能被窃听

由于HTTP本身不具备加密功能，在传输的整个流程中（请求和应答）都是明文传输，任何在传输过程中经过的设备均有能力获取源内容。

可能遭受伪装请求

HTTP协议中，不能确定通信的双方信息，无论谁发送过来的请求都会返回响应：

        无法确定请求发送到目标服务器，或者响应是由目标服务器响应

        无法确认正在通信的对方是否具有权限访问

        即时无意义的请求也会全部响应DoS（Denial of Service 拒绝服务）攻击

报文完整性无法验证

请求或响应发出到对方接收的过程中，就算内容遭到篡改也无法知晓

其实上面三种问题并非只出现在HTTP协议上，任何未加密的协议可会存在这些问题。

HTTP+加密+认证+完整性保护=HTTPS

为了解决上述问题，需要在HTTP上加入加密处理和认证等机制，采用这种机制的被成为HTTPS（HTTPSecure）。

HTTPS不是应用层的一种新协议，只是HTTP通信部分的接口采用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替。

一般HTTP和TCP通信，采用SSL之后，变为HTTP先和SSL通信，SSL再和HTTP通信，所以HTTP是身披SSL的HTTP。

SSL

SSL采用公开密钥加密（Public-key cryptography）的处理方式，一般加密的算法是公开的，但是密钥是私密的，所以只要密钥不丢失（不被破解），加密过程就是安全的。

加密算法

共享密钥加密（对称）

        加密和解密使用同一个密钥，但这会出现一个问题，如果将这个密钥安全的送到对方手中，以及处密钥泄密造成整个加密链暴露，其优点是加密快。

公开密钥加密（非对称）

        非对称密钥，公钥和对应的密钥。公钥是任何人都可以使用的，密钥是不能公开的。请求方通过公钥加密，服务方通过密钥解密，整个过程私钥是不会暴露的，缺点是加密复杂效率低。

HTTPS混合加密

考虑对称和非对称加密性能的问题，HTTPS是通过采用混合加密的机制，在交换密钥的环节使用公开密钥加密建立通信，之后通过交换的密钥通过共享密钥加密的方式进行验证。

HTTPS安全通信机制

通信步骤

①：客户端生成随机文本并将自己支持的SSL版本加密组件等信息发送给服务端

②：如果服务端支持SSL，也会生成随机文本并将SSL信息和公钥及证书发给客户端

③：客户端验证公钥有效后，通过公钥加密Pre-master Secret随机数发给服务端

④：服务端通过自己的私钥来解密验证Pre-master Secret，如果验证成功则开始SSL通信

证书的意义

通过HTTPS的通信步骤可以看出，在SSL建立前服务端会告知请求端加密的公钥，然后客户端通过公钥加密，服务端密钥解密校验完成后才能算SSL建立完毕。那么，在服务端告知客户端它的公钥时，这并不是安全的链接，也就是说服务端A告诉客户端它的公钥是A，这个响应就不是安全的，那么怎么证明服务端A的公钥就是A呢？

受信任的数字证书颁发机构CA

由于它是类似全球共识的可信赖网站，它来为服务器A提供的公开公钥A签署CA证书，用以证明服务器A确实提供的公开公钥是A。浏览器在得到服务器提供的公钥后，再通过该权威机构提供的网站证书进行联合校验以证明可以信赖该公钥。证书是为了证明公钥是对应服务器签发而存在的。而大型权威的数字证书颁发机构在服务器公开公钥进行CA认证的过程是需要收费的，所以存在为了接HTTPS需要买证书这种说法。

从SSL流程来说，只要是非对称加密，一套对应的公钥密钥就能建立起SSL。但是基于证明服务器A的公开密钥就是密钥A的问题，客户端在建立SSL前必须得有这个证明，但是以浏览器为例，它是需要权威机构颁发的证书来证明才认为有效。用户其实大可自签证书，但是浏览器并不会使用，因为如果你的证书都不能保证何以保证你证明的东西是正确的。但是用户是可以将证书手动导入系统，使得浏览器在系统可信赖证书里面查找到后，就不再向权威机构再去证明该问题。

HTTPS的绝对安全？

中间人攻击

正常请求模式

Browser    <------------------------->    server

中间人请求模式

Browser    <-------> Proxy <-------->    server

正常情况，浏览器直接请求服务器，但是在中间人介入后，所有请求数据是要经过中间人的，服务器和浏览器彼此都不知道中间人的存在。这是对于浏览器来说中间人是服务器，对于服务器来说，中间人是浏览器。

在中间人模式中：

    步骤1中，中间人冒充服务器就必须拥有对应域名的证书私钥。1> 去对应服务器上拿（基本不可能）；2> 从CA处签发证书；3> 自签证书。

    步骤2中，中间人冒充客户端，但是HTTPS中这一步不验证，所以这一步基本没有什么问题。

    中间人攻击必须要伪造步骤1的原网站证书，所以一般在访问网站浏览器提示证书不可信任时就应该停止访问，有可能就处于中间人攻击的情况中。

假设步骤1和步骤2都没有问题的情况下，Proxy在和server通信后能得到明文信息，然后再经过自己的密钥加密给浏览器，浏览器再通过伪造源网站的证书公钥完成解密。整个过程在浏览器端看似没有任何问题，然后中间人却能拿到两方的请求明文，达到了窃取原文的目的，SSL的安全也就全无。

HTTPS服务降级