此文你能学到什么?:
HTTPS 是在 HTTP 和 TCP 之间建立了一个安全层,HTTP 与 TCP 通信的时候,必须先进过一个安全层,对数据包进行加密,然后将加密后的数据包传送给 TCP,相应的 TCP 必须将数据包解密,才能传给上面的 HTTP。
散列函数 、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。
非对称加密是实现身份认证和密钥协商;
对称加密是对信息进行加密;
image.png
SSL和TLS都是加密协议,有网络请求的地方就可以使用这两种协议在传输层进行加密,确保数据传输的安全,SSL是TLS的前身
,网景在1995年发布了直接发布了SSL 2.0版本,1.0版本没有对外发布。由于漏洞的原因,版本2.0也只是昙花一现,网景在1996年就发布了SSL3.0。随后在1999年的时候,基于SSL3.0版本,网景发布了TLS1.0版本(虽然TLS1.0在SSL3.0基础上的改动不太大,但是这些改动都是非常重要的)。
我们现在应该使用TLS协议
,因为在2011年和2015年的时候SSL2.0和SSL3.0就已经分别被弃用了,而且由于漏洞的缘故,如果你的服务器配置了SSL的协议,还得手动将他们禁用掉。所以我们只给服务器配置TLS协议就好了,有的服务对TLS版本有要求,你可以在SSL Server Test查看服务器的证书及协议等配置。
现在TLS主流版本是1.2。
为保证网络安全,我们需要给服务器颁发证书,这个证书可以自己生成,但是自己颁发证书是不安全的,可以被别人伪造,所以我们一般都是在第三方认证机构购买证书
。那么问题来了,证书到底和协议是否有关联,我们是否需要区分SSL证书和TLS证书呢?答案是否定的,证书不依赖协议,和协议没有太大关联,我们也不需要去纠结是使用SSL证书和TLS证书,协议由服务器配置决定,证书是配合协议一块使用的
。
对称密钥只有一个,可以是字符串,也可以是数字,对应的加密方法是对称加密。
公钥和私钥成对出现.公开的密钥叫公钥,只有自己知道的叫私钥
“举个例子: A,B双方准备进行系统间的通信,基于安全的考虑,采用数据加密通信。这时候,A有自己的公私钥,分别是A公和A私,B也有自己的公私钥,分别是B公和B私。通信前,双方需要交换公钥,这时候,A手上的密钥有:A私和B公,B手上的密钥有:B私和A公通信时,A使用B公进行敏感信息的加密,使用A私签名。B收到信息后,使用B私进行敏感信息解密,使用A公进行验签。反之亦然。
从上面可以总结:
1.公钥和私钥成对出现.公开的密钥叫公钥,只有自己知道的叫私钥 2.公钥用于敏感信息的加密,私钥用于签名.所以公钥的作用是保证数据安全,私钥的作用的标记信息的发送方.
3.用公钥加密的数据只有对应的私钥可以解密,用私钥签名只有对应的公钥可以验签.
4.用公私钥加解密的方式叫作非对称加密.
5.其实通信双方使用同一对公私钥也是可以的.
这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。以对称加密方式加密时必须将密钥也发给对方。
Q1:许许多多的客户端,不可能都用同一秘钥进行信息加密,该怎么办呢?
解决办法:一个客户端使用一个密钥进行加密
Q2:既然不同的客户端使用不同的密钥,那么对称加密的密钥如何传输?
解决办法:只能是「一端生成一个秘钥,然后通过HTTP传输给另一端」
Q3:这个传输密钥的过程,又如何保证加密?「如果被中间人拦截,密钥也会被获取,」 那么你会说对密钥再进行加密,那又怎么保存对密钥加密的过程,是加密的过程?
解决办法:非对称加密
以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交?在互联网上转发密钥时,如果通信被监听那么密钥就可会落人攻击者之手,同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥,所以使用非对称加密。
采用的算法是RSA、ECC、DH等
加密使用一对非对称的密钥。一把叫做私有密钥,另一把叫做公开密钥。顾名思义,私有密钥不能让其他任何人知道,而公开密钥则可以随意发布,任何人都可以获得。
发送密文的一方使用公钥进行加密处理“密钥”,对方收到被加密的信息后,再使用自己的私有密钥进行解密。这样可以确保交换的密钥是安全的前提下,之后使用对称加密方式进行通信交换报文。利用这种方式,不需要发送用来解密的私有密钥
,也不必担心密钥被攻击者窃听而盗走。
HTTPS将对称加密与非对称加密结合起来,充分利用两者各自的优势。在交换密钥环节使用非对称加密方式,之后的建立通信交换报文阶段则使用对称加密方式
。
具体做法是:发送密文的一方使用公钥进行加密处理“密钥”,对方收到被加密的信息后,再使用自己的私有密钥进行解密。这样可以确保交换的密钥是安全的前提下,之后使用对称加密方式进行通信交换报文。所以,HTTPS采用对称加密和非对称加密两者并用的混合加密机制。
第三方认证是指与交易双方没有切实的利益关系并被国家认可授权的有资历审核认证的单位,包括很多
如,CA认证、CE认证、QA/QC认证等等。拿CE认证来说,产品要想在欧盟市场上自由流通,就必须经国CE认证,加贴“ CE ”标志,以表明产品符合欧盟《技术协调与标准化新方法》指令的基本要求,这是欧盟法律对产品提出的一种强制性要求。
CA认证是CA中心进行的认证
。CA(Certificate Authority),称为电子商务认证中心,是负责发放和管理数字证书的权威机构,并作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。CA认证是第三方认证的一种,应用于电子商务方面。
附:我觉得第三方认证也可以叫做第三方数字证书认证
网络传输过程中需要经过很多中间节点,虽然数据无法被解密,但可能被篡改,那如何校验数据的完整性呢?那就是校验数字签名。
先普及摘要的含义:对需要传输的文本,做一个HASH计算(SHA1,SHA2)
“一段文本 ----hash函数----》 消息摘要 ----私钥加密----》 数字签名
将一段文本先用Hash函数生成消息摘要,然后用发送者的私钥加密生成数字签名,与原文一起传送给接收者。接下来就是接收者校验数字签名的流程了。
其实此处的发送者就是Sever,接受者是Client。
收到原文和数字签名之后,需要比对校验。
步骤:
1. 数字签名 ----发送者的公钥解密----》 消息摘要1
2. 原文 ----hash函数----》 消息摘要2
3. 消息摘要1 与 消息摘要2 比对
如果相同,则说明收到的信息是完整的,在传输过程中没有被修改,
否则说明信息被修改过,因此数字签名能够验证信息的完整性。
复制代码
接收者只有用发送者的公钥才能解密被加密的摘要信息,然后用HASH函数对收到的原文产生一个摘要信息,与上一步得到的摘要信息对比。
“举个例子:假设消息传递在Kobe,James两人之间发生。James将消息连同数字签名一起发送给Kobe,Kobe接收到消息后,通过校验数字签名,就可以验证接收到的消息就是James发送的。当然,这个过程的前提是Kobe知道James的公钥。问题来了,和消息本身一样,公钥不能在不安全的网络中直接发送给Kobe,或者说拿到的公钥如何证明是James的?
此时就需要引入了证书颁发机构(Certificate Authority,简称CA),CA数量并不多,Kobe客户端内置了所有受信任CA的证书。CA对James的公钥(和其他信息)数字签名后生成证书。
为什么是发送者的公钥?请求公钥的过程是数字签名的过程还是校验数字签名的过程?
下面的【数字证书认证机构的业务流程】能给与答案,请继续看。
image.png
客户端无法识别传回公钥是中间人的,还是服务器的,也就是客户端可能拿到的公钥是假的,这是问题的根本,我们可以通过某种规范可以让客户端和服务器都遵循某种约定,那就是通过「第三方认证的方式」
数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。
image.png
申请者公钥
、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名
。其中签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名; 【数字签名生成的过程】第三方认证机构是一个公开的平台,中间人可以去获取。
数字签名:将网站的信息,通过特定的算法加密,比如MD5,加密之后,再通过服务器的私钥进行加密,形成「加密后的数字签名」。
可能会发生以下情况
image.png
从上面我们知道,因为没有比对过程,所以中间人也向第三方认证机构进行申请,然后拦截后把所有的信息都替换成自己的,客户端仍然可以解密,并且无法判断这是服务器的还是中间人的,最后造成数据泄露
【证书 + 数字签名】
来保证安全image.png
5.服务器Server通过自己的私钥,对信息解密,至此得到了【对称密钥】,此时两者都拥有了相同的【对称密钥】,接下来,就可以通过该对称密钥对传输的信息加密/解密啦。
6 . Server使用对称密钥加密“明文内容A”,发送给Client。 7 . Client使用对称密钥解密响应的密文,得到“明文内容A”。 8 . Client再次发起HTTPS的请求,使用对称密钥加密请求的“明文内容B”,然后Server使用对称密钥解密密文,得到“明文内容B”。
Server安全拿到对称秘钥之后,也就是Client和Server都拥有了相同的【对称秘钥】之后,开始对称加密;认之前是非对称加密。换句话说,在交换密钥环节使用非对称加密方式,之后的建立通信交换报文阶段则使用对称加密方式
。
实施有门槛
,这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署,传统的模式下都会比较耗时耗力。会消耗相当多的资源
,平摊到一台计算机上时,能够处理的请求数量必定也会随之减少。但事实并非如此,用户可以通过性能优化、把证书部署在SLB或CDN,来解决此问题。举个实际的例子,“双十一”期间,全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现,经过优化后的许多页面性能与HTTP持平甚至还有小幅提升,因此HTTPS经过优化之后其实并不慢。开销
也是原因之一。要进行HTTPS通信,证书是必不可少的。而使用的证书必须向认证机构(CA)购买。安全意识
。相比国内,国外互联网行业的安全意识和技术应用相对成熟,HTTPS部署趋势是由社会、企业、政府共同去推动的。HTTPS就是使用SSL/TLS协议进行加密传输大致流程:
客户端拿到服务器的公钥(是正确的),然后客户端随机生成一个「对称加密的秘钥」,使用「该公钥」加密,传输给服务端,服务端再通过解密拿到该「对称秘钥」,后续的所有信息都通过该「对称秘钥」进行加密解密,完成整个HTTPS的流程。「第三方认证」,最重要的是「数字签名」,避免了获取的公钥是中间人的。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8