HTTPS协议和HTTP协议的区别

HTTPS 协议和 HTTP 都是应用层协议，不过HTTP 协议内容在传输时都是以文本方式进行明文传输的，这就可能导致在传输过程中，数据被泄漏和篡改等问题。所以HTTPS 协议是在HTTP 基础上引入了一个加密层。

HTTPS （全称：Hypertext Transfer Protocol Secure ），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。

什么是“加密” 和“解密”

• 加密就是把明文经过一系列变化（要传输的信息） 变成密文。
• 解密就是把密文再经过一系列的变化，变成明文。

在加密和解密的过程中，通常需要用到一个或多个中间的数据，辅助进行这个过程，这样的数据称为密钥。

加密和解密的小故事

对传输的数据进行加密和解密并不是计算机学科独有的，只要是重要的信息，那就有加密的必要性。

五言律诗秘钥加密法
北宋时期的《武经总要》记录了我国最早的军事密码本。

在军队发兵前，将战场上经常出现的40种战斗情况编成序号，例如：1 请弓、2 请箭、3 请刀、4 请甲、5 请枪旗、6 请锅幕、7 请马、8
请衣赐、9 请粮料、10 请草料……

指挥部门与战斗部门约定一首没有重复文字的五言律诗，将其中的每一个字和这40种情况一一对应，对应顺序随机排列，前线负责战斗的将领会讲对应关系烂熟于心，在战斗过程中，只需几个字就能传递大量的信息。

这种加密方法，敌人是非常难破译的，五言律诗在这其中起到的是秘钥的作用。

加密解密到如今已经发展成⼀个独立的学科:密码学
而密码学的奠基人,也正是计算机科学的祖师爷之⼀,艾伦·麦席森·图灵

艾伦·麦席森·图灵年少有为,不光奠定了计算机,人工智能,密码学的基础,并且在二战中大破德军的Enigma机,使盟军占尽情报优势,才能扭转战局反败为胜.但是因为⼀些原因,他遭到英国皇室的迫害,41岁就英年早逝了。
计算机领域中的最高荣誉就是以他名字命名的"图灵奖"。

为什么要进行加密？

在互联网上进行信息加密的重要性肯定是不言而喻的，加密可以在一定程度上保护用户的个人隐私，财产安全等。如果没有信息传输的加密技术，那么每个人的信息就会在互联网上“裸奔”。试想一下，如果一个黑客能随意获取你的支付宝，微信支付密码等个人信息，从事一些违法行为，那网络世界是非常可怕的。

这里举一个客户端和服务器在传输数据的过程中，因为传输数据没有加密，被劫持（数据被篡改）的例子。

臭名昭著的“运营商劫持”事件

下载一个天天动听
未被劫持的效果,点击下载按钮,就会弹出天天动听的下载链接。

已被劫持的效果,点击下载按钮，会弹出QQ浏览器的下载链接

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器,交换机等),那么运营商的网络设备就可以解析出你传输的数据内容,并进行篡改。

点击"下载按钮",其实就是在给服务器发送了⼀个HTTP请求,获取到的HTTP响应其实就包含了该APP的下载链接.运营商劫持之后,就发现这个请求是要下载天天动听,那么就自动的把交给用户的响应给篡改成"QQ浏览器"的下载地址了。

还有就是大家平时在浏览网页的时候，会莫名其妙弹出一些广告，这可能不是该网站的问题，而是你向服务端请求浏览该网页的时候，在数据传输的过程中，被劫持了，在返回数据时，给你注入了一些广告。

因为http的内容是明文传输的，明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击 ，所以我们才需要对信息进行加密。

所以，平时在下载应该的时候最好去应用官网下载，正规的官网都会使用一些加密技术和一些反劫持措施。比如，HTTPS加密连接：许多应用官网采用了HTTPS协议，使用SSL/TLS加密通信，这可以防止运营商对网站流量进行劫持和篡改。HTTPS协议确保通信的安全性和完整性。

不止运营商可以劫持,其他的黑客也可以用类似的手段进行劫持,来窃取用户隐私信息,或者篡改内容。

在互联网上,明文传输是比较危险的事情!!!
HTTPS就是在HTTP的基础上进行了加密,进⼀步的来保证用户的信息安全。

常见加密方式

为了能很好地对HTTPS的工作过程进行探究，接下来先介绍一些相关知识。

对称加密

• 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方式称为对称加密，特征：加密和解密所用的密钥是相同的。
• 常见对称加密算法：DES,3DES,AES,TDEA,Blowfish,RC2等
• 特点：算法公开、计算量小、加密速度快、加密效率高。

