现在很多网站使用的都是HTTPS协议,比如CSDN
他们为什么要使用HTTPS协议而不是继续使用HTTP协议呢?以及HTTPS都做了些什么?
HTTP协议与HTTPS有哪些区别? 下面我来 讲解这些问题?(篇幅可能有些长,请求耐心观看,我以0基础的角度去讲解这些东西, 如果你有一定的基础前面的跳过就好)
一, HTTP协议 和 HTTPS协议的区别
( 如果这里的图文还是不能理解的话, 就直接看简单理解)
1.HTTP协议:
HTTP协议,是一种使用 明文数据传输 的网络协议;
一直以来HTTP协议都是最主流的网页协议;
HTTP协议不提供任何方式的数据加密，
如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。
HTTP协议的明文传输会让用户存在非常大的 安全隐患。
2.HTTPS协议:
安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，
为浏览器和服务器之间的通信加密。就是在HTTP的基础上增加了 数据加密。
在数据进行传输之前，对数据进行加密，然后再发送到服务器。这样，就算数据被第三者所截获，但是由于数据是加密的，所以你的个人信息仍然是安全的。这就是HTTP和HTTPS的最大区别。
HTTPS协议是由SSL/TLS+HTTP协议构建的, 可进行加密传输、身份认证的网络协议，要比http协议安全，很多大型互联网网站，如百度、淘宝、腾讯很早就已经把HTTP换成HTTPS了。
3.HTTP和HTTPS的区别
安全性不同:
https:// 前缀表明是用SSL (安全套接字)或TSL加密的，你的电脑与服务器之间收发的信息传输将更加安全。当你使用浏览器访问一个HTTP网站的时候，你会发现浏览器会对该HTTP网站显示“不安全”的安全警告，提示用户当前所访问的网站可能会存在风险。
网站申请流程不同:
https协议需要到CA申请整数,一般免费证数很少,需要缴费,web服务器启用SSL需要获得一个服务器证数并将该证书与要使用SSL的服务器绑定
默认端口不同:
http和http使用的是完全不同的连接方式,同时使用的端口也不同,http使用的是80端口,https使用的是443端口;在网络模型种,HTTP工作于应用层,而HTTPS工作在传输层
对搜索排名的提升:
这也是很多站长所关注的地方,百度和谷歌两大搜索引擎都已经明确表示,HTTPS网站将会作为搜索排名的一个重要权重指标,也就是说HTTPS网站比起HTTP网站在搜索排名中更有优势
HTTPS网站相比起HTTP网站拥有着多种的优势,HTTP明显已经不能适应当今这个互联网时代,可以预见到HTTP将在不久的爱你过来会被HTTPS所取代
简单理解:
虽然都是超文本传输协议，但是: http 就是你跟你女朋友之间对话都是直接大声喊的，而且旁边大家都听的 到，都可以知道你们在说什么。
https 是虽然也是直接对喊，但是加密了，说的是火星文，旁边的的人能听见,但听不懂(单身狗流泪)
二. 常用的加密方法
对于理解HTTPS加密原理,首先你要了解一下常用的加密方法, 这里给大家介绍两种, 对称加密和非对称加密, 如果你这两种加密方式有所了解可直接跳过
对称加密
对称加密又叫做私钥加密 ,即信息的发送方和接收方使用同一个密钥去加密和解析数据; 对称加密的特点是算法公开,加密和解密速度快,适合对大数据量进行加密
对称加密中用到的密钥叫做私钥,私钥表示个人私有的密钥,即该密钥不能被泄露,
其加密过程中的私钥与解密过程中用到的私钥是同一个密钥,这也是对称加密之所以称之为"对称"的原因,
由于对称加密的算法是公开的,所以一旦私钥被泄露,那么密文就很容易破解,
所以对称加密的缺点是密钥安全管理困难
举个栗子;
从前有个人叫张三, 另一个人叫李四
张对李说:我这有一把锁，以后我们互相传消息，就把消息放盒子里，然后用这个锁 锁上再传，这个锁有两把一模一样的钥匙，咱俩一人一把 说完张把钥匙递给了李。
如果, 张三没有当面把钥匙给李四, 而是通过中间人王五转交钥匙给李四? 那么这个放在盒子里的消息是否安全?
这当然没有当面给安全, 很可能中间人王五复制了一把钥匙, 在转交给李四, 这样张三和李四之间的秘密对话, 就有可能被中间人王五获取
2. 非对称加密
非对称加密也叫做公钥加密,非对称加密与对称加密相比,其安全性更好;
对称加密的通信双方使用相同的密钥,如果一方的密钥泄露,那么整个通信就会被破解;
而非对称加密使用一对密码,即公钥和私钥,且二者成对出现;
私钥被自己保存,不能对外泄露;
公钥指的是公共的密钥;任何人都可以获得该密钥;
用公钥或私钥的任何一个进行加密,用另一个进行解密
被公钥加密过的密文只能被私钥解密,过程如下:
明文 + 加密算法 + 公钥=>密文
密文 + 解密算法 + 私钥 => 明文
举个梨子:
若有一个外卖平台, 使用的是非对称加密的方式, 私钥保存在平台, 不再互联网上传输, 这样就能保证这个秘钥的私密性。但是，对应私钥的公钥，是可以在互联网上随意传播的，只要外卖网站把这个公钥给你，你们就可以愉快地互通了
三. HTTPS的加密原理
1.为什么需要加密?
因为http的内容是明文传输的,明文数据会经过中间代理服务器,路由器,wifi热点,服务运营商等多个物理节点,如果信息在传输过程中被劫持,传输的内容就会完全暴露;
劫持者还可以篡改传输的信息且不被双方察觉, 这就是"中间人攻击",所以我们才需要对信息进行加密;
2.为什么不用对称加密 ?
对称加密算法中,加密和解密使用的密钥是相同的;对称加密要保证安全性的话,密钥要做好保密,不能对外公开;
如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。
但密钥在服务器传到客户端的安全性无法保证,很可能密钥在传输工程中被某些人获取
3.为什么不使用非对称加密?
非对称加密: 两把密钥,一把是公钥,一把是私钥, 公钥加密的内容只有私钥能解,私钥加密的内容只有公钥能解
如果私钥在服务端, 公钥以明文传输给浏览器端,中间人只能获得公钥无法获取私钥;
这样只能保证浏览器向服务器传输数据的安全性, 而服务端向浏览器传输的数据依旧无法保证
4.为什么不用双非对称加密?
双对称加密: 服务端公钥A密钥A, 浏览器端公钥B,密钥B
服务端向浏览器端: 服务器端公钥B加密,浏览器端私钥B解密
浏览器向服务器端: 浏览器公钥A加密, 服务端私钥A解密
要知道非对称加密是比较耗费时间的, 对服务端有一定的压力(而且这种方法也有不安全的地方,后面会提)
5.非对称加密 + 对称加密 ?
网站拥有用于非对称加密的公钥A,私钥A
浏览器向网站服务请求,服务器把公钥A明文传输浏览器
浏览器随机生成一个用于对称加密的密钥X,用公钥A加密后传给服务器
服务器拿到后用 私钥A 解密得到密钥X
这样双方都拥有密钥X了,且鄙人无法知道它,之后双方所有数据都通过密钥X加密解密即可
HTTPS基本就是采用的这种方案, 但是还有漏洞
为什么还有漏洞? 请看下面这个例子:
1. 某网站有用于非对称加密的公钥A,私钥A
2. 浏览器向网站服务器请求, 服务器把公钥A明文传给浏览器
3. 中间人劫持到公钥A,保存下来,把数据包中的公钥替换成自己伪造的公钥B(它会有自己的公钥B对应的私钥B)
4. 浏览器生成一个用于对称加密的密钥X,用 公钥B(浏览器无法得知公钥被替换了)加密后传给服务器
5. 中间人劫持后用私钥B,解密得到密钥X,再用公钥A加密后传给服务器
6. 服务器拿到后用私钥A,解密得到密钥X
这样再双方都不会发现异常的情况下,中间人通过一套"狸猫换太子"的操作,调包了服务器传来的公钥,进而得到了密钥X 根本原因是 浏览器无法确认收到的公钥是不是网站自己的,因为公钥本身是明文传输的
6.数字证书 ?
网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。
6.1 什么是数字证书?
数字证数是一种权威性的电子文档,它提供了一种在Internet上验证身份的方式;
其作用类似于司机的驾驶证或日常生活中的凭证;
它是由一个权威机构--CA证数授权(Certificate Authority)中心发行的，人们可以在互联网交往中用它来识别对方的身份。
6.2 如何防止数字证书被篡改?
我们把证书原本的内容生成一份签名对比证书内容和签名是否一致就能判别是否被篡改,这就是数字证书的"防伪技术",这里的"签名"就是 数字签名
6.3 数字签名?
- 数字签名的制作过程:
- CA机构拥有非对称加密的私钥和公钥
- CA机构对证书明文数据T进行hash
- 对hash候得值用私钥加密得到数字S
明文和数字签名共同组成了数字证书,这样一份数字证书就可以颁发给网站了
那浏览器拿到服务器串来的数字证书后,如何验证它是不是真的? (有没有被篡改,掉包)
- 浏览器验证过程
- 拿到证书,得到明文T,签名S
- 用CA机构的公钥对S解密(由于是浏览器信任的机构,所以浏览器保有它的公钥,详细请看下面)得到 s'
- 用证书里置命的hash算法对明文T进行hash得到T'
- 显然通过以上步骤, T' 应当等于 S', 除非明文或签名被篡改; 所以此时比较 S' 是否等于 T',等于则表明证书可信
6.4 中间人有可能篡改证书吗?
假设中间人篡改了证书的原文,由于他没有CA机构的私钥,所以无法得到此时加密后的签名,无法相应的篡改签名,浏览器收到该证书后会发现原文和签名解密后的值不一致,则说明证书已被篡改,证书不可信,从而种终止向服务器传输信息,防止信息泄露给中间人;
6.5 中间人可能把证书掉包吗?
假设有另一个网站B也拿到了CA机构的认证的证书, 他想劫持网站A的信息,于是它成为中间人拦截到了A传给浏览器的这个证书,然后替换成自己的证书,传给浏览器,之后浏览器就会错误的拿到B的证书里面的公钥, 就会导致"中间人攻击"
其实者并不会发生,因为证书里面包含A的信息,包括域名,浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。
6.6 为什么制作数字签名时需要hash一次?
非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多。
还有一些安全上的原因,这部分内容更6一些: crypto.stackexchange.com/a/12780
6.7 怎么证明CA机构的公钥是可信的？
为了证明某公钥是可信的，即“该公钥是否对应该网站”; 操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。
实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
6.8 HTTPS工作机制
举个粒子:
当你登录一个外卖网站的时候，由于是 HTTPS，客户端会发送 Client Hello 消息到服务器，
以明文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。
另外，还会有一个随机数，在协商对称密钥的时候使用。
这就类似在说：“您好，我想定外卖，但你要保密我吃的是什么。
这是我的加密套路，再给你个随机数，你留着。”
然后，外卖网站返回 Server Hello 消息,，告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，
还有一个随机数，用于后续的密钥协商。
这就类似在说：“您好，保密没问题，你的加密套路还挺多，
咱们就按套路 2 来吧，我这里也有个随机数，你也留着。”
然后，外卖网站会给你一个服务器端的证书，然后说：“Server Hello Done，我这里就这些信息了。”
你当然不相信这个证书，于是你从自己信任的 CA 仓库中,
拿 CA 的证书里面的公钥去解密外卖网站的证书。如果能够成功，
则说明外卖网站是可信的。这个过程中，
你可能会不断往上追溯CA、CA的CA、CA的CA的CA，反正直到一个授信的 CA，就可以了。
证书验证完毕之后，觉得这个外卖网站可信，于是客户端计算产生随机数字Pre-master，
发送 Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。
到目前为止，无论是客户端还是服务器，
都有了三个随机数，分别是：自己的、对端的以及刚生成的 Pre-Master 随机数。
通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。
有了对称密钥，客户端就可以说：“Change Cipher Spec，
咱们以后都采用协商的通信密钥和加密算法进行加密通信了。”
然后发送一个 Encrypted Handshake Message，
将已经商定好的参数等，采用协商密钥进行加密，
发送给服务器用于数据与握手验证。
同样，服务器也可以发送 Change Cipher Spec，
说：“没问题,咱们以后都采用协商的通信密钥和加密算法进行加密通信了”，并且也发送 Encrypted Handshake Message 的消息试试。
当双方握手结束之后，就可以通过对称密钥进行加密传输了。
这个过程除了加密解密之外，其他的过程和 HTTP 是一样的，过程也非常复杂。
上面的过程只包含了 HTTPS 的单向认证，也即客户端验证服务端的证书，
是大部分的场景，也可以在更加严格安全要求的情况下，
启用双向认证，双方互相验证证书。参考资料: