动态背景设置网站,江苏工程建设信息官方网站,合肥手机建站模板,建筑公司网站功能表文章目录 #x1f4d6; 前言1. 引入https协议2. 常见的加密方式2.1 对称加密#xff1a;2.2 非对称加密#xff1a;2.3 数据摘要数据指纹#xff1a; 3. 对加密方式的探究3.1 只使用对称加密#xff1a;3.2 只使用非对称加密#xff1a;3.3 双方都使用非对称加… 文章目录 前言1. 引入https协议2. 常见的加密方式2.1 对称加密2.2 非对称加密2.3 数据摘要数据指纹 3. 对加密方式的探究3.1 只使用对称加密3.2 只使用非对称加密3.3 双方都使用非对称加密3.4 非对称加密 对称加密3.5 共性问题 4. CA证书认证4.1 CA认证4.2 理解数据签名 5. 非对称加密 对称加密 证书认证 前言
在上一章中我们学习了http协议了解了其层状的结构并对其常见报头方法各种特性有了相关的认识。本章我们紧接着学习https这一协议。分析通信时是如何加密的主要的策略有哪些并了解现在主流的加密措施等。目标已经搬好小板凳准备开讲啦… http协议复习 1. 引入https协议
在上一章节中我们学习了http协议我们知道http协议是具有安全隐患的最主要的原因就是其是明文传输的
HTTP的安全隐患主要包括以下几点
数据明文传输HTTP传输的数据是明文的容易被截取和窃听。缺乏身份验证HTTP协议不提供对用户身份的验证机制易受到伪造请求的攻击。客户端篡改风险攻击者可以在传输过程中修改数据包内容实施各种攻击。中间人攻击攻击者可以截取数据并可能修改数据内容通信双方都不知情。
为了解决这些问题发展出了HTTPSHTTP Secure协议
它在HTTP的基础上引入了SSL/TLS协议通过对数据进行加密和身份验证使得通信更加安全可靠。在使用HTTP时尽量避免传输敏感信息并在必要时考虑使用其他安全手段如对数据进行加密加强身份验证等。
现在主流的已经不是http了都是https了~ http直接使用传输层的接口套接字http是用传输层的接口来使用网络层的协议来进行通信。构建http的response和request二进制流。数据和正文都是明文的有人拿到了数据就能看到不安全 可以选加密或者不加密加密就是https不加密就是http。SSL/TLS在http协议下侧属于软件层。
同层的http协议并不关心如何加密同层的http也不需要关心如何解密
拿到的数据就是发送之前是明文收到之后也是明文并不影响上层http的使用。 中间经历了加密解密的过程。 通过加软件层的方式解决数据安全的问题。
所有的加密都是为了防止中间有人进行窃取和篡改
具体解释
应用层已经写好的协议最典型的就是http协议。http协议最开始的时候的逻辑直接调用的是传输层对应的接口没有安全策略在功能上保证完成通信就好。但是不太安全于是在http和传输层之间加了一层软件层SSL/TLS加密层也是属于应用层的浏览器和服务端都支持。发送的http请求并不是直接交给传输层而是先交给加密层进行加密完成之后形成的二进制数据再交给传输层。传输层会封装自己的报头根本就不关心自己的有效载荷是什么有效载荷的格式也不关心。传输层将加密之后的http请求经过网络发送给对方。对方在向上交付时因为http采用的端口是80https采用的端口是443。所以传输层在收到了一个请求之后会根据绑定的端口来判断交付给那个进程。如果请求报文请求的是443就将请求交给443实际上是交给了服务端的SSL/ TLS加密解密层对数据进行解密。
这就保证了数据在中间传输过程中一旦被截取了也不会对数据进行篡改。
http SSL/TLS合起来称之为https。 2. 常见的加密方式
加密就能解决彻底解决安全问题吗不能单纯依靠加密是解决不了问题的还需要一套综合的方案 什么是加密
加密就是把明⽂要传输的信息进行一系列变换⽣成密⽂。 什么是解密
解密就是把密⽂再进⾏⼀系列变换还原成明⽂。 什么是密钥
在这个加密和解密的过程中往往需要⼀个或者多个中间的数据辅助进⾏这个过程这样的数据称为密钥。
密钥就是对应的一段数据根据不同的加密算法密钥肯定不一样。但是一般是可以通过特定的加密算法采用特定的密钥来对明文做加密。加密之后就可以形成对应的密文。
2.1 对称加密
概念简述
采⽤单钥密码系统的加密⽅法同⼀个密钥可以同时⽤作信息的加密和解密。这种加密⽅法称为对称加密也称为单密钥加密。
特征加密和解密所用的密钥是相同的。
周边概念
常见对称加密算法DES、3DES、AES、TDEA、Blowfish、RC2…特点算法公开计算量小加密速度快加密效率⾼。
举个栗子
假设明文x密钥key。则加密x ^ key得到的密文y。然后针对密文y再次进行运算y ^ key得到的就是原来的明文x。
2.2 非对称加密
概念简述
需要两个密钥来进行加密和解密。这两个密钥是公开密钥public key简称公钥。和私有密钥private key简称私钥。
特点算法强度复杂安全性依赖于算法与密钥但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快。
周边概念
公钥和私钥是配对的最大的缺点就是运算速度非常慢比对称加密要慢很多。可以正着用 通过公钥对明文加密变成密文。 通过私钥对密文解密变成明文。 也可以反着用 通过私钥对明文加密变成密文。 通过公钥对密文解密变成明文。 非对称加密有两个秘钥一个密钥叫公钥 一个密钥叫私钥。两个密钥任何一个都能叫做公钥或私钥选择其中某一个公开这就叫做公钥自己保留好不让别人看到的叫做私钥。用私钥加密公钥解密这种算法叫非对称。 举个栗子
甲要给乙一些重要的文件但是乙可能不在于是甲和乙提前做出约定。乙说我桌子上有个盒子然后我给你一把锁你把文件放盒子里用锁锁上然后我回头拿着钥匙来开锁取文件。在这个场景中这把锁就相当于公钥钥匙就是私钥公钥给谁都行不怕泄露但是私钥只有乙自己持有持有私钥的人才能解密。
2.3 数据摘要数据指纹
数字指纹数据摘要其基本原理是利用单向散列函数Hash函数对信息进行运算生成一串固定长度的数字摘要。数字指纹并不是一种加密机制但可以用来判断数据有没有被篡改。
数据摘要只有数据加密没有数据解密哈希算法是不可能的严格意义来讲不算是加密算法因为不能解密但是可以判断信息是否被篡改摘要是不可能反推回原信息的。
因为没有解密只不过从摘要很难反推原信息通常用来进行数据对比。
数字签名摘要经过加密就得到数字签名。 3. 对加密方式的探究
加密的方式有很多但是整体可以分成两大类对称加密和非对称加密。
3.1 只使用对称加密
如果通信双方都各自持有同一个密钥X且没有别人知道这两方的通信安全当然是可以被保证的除 非密钥被破解。
引入对称加密之后即使数据被截获由于黑客不知道密钥是啥因此就无法进行解密也就不知道请求的真实内容是啥了。
但是真的就这么简单的解决了吗答案是否定的
但事情没这么简单服务器同一时刻其实是给很多客户端提供服务的。这么多客户端每个人用的密钥都必须是不同的 如果是相同那密钥就太容易扩散了黑客就也能拿到了。 因此服务器就需要维护每个客户端和每个密钥之间的关联关系这也是个很麻烦的事情。
比较理想的做法就是能在客户端和服务器建立连接的时候双方协商确定这次的密钥是啥~
客户端如何拿到密钥
首先想到的是将密钥内置在客户端的浏览器内 显然这是不可取的这样都不能叫密钥了大家都能拿到这个密钥都可以对密文解密加密形同虚设。 其次想到的是客户端将密钥发送给客户端 那么一旦中间人黑客拿到了密钥就可以对密文解密那么之前的加密形同虚设。 那可以将密钥加密然后发送给客户端吗 可以但是客户端如何拿到被加密之后的密钥所形成的密文的密钥呢 显然服务端还需要将被加密之后的密钥所形成的密文的密钥发送给客户端那么该密钥要是被中间人截取了呢 显然这是一个无穷无尽的问题一直套下去解决不了问题。
3.2 只使用非对称加密
公钥加密的密文只能用私钥解密私钥加密的密文只能用公钥解密
非对称加密过程图 如果服务器先把公钥以明文方式传输给浏览器。之后浏览器向服务器传数据前都先用这个公钥加密好再传。从客户端到服务器信道似乎是安全的但是也有安全问题。因为只有服务器有相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条信道怎么保障安全重点
非对称加密服务器想向客户端发消息服务器不能用公钥加密。因为客户端没有私钥客户端没办法解密。所以只能用私钥加密并将公钥发送给客户端客户端再用公钥解密。但是中间人也会持有公钥私钥加密的密文也会形同虚设。
所以反向的从服务器单发送给客户端这条信道是不安全的而且暂时还没有解决方案。
3.3 双方都使用非对称加密
加密解密过程
服务端拥有公钥S与对应的私钥S客户端拥有公钥C与对应的私钥C。客户和服务端交换公钥。客户端给服务端发信息先用S对数据加密再发送只能由服务器解密因为只有服务器有私钥S。服务端给客户端发信息先用C对数据加密再发送只能由客户端解密因为只有客户端有私钥C。
这种是看似是安全的依旧有安全问题但是效率过于低下是用户接受不了的。
3.4 非对称加密 对称加密
首当其冲的我们要解决效率的问题
客户端发起https请求获取服务端公钥S。客户端在本地生成对称密钥C通过公钥S加密后发送给服务器。由于中间人没有私钥S即使截获了数据也无法还原出对称密钥C其实也不一定。服务器通过私钥S解密还原出客户端发送的对称密钥C并且使用这个对称密钥C加密给客户端返回的响应数据。
后续客户端和服务器的通信都只用对称密钥C加密即可因为该密钥只有客户端和服务器两个主机知道其他主机和设备即使截获数据也没有意义。
3.5 共性问题
虽然上一种方案已经接近完美了看似很安全但是依旧存在安全问题
方案2方案3方案4都存在一个问题如果在最开始中间人就已经开始攻击了呢
针对于 方案4 的问题 重点
客户端无法确定收到的含有公钥的数据报文就是目标服务器发送过来的
针对于 方案2方案3 的问题
中间人将公钥换成自己的公钥并发给客户端。客户端会误以为中间人发来的公钥是服务端发来的。所以就用中间人的公钥将数据加密成密文发给服务端。中间人依旧会截获密文用自己的私钥解密就能得到数据也是不安全的
上述分析是截获客户端数据同样的反过来中间人截获服务端数据也是一样的方式。这就是之前在讲前三个方案时括号内的备注不安全的原因。 4. CA证书认证
上述四种方案都是有问题的那么怎么样证明收到的公钥就是合法的主机发来的呢
证书是用来标识服务器是否合法的一种策略。
4.1 CA认证 服务端在使用HTTPS前需要向CA机构申领一份数字证书数字证书里含有证书申请者信息公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如身份证证明服务端请求一个服务器会返回一个证书给客户端。 请求服务器时服务器可不仅仅是把公钥给客户端是给了一批数据把所有数据都打了个包放在了一个叫证书的东西上。方案四当中客户端请求时服务端返回公钥S不叫做返回服务端公钥S而叫做获取服务端证书证书是一对信息的集合。
这个证书可以理解成是一个结构化的字符串里面包含了以下信息
证书发布机构、证书有效期、公钥、证书所有者、签名 …
需要注意的是申请证书的时候需要在特定平台生成。会同时生成一对密钥对即公钥和私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。其中公钥会随着CSR文件一起发给CA进行权威认证私钥服务端自己保留用来后续进行通信其实主要就是用来交换对称秘钥
4.2 理解数据签名
签名的形成是基于非对称加密算法的注意目前暂时和https没有关系不要和https中的公钥私钥搞混了。 图中的数据可以理解为证书。
当服务端申请CA证书的时候CA机构会对该服务端进行审核并专门为该网站形成数字签名过程如下
CA机构拥有非对称加密的私钥A和公钥A。CA机构对服务端申请的证书明文数据进行hash形成数据摘要。然后对数据摘要用CA的私钥A加密得到数字签名S。服务端申请的证书明文和数字签名S共同组成了数字证书这样一份数字证书就可以颁发给服务端了。
5. 非对称加密 对称加密 证书认证
在客户端和服务器刚一建立连接的时候服务器给客户端返回一个证书证书包含了当前服务端的公 钥也包含了网站的身份信息。
客户端进行认证
当客户端获取到这个证书之后会对证书进行校验防止证书是伪造的。判定证书的有效期是否过期。判定证书的发布机构是否受信任操作系统中已内置的受信任的证书发布机构。
验证证书是否被篡改
从系统中拿到该证书发布机构的公钥对签名解密得到一个hash值称为数据摘要设为hash1。然后计算出整个证书的hash值设为hash2对比hash1和hash2是否相等。如果相等则说明证书是没有被篡改过的。
CA机构将公钥也会内置在浏览器内部或者电脑内部的。
客户端小结
拿着证书原文做哈希得到摘要。拿着CA机构的公钥对签名做解密形成摘要。两个摘要作对比就能知道证书是否被篡改过。
服务器提前在自己的网站https被使用之前要去CA机构申请证书。从此往后所有要访问这个网站的客户端要请求这个网站都要拉取的都是证书。证书里有以明文传送的证书和数据签名附在证书上。因为世界上只有CA有私钥只有CA机构能够对这个明文重新签名。CA机构将公钥暴露给所有人客户端对签名进行解密得到摘要对证书明文重新哈希也形成摘要两个摘要一对比就发现这个证书是否被篡改。
这样就能保证客户端收到的公钥一定是目标服务器发过来的了
还会有安全隐患吗
如果中间人把证书的明文改了 由于中间人没有CA机构的私钥就无法对哈希之后的数据摘要做私钥加密重新形成新的签名。 那么就无法对篡改之后的证书形成匹配的签名。 如果强行的篡改客户端收到证书之后会发现收到的明文哈希之后的摘要和签名解密之后的摘要不一致。 就证明这个证书已经经被篡改了证书不可信从而直接终止向服务器传送信息。 中间人既然修改不了证书如果中间人用自己的私钥将证书的明文形成的摘要加密形成签名给客户端 这也是不行的因为客户端认证证书的时候只会用匹配的CA机构的公钥来解密。 自然解密不了中间人用私钥加密的证书明文谁认你啊~。 所以中间人是无法对证书做任何修改的即便证书是明文传送的。
所以https是一套非对称加密 对称加密 证书认证的机制。
为什么摘要内容在网络传输的时候一定要加密形成签名
因为只要知道哈希算法而且哈希算法一般都是公开的只要拿到明文知道哈希算法自己也可以形成摘要。如果不对它做加密的话将明文直接传过去中间商如果将明文改掉重新形成的摘要认证就没有意义了。
为什么签名不直接加密而是要先hash形成摘要
是为了缩小签名密文的长度加快验证时的运算速度。
查看浏览器内置的证书 传统的TLS/SSL连接确实是由服务器向浏览器发送证书然后浏览器通过验证该证书来确认服务器的身份和信任。在这个过程中浏览器会检查证书的有效性、签名机构的可信度等信息。然而浏览器也可以内置一些常用的根证书这些证书是由各大公认的证书颁发机构CA所签署的并被广泛接受和信任。内置证书的目的是为了方便用户使得用户不需要手动验证每个网站的证书。当浏览器访问一个使用内置证书的网站时浏览器会自动使用内置的根证书来验证服务器发送的证书。只有在该证书通过验证且与已知的根证书匹配时浏览器才会显示网站是安全可信的。
总结起来浏览器内置证书是为了简化用户验证过程并提供更好的用户体验。
