https

1.通信双方使用明文，可能被窃听

2.不验证通信方的身份，可能被伪装

3.无法证明报文的完整性，所以可能遭到篡改，截取

http的问题

加密和解密用同一把密钥，但是这把密钥也需要传输，所以如何安全的传输这把密钥，也会成为一个很严重的问题

1.对称加密

使用私钥和公钥，发送密文的一方采用对方的公钥进行加密处理，对面收到加密信息后，使用私钥进行解密，这样就不需要发送私钥了，也不用担心密钥被截取，特点是信息传输1对多，服务器只需要一个私钥就能够和多个客户端进行加密。缺点是公钥公开，黑客可以截取信息，用公钥解锁，发现发送的内容，公钥不包含服务器信息，存在被人攻击的风险，服务器发送客户端的公钥可能被人篡改，非对称加密消耗时间比较久。

2.非对称加密（ssh采用这个方式）

交换信息采用对称加密，发送密钥采用非对称加密，发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制

3.对称加密和非对称加密结合（https协议采用这个方式）

1.解决明文内容被窃听的问题

如何实现？

1.发送者生成数字签名：将一段文本先用hash函数生成消息摘要，所谓摘要也可以理解为md5这种，然后再用发送者的私钥生成数字签名，与原文一起传送给接受者。

2.接受者校验数字签名：接受者使用发送者的公钥解密成被加密的摘要信息，然后用hash函数对收到的原文生成摘要，对比两个摘要是否相同，如果相同则代码收到的信息是完整的，没有被修改过。

前提是客户端要知道服务器的公钥，问题的关键是，和消息本身一样，服务器的公钥不能在不安全的网络中直接发送给客户端，或者说客户端无法证明拿到的公钥就是服务器端的。所以为了解决这个问题需要第三方证书颁发机构。

数字签名可以确认消息是由发送方签名并发出来的，别人无法假冒签名   2.数字签名可以确认消息的完整性，证明数据没有被篡改过。

数字签名

为了解决服务器公钥的传输问题，就干脆不传输，现在的服务器公钥都在操作系统中，internet选项中就有非常多的证书，既然直接在操作系统中，那就不需要传输服务器的公钥，因此就安全了。

如何颁发证书？

比如有名的机构ca，会直接去申请要证书的公司实地考察，确认是可靠的运营才会颁发证书，

1.客户端向服务器端发出请求时，服务器返回证书文件;2.客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。3.客户端还会验证证书相关的域名信息、有效时间等信息；客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。

解决通信方身份可能被伪装的问题

数字证书

2.解决报文被篡改问题

1.浏览器发起https请求

2.服务器把事先配置好的公钥证书返回给客户端

3.浏览器验证公钥证书：比如是否在有效期内，证书的用途是不是匹配客户端请求的站点，如果验证通过则继续，否则提示警告信息

4.浏览器继续使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥发给服务器。

5.服务器使用自己的私钥解密这个消息，得到对称密钥，然后这时候客户端和服务器端都拥有的相同的对称密钥。

6.服务器使用对称密钥对浏览器第一次的url请求进行相应和加密，发送给浏览器

7.以后都用对称加密进行通信

https的工作流程

第一次客户端发给服务器client random

第二次服务器发给客户端sever random

第三次客户端校验证书合法性，生成pre_master，并生成对称密钥，利用从证书中得到的服务器公钥将对称密钥和pre_master加密之后传送给服务器

服务器用自己的私钥解密得到对称密钥，并且生成自己的对称密钥，如果两个对称密钥相同则握手成功

TLS四次握手

SSL和TLS

https