对称加密其实就是通过同一个密钥，把明文变成密文，再通过这个密钥也能把密码变成明文。

一个简单的对称加密：按位异或
假设 明文 a = 1234 密钥 k = 8888
a ^ k = 9834 ，此时9834是密文
再把9834 ^ 8888 ,得到的明文就是1234
此时的k 既能加密又能解密
当然，这是最简单的对称加密例子，实际中肯定比这更复杂

非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥是公开密钥（公钥），和私有密钥（私钥）。

• 常见非对称加密算法：RSA、DSA、ECDSA

• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密和解密速度没有对称加密解密的速度快。

• 通过公钥对明文加密，变成密文

• 通过私钥对密钥解密，变成明文

也可以反着用

• 通过私钥对明文加密，变成密文
• 通过公钥对密钥解密，变成明文

非对称加密的数学原理比较复杂,涉及到⼀些数论相关的知识，这里举⼀个简单的生活上的例⼦。
A要给B⼀些重要的文件,但是B可能不在。于是A和B提前做出约定:
B说:我桌子上有个盒子,然后我给你⼀把锁,你把文件放盒子里用锁锁上,然后我回头拿着钥匙来开锁取文件。
在这个场景中,这把锁就相当于公钥,钥匙就是私钥。公钥给谁都行(不怕泄露),但是私钥只有B自己持有.持有私钥的人才能解密。

数据摘要

• 数据摘要（数字指纹），其基本原理就是用单向散列函数（Hash函数），对信息进行运算，生成一串固定长度的数据摘要。这并不是一种加密加密，而是用来判断有没有被篡改
• 摘要常见算法：有MD5、SHA1、SHA256、SHA512等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）

哈希不可逆
哈希函数被称为不可逆函数，是因为它的逆函数难以计算。

当我们给定一个输入，通过哈希函数可以生成相应的哈希值。但是，从给定的哈希值反推回原始输入几乎是不可能的。这是因为哈希函数设计时候会考虑到散列算法的安全性，而故意进行了复杂性的增加，使其难以逆向计算回原始数据。

哈希函数的主要目的是提供数据的唯一标识和用于验证数据完整性的校验值。它们广泛应用于密码学、数据摘要、数字签名等领域。

尽管哈希函数不可逆，也就是无法准确地从哈希值回推出原输入，但是在实际应用中，可以使用暴力破解或碰撞攻击等技术来尝试破解哈希值，特别是对于较弱的哈希函数和短哈希值来说。因此，在选择哈希函数时，需要选择具有足够的安全性和抗碰撞性能的函数来保护数据的安全性。

• 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比

数字签名

摘要经过加密就能得到数字签名（文章后面详细介绍）

HTTPS工作过程探究

既然要保证数据安全, 就需要进行 “加密”.
网络传输中不再直接传输明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密

方案 1 ： 只使用对称加密

如果通信双方都使用一把密钥，且没有其他人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）

引入对称加密以后，即使数据被截获，黑客也不知道密钥是什么，因此无法进行解密。
但是实际情况并没有这么简单，我们知道，服务器是要为很多客户端服务的。那么如果采用上面的做法，每台客户端和服务器用的密钥必须是不同的（如果密钥都是相同的话，那么黑客就能利用这相同密钥截获并解密其他客户端的请求了）。因此服务器就要维护每个客户端和服务器的密钥的关联关系，这是非常麻烦的。

比较理想的做法,就是能在客户端和服务器建立连接的时候,双方协商确定这次的密钥是什么。

但是问题来了，先不管服务器是只为一台客户端服务，还是为多台客户端服务。服务器要怎么安全地把密钥传输给客户端？
如果把密钥进行明文传输给客户端，那么黑客也能截获。
因此该密钥还是要加密，如果该密钥还是对称加密，该怎么把密钥的密钥传输给客户端？因此这种只使用对称加密方式存在的问题是无法把约定好的密钥通过网络的方式安全地交给对方。

方案2 ： 只使用非对称加密

这里只使用非对称加密，此时假如只有服务器拥有私钥，而公钥是公开的，意外着客户端和黑客都有能力拿到公钥。
客户端可以用公钥进行加密传输，此时就算被黑客截获也没关系，因为只有私钥才能进行解密，而私钥只有服务器拥有，此时由客户端向服务器传输数据的过程似乎是安全的（这里还是有安全问题，后面会讲）。
但是服务器到浏览器传输数据的过程无法保证安全。
如果服务器用公钥加密，那么就不仅仅黑客无法解密，浏览器也无法解密，因为没有私钥。如果用私钥进行加密，那么公钥就可以解密，虽然浏览器可以解密，但是黑客也有公钥，也能解密。

