HTTPS和HTTP

HTTP的缺点

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

HTTPS的作用

• 内容加密 建立一个信息安全通道，来保证数据传输的安全；
• 身份认证 确认网站的真实性
• 数据完整性 防止内容被第三方冒充或者篡改

HTTPS的劣势

• HTTPS还需要做服务器、客户端双方加密及解密处理，会消耗更多的CPU及内存资源，如果每一次通信都加密，会消耗更多的资源，能够处理的请求数量必定也会随之减少
• 节约购买证书的开销
• 与HTTP通信相比，SSL通信部分消耗网络资源。而SSL通信部分，又因为要对通信进行处理，所以时间上又延时了

HTTPS和HTTP的区别

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

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
• HTTP是超文本传输协议，信息是明文传输；HTTPS 则是具有安全性的SSL加密传输协议。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

加解密相关知识

加密的对象：

• 通信的加密，用SSL建立安全通信线路之后，就可以在这条线路上进行通信了
• 内容的加密，将参与通信的内容本身加密。内容仍可能被篡改。

共享秘钥加密

       也被称为对称秘钥加密，加密和解密共用同一个秘钥的加密算法。以共享秘钥方式加密时必须把秘钥发送给对方。在网上转发秘钥时，可能就被窃听，失去了加密的意义。

公开秘钥加密

       也称为非对称秘钥加密，公开秘钥加密使用一对非对称的秘钥，一把叫做私有秘钥，一把叫公开秘钥。私有秘钥不能让任何人知道，公开秘钥可以随意发布。

HTTPS采用混合加密机制

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

身份认证相关知识

       客户端如何证明收到的公开秘钥就是原本预想的那台服务器发型的公开秘钥？此时，就需要使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开秘钥证书。

数字证书的颁发过程

       首先，服务器的运营人员向数字证书认证机构提出公开秘钥的申请。数字认证机构在判明提出申请者的身份之后，会对已申请的公开秘钥做数字签名，然后分配这个已签名的公开秘钥，并将该公开秘钥放入公钥证书后绑定在一起。
       服务器会将公钥证书发送给客户端，客户端可使用公钥证书认证机构的公开秘钥，对那张证书上的数字签名进行验证，验证通过之后可以确定两件事：

• 认证服务器的公开秘钥的是真实有效的数字证书认证机构
• 服务器的公开秘钥时值得信赖的

证书包含哪些内容

• 证书颁发机构的名称
• 证书本身的数字签名
• 证书持有者公钥
• 证书签名用到的Hash算法

数据完整性

       保证数据完整性常用的是MD5和SHA-1等三列值校验的方法，以及用来确认文件的数字签名方法。提供文件下载服务的Web网站也会提供相应的以PGP创建的数字签名及MD5算法生成的散列值。这些方法仍不能百分百保证确认结果正确。因为PGP和MD5本身被改写的话，用户是没办法意识到的。
       为了有效防止这些弊端，有必要使用HTTPS。SSL提供认证和加密处理及摘要功能。

摘要算法

       数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名

       数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
       数字签名的过程如下：
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两种功效：
一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
二、数字签名能确定消息的完整性。

HTTPS的安全通信机制

通信步骤，SSL与TLS的握手过程如下图所示

客户端首次发起请求

       客户端发送Client Hello报文开始TLS通信，在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密组件列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

服务端首次回应

       服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端。这里的随机数是整个过程的第二个随机数。

客户端再次回应

       客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。

服务端再次响应

       服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

       确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

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还对何时应该发送某些警报进行记录