HTTPS-确保Web安全

HTTP的问题

• TCP/IP是可能被窃听的网络。

加密处理防止被窃听：

1.通信加密：通过和SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密HTTP的通信通道和内容。

2.内容的加密：把HTTP报文里所含的内容进行加密处理。该方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍有被篡改的风险。

• 不验证通信方的身份就可能遭遇伪装。

• 无法证明报文完整性，可能已遭篡改。

在请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击。

HTTPS

1、通常，HTTP直接和TCP通信。当使用SSL时，则先和SSL通信，再由SSL和TCP通信。简言之，HTTPS，其实就是身披SSL协议这层外壳的HTTP。

2、HTTPS采用混合加密机制。

在交换秘钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

3、证明公开密钥正确性的证书

问题：正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是正确的服务器发行的。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

解决：使用数字证书认证机构和其相关机关颁发的公开密钥证书。
首先，服务器人员向数字证书认证机构提出公开密钥申请，在判明申请者身份后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥并放入公钥证书。

服务器将公钥证书发送给客户端，接到后客户端使用数字证书认证机构的公开密钥，对证书上的数字签名进行验证。

验证通过，客户端便可明确两件事：服务器的公开密钥是值得信赖的；认证公开密钥的是真实有效的数字证书认证机构。

多数浏览器会事先在内部植入常用认证机关的公开密钥。

证书认证过程

4、可证明组织真实性的 EV SSL 证书

愿意图是防止用户被钓鱼攻击，但效果还都打个问号。

5、用以确认客户端的客户端证书

证明服务器正在通信的客户端是预料之内的。问题是证书的获取及发布； 只能证明客户端实际存在，不能证明用户本人的真实有效性。

6、自签名证书-由自认证机构颁发的证书

HTTPS 的安全通信机制流程

1、客户端通过发送 Client Hello 报文开始SSL通信。报文中包含客户端支持的 SSL 的指定版本、加密组件列表等。

2、服务器可进行SSL通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含SSL版本及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

3、之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

4、最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。

5、SSL第一次握手结束后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种叫做 Per-master secret 的随机密码串。该报文已用步骤3中的公开密钥进行加密。

6、接着客户端发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 秘钥加密。

7、客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

8、服务器同样发生 Change Cipher Spec 报文。

9、服务器同样发送 Finished 报文。

10、服务器和客户端的 Finished 报文交换完毕后，SSL连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始应用层协议的通信，即发送HTTP请求。

11、应用层协议通信，即发送HTTP响应。

12、最后由客户端断开连接。断开连接时，发送 close_notify 报文。这步之后再发送 TCP FIN 报文来关闭与TCP的通信。

以上流程中，应用层发送数据时会附加一种叫做MAC的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性。 建立HTTPS通信的过程

HTTPS的一些小问题

1、通信相对HTTP要慢

2、增加CPU及内存等资源消耗

3、向认证机构（CA）购买证书