方案 3 ：双方都使用非对称加密

方案2的解决方法很容易想到，那就是双方都使用非对称加密。

• 服务端拥有公钥S和私钥S’，客户端拥有公钥C和私钥C’
• 服务端和黑客都能拿到公钥C，客户端和黑客都能拿到公钥S
• 当客户端向服务端发送数据时，如方案2
• 当服务端向客户端发送数据时，先用公钥C进行加密，加密后的数据只有客户端能进行解密

但是这种做法 效率太低，更重要的还是有安全问题。

方案 4 ： 对称加密 + 非对称加密

我们先来解决效率问题，
在方案1中的的对称加密方案效率是很高的，但是不能保证密钥能安全送到对方手上。而非对称加密方案可以做到只有拥有私钥的客户端或服务器能解密，但是效率不行。所以可以将这两种方案结合起来。

• 服务端拥有公钥S和私钥S’，客户端拥有密钥C’。
• 客户端和黑客都能获取服务端的公钥S
• 服务器用公钥S加密自己的密钥C’，发送给服务端，此时因为只有服务端有私钥S’，只有服务端能解密，黑客不能解密。
• 当服务器解密以后，获取到了客户端的密钥C’，之后就可以使用C’进行加密通信了，黑客没有密钥C’，只有客户端和服务器有密钥C’，所以黑客即使劫持到也无法解密。

由于只是在开始协商密钥的时候使用了非对称加密，而后面可以一直使用对称加密，所以效率提高了很多。

中间人攻击

Man-in-the-MiddleAttack，简称“MITM攻击”

在不断改正的方案中，从方案2的单向非对称加密，到方案3的双向非对称加密，最后到方案4的对称加密和非对称加密结合的方式，我们讨论的都是双方在协商完密钥之后，黑客再进行劫持，试图解密获取信息，这样黑客确实不能解密。

但是MITM攻击，如果是在最开始握手协商的时候就进行了，那上面的方案可能就没用了，因为黑客已经成为中间人。

我们拿方案4举例

• 服务器具有非对称加密算法的公钥S和私钥S’

• 中间人具有非对称加密算法的公钥M和私钥M’

• 客户端向服务器发起请求，服务器明文将公钥S给送给客户端

• 中间人劫持数据报文，提取公钥S并将其保存好，然后将被劫持报文中的公钥S换成自己的公钥M，并将伪造报文发送给客户端
  

  • 客户端收到报文后，提取到M（客户端自然是不知道M是中间人的公钥，以为是服务器的公钥）直接用M对自己的对称密钥加密，形成报文发送给服务器。

  • 中间人劫持以后，直接用自己的私钥M’进行解密，获取到客户端的对称加密的密钥C’，再用曾经保存的服务器的公钥S进行加密，将报文推送给服务器。

  • 服务器拿到报文，进行用私钥S’进行解密后，得到通信密钥C’。

  • 双方开始采用密钥C’进行对称加密，进行通信。但是一切都在中间人的掌控之中，因为它也有对应的密钥C’，劫持后，可以解密，获取到信息，可以篡改数据，甚至双方都毫不知情。
    
    这种攻击方式，同样适用于方案2/3 。

问题的本质在于：客户端无法确定自己收到的含有公钥的数据报文，就是目标服务器发来的。

引入证书

CA认证

服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

CA认证，即电子认证服务 ，是指为电子签名相关各方提供真实性、可靠性验证的活动。
证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

这个证书可以理解成是⼀个结构化的字符串,里面包含了以下信息:

• 签发机构
• 有效时间
• 扩展信息
• 域名（域名是唯一的）
• 申请者
• 公钥

需要注意的是：申请证书的时候，需要在特定平台生成，会同时生成⼀对密钥对，即公钥和私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。
其中公钥会随着CSR文件，⼀起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）

可以使用在线生成CSR和私钥：
在线生成CSR和私钥

形成CSR之后，后续就是向CA进行申请认证。

理解数字签名

签名的形成是基于非对称加密算法的，注意，目前暂时和https没有关系，不要和https中的公钥私钥搞混了

当服务端申请CA证书的时候，CA机构会对该服务端进行审核，并专门为该网站形成数字签名，过程如
下：

1. CA机构拥有非对称加密的私钥A和公钥A’

2. CA机构对服务端申请的证书明文数据进行hash，形成数据摘要

3. 然后对数据摘要用CA私钥A’加密，得到数字签名S
   服务端申请的证书明文和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

方案 5 ： 对称加密 + 非对称加密 + 证书认证

在客户端和服务器建立连接的时候，服务器给客户端返回一个证书，证书包含了服务端的公钥，也包含了网站的身份信息

客户端进行认证
当客户端获取到这个证书之后，会对证书进行校验（防止证书是伪造的）

• 判定证书的有效期是否过期
• 判断证书的发布机构是否受信任（操作系统中已内置的受信任的证书发布机构）
• 验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一个hash值（称为数据摘要），设为hash1 。然后计算整个证书的hash值，设为hash2 。对比hash2和hash1 是否相等，如果相等，则说明证书是没有被篡改过的。

查看浏览器的受信任证书发布机构

方案5的一些问题解答

 中间人有没有可能篡改该证书

• 假如篡改了证书的明文

• 由于他没有CA机构的私钥，所以无法hash之后用私钥加密形成签名，那么也就没办法对篡改后的证书形成匹配后的签名。

• 如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人

  那中间人把整个证书都掉包了呢?
  

• 因为中间人没有CA私钥，所以无法制作假的证书。

• 所以中间人只能向CA申请真证书，然后用自己申请的证书进行掉包

• 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能识别出来。而出如果被识别出来了，那么就可以根据域名等认证信息，顺着找到该中间人，对于中间人来说，这是不利的。

• 永远记住：中间人没有CA私钥，所以对任何证书都无法进行合法修改，包括自己的。

常见问题

为什么摘要内容在网络传输的时候⼀定要加密形成签名?

常⻅的摘要算法有:MD5和SHA系列
以MD5为例,我们不需要研究具体的计算签名的过程,只需要了解MD5的特点:

• 定⻓:⽆论多⻓的字符串,计算出来的MD5值都是固定⻓度(16字节版本或者32字节版本)

• 分散:源字符串只要改变⼀点点,最终得到的MD5值都会差别很⼤.

• 不可逆:通过源字符串⽣成MD5很容易,但是通过MD5还原成原串理论上是不可能的.

正因为MD5有这样的特性,我们可以认为如果两个字符串的MD5值相同,则认为这两个字符串相同.

理解判定证书篡改的过程:(这个过程就好⽐判定这个⾝份证是不是伪造的⾝份证)

假设我们的证书只是⼀个简单的字符串hello,对这个字符串计算hash值(⽐如md5),结果为
BC4B2A76B9719D91
如果hello中有任意的字符被篡改了,⽐如变成了hella,那么计算的md5值就会变化很⼤.
BDBD6F9CF51F2FD8
然后我们可以把这个字符串hello和哈希值BC4B2A76B9719D91从服务器返回给客户端,此时客户端
如何验证hello是否是被篡改过?
那么就只要计算hello的哈希值,看看是不是BC4B2A76B9719D91即可.

但是还有个问题,如果黑客把hello篡改了,同时也把哈希值重新计算下,客户端就分辨不出来了呀.

所以被传输的哈希值不能传输明⽂,需要传输密⽂。

所以，对证书明⽂(这⾥就是“hello”)hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将hello和加密的签名合起来形成CA证书，颁发给服务端，当客户端请求的时候，就发送给客户端，中间⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。最后，客户端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密,还原出原始的哈希值,再进⾏校验.

为什么签名不直接加密，⽽是要先hash形成摘要？

缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度

如何成为中间⼈

• ARP欺骗：在局域⽹中，hacker经过收到ARP Request⼴播包，能够偷听到其它节点的(IP,MAC)地址。例，⿊客收到两个主机A,B的地址，告诉B(受害者)，⾃⼰是A，使得B在发送给A的数据包都被⿊客截取

• ICMP攻击：由于ICMP协议中有重定向的报⽂类型，那么我们就可以伪造⼀个ICMP信息然后发送给局域⽹中的客⼾端，并伪装⾃⼰是⼀个更好的路由通路。从⽽导致⽬标所有的上⽹流量都会发送到我们指定的接⼝上，达到和ARP欺骗同样的效果
• 假wifi&&假⽹站等

完整流程

左侧是客户端要做的事情，右侧是服务端要做的事情

总结

HTTPS工作过程中涉及到的密钥有三组
第⼀组(非对称加密):用于校验证书是否被篡改.服务器持有私钥(私钥在形成CSR文件与申请证书时获得),客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器在客户端请求时，返回携带签名的证书.客户端通过这个公钥进行证书验证,保证证书的合性，进⼀步保证证书中携带的服务端公钥权威性。
第⼆组(非对称加密):用于协商生成对称加密的密钥.客户端用收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实⼀切的关键都是围绕这个对称加密的密钥.其他的机制都是辅助这个密钥⼯作的.
第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器. 第⼀组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥.