网站建设与企业发展,手机制作网站主页软件,网站建设公司豆瓣,池州家居网站建设怎么样文章目录HTTP不安全HTTPS中的加密算法对称加密非对称加密混合加密HTTPS中的摘要算法HTTPS中的数字证书SSL /TLS握手TCP建立连接#xff08;三次握手#xff09;三次握手中常见的面试题#xff1a;TCP断开连接#xff08;四次挥手#xff09;四次挥手中常见的面试题#x…
文章目录HTTP不安全HTTPS中的加密算法对称加密非对称加密混合加密HTTPS中的摘要算法HTTPS中的数字证书SSL /TLS握手TCP建立连接三次握手三次握手中常见的面试题TCP断开连接四次挥手四次挥手中常见的面试题HTTPS协议的握手第一次握手第二次握手第三次握手第四次握手常见的面试题HTTP不安全 目前绝大多数网站使用的都是HTTPS协议对数据进行传输但是如果是20年前的网站基本上只有HTTP。那么是什么原因导致HTTP逐渐转变为HTTPS的呢 先说结论HTTPS相较于HTTP能够提供更加安全的服务我们经常会看到有一些网站网址的前面有加一把锁其实这就表示了HTTPS协议的数据安全传输反之如果是HTTP协议的网站其网址前面则会有一个警告表示数据传输的不安全提示。
HTTP不安全主要体现在这三个方面 1窃听风险。HTTP协议传输的数据是明文的由于这些数据是没有经过加密操作的因此黑客就可以轻而易举地获取到传输数据的内容。 2篡改风险。当黑客窃听到数据之后由于这个数据是在中途被黑客所截取的所以此时黑客可以选择性地对这些截获到的数据进行修改后再发送到目的地导致了数据的不准确性。 3被伪造身份。黑客在截获到HTTP报文之后可以进一步伪造HTTP报文假装自己是当前用户想访问的网站然后与用户进行通信。
HTTPS引出解决安全性问题的方法 1数据加密。HTTPS的传输不再是直接明文传输而是采用了加密算法来传输密文这样即使数据被黑客截获了在短时间内也是很难破解出密文中的内容。 2完整性摘要。HTTPS通过摘要算法得到报文的一个摘要如果此时黑客篡改了报文的内容那么重新生成的摘要也会发生变化此时用户得到的数据就可以看出是不完整的了也就知道了该信息被篡改了。 3数字证书。HTTPS通过数字证书来验证通信实体的身份这个证书是需要到相关部分进行申请的但是黑客没有对应的证书此时一旦冒充其他网站则会被马上识破。当然黑客也可以去申请一个证书来冒充但是这样的成本就会比较高了。 注意 虽然HTTPS协议保证了一定的安全性但是实际上并不是绝对的安全只是增加了黑客截获数据的成本、难度。
HTTPS中的加密算法 加密算法一般分为两大类对称加密和非对称加密。 对称加密加密和解码使用的是同一把密钥。 非对称加密加密和解码使用的是不同的密钥。
对称加密 例如凯撒密码这种就是一种比较简单的对称加密算法将明文中的每个字母都按照字母表所在的位置右移k位允许回绕。但是这样加密的缺点就是每个字母经过加密后只有唯一的密文表示如果有黑客收集了很多数据并对这些数据进行统计分析那么会很大概率能够破解这个加密算法。 比较好的加密方式是采用多个凯撒密码k轮询进行加密比如位置为奇数的字母采用密钥k2进行加密而位置为偶数的字母采用密钥k3进行加密。 类似上面这样的轮询规则就可以使密码的破解难度大大提高。当然还有一个问题凯撒密码只能加密英文文本如果想要加密所有的字符则可以采用分组加密的方式。 因为我们知道任何数据在计算机中实际存储的都是0和1的比特组合而分组加密其实就是将要加密的报文处理为k比特的分组每个分组都是通过一对一的映射表进行加密的。 这样之后就可以不仅仅只是局限与英文的文本同时与前面采用多个凯撒密码k作为密钥的方式一样为了增加破解的难度一种更好的方式是采用多个映射表轮询对数据进行加密进一步增加破解成本。 在计算机网络中经常使用的对称加密算法DES、3DES、AES等。
非对称加密 既然对称加密可以完成加密的功能而且加密的效果也还是可以的那为什么还需要引出非对称加密呢 原因使用对称加密的前提是需要通信双方商量出一个密钥出来而商量这个密钥的使用也是需要之间数据的传输并且这里的传输是明文的如果此时的密钥被黑客截获那么后面再对数据按照这个密钥进行加密也就变得没有意义了。 非对称加密算法中的加密和解密的钥匙不同分别称为是公钥和私钥1如果用公钥加密则只能够使用私钥进行解密此时的公钥是不能够解密的2如果用私钥加密则只能够使用公钥解密此时的私钥是不能够解密的3公钥是对外公开的任何人都是能够得到的而私钥只有自己知道不能泄露的。 在计算机网络中经常使用的非对称加密算法RSA、ECDHE等。
混合加密 由前面我们知道对称加密算法需要提前协商出密钥而协商的过程使用的是明文进行数据的传输如果被黑客截获了这个密钥那么后面即使加密了也是没有安全性可言的。后面我们又引出了非对称加密非对称加密就可以很好地解决这个问题但是非对称加密有一个缺点其中存在大量的指数运算加密的速度是非常慢的。反观对称加密其加密的速度就非常快了一般情况下是非对称加密的100-10000倍。 为了既要保证安全性的同时又要降低数据加密的速度这时候我们就需要将对称加密和非对称加密两者结合起来了HTTPS协议中也有采用混合加密的方式既采用对称加密有采用非对称加密。 那么如何混合使用呢其实就是需要保留加密算法的优点舍弃其缺点。比如对称加密的弱点在于协商密钥的过程中传输的是明文存在密钥泄露的风险那么我们可以只在这个阶段使用非对称加密来协商这个密钥那么此时的密钥就不会被黑客获取到后面既然这个密钥是安全的那么自此之后我们就可以使用这个密钥对数据进行对称加密。这样的话我们只使用到了一次非对称加密协商密钥保证加密的效率后面都使用这个安全的密钥来加密数据保证数据的安全性。 类似这样的使用非对称加密算法传输密钥使用对称加密算法传输实际数据此密钥一般就被称为是“会话密钥”。
HTTPS中的摘要算法 摘要算法用于解决HTTP传输数据容易被篡改的问题。摘要算法也可以称为是哈希算法输入任意数据并输出一个长度固定的字符串摘要而且这个摘要的特点是不可逆的无法通过输出反推出输入、相同的输入必然会产生相同的输出、不同的输入大概率会产生出不同的输出、无论输入的数据有多长输出摘要的长度永远是固定不变的。 注意如果两个不同的输入数据经过摘要算法得到的输出结果一样那么我们将这一现象称为是“哈希碰撞”。当然出现这种情况的概率是非常低的一个好的摘要算法出现哈希碰撞的概率是非常低的而且也是非常难以通过输出的内容猜测输入的数据的。 在计算机网络中经常使用的摘要算法MD5、SHA-1、SHA-256等。 为了防止传输的数据被黑客所篡改发送方除了发送实际的数据之外还可以利用摘要算法得到数据的摘要一并发送出去。当接收方接收到数据之后利用同样的摘要算法就可以再次得到数据的摘要并将此摘要与传输过来的摘要进行比对如果发现两者不同则说明数据已经被篡改过了反之则是没有。 但是如果黑客不仅篡改了数据而且同时也篡改了摘要那么这样不也是无法判断数据是否被篡改了吗其实这种情况是比较少见的因为黑客如果在不知道规则的情况下同时篡改数据和摘要而且还能保证篡改之后的内容是一样的这种情况几乎是不可能的。当然这是需要一个前提条件的黑客不知道规则使用的这种密钥与“会话密钥”比较相像但是其有一个新的名称“鉴别密钥”。其中数据和鉴别密钥级联后经过摘要算法所生成的摘要有一个专有名称“报文鉴别码”简称“MAC”。
HTTPS中的数字证书 数字证书用于解决HTTP协议中身份容易被伪造的问题。前文总结了HTTPS采用的是非对称加密算法传输会话密钥一般是服务器将公钥对外公布客户端利用这个公钥加密数据之后是服务器通过私钥解密得到数据此时的双方就协商好了用于对称加密传输数据的密钥。 但是这时候有一个问题如果这个服务器的公钥被黑客伪造过了的话呢 在解答这个问题之前我们先来总结一个经典的问题“中间人攻击问题” 1. 客户端发送的请求被中间人劫持例如DNS劫持所有请求均发送至中间人。 2. 中间人假装自己是正规网站服务器向客户端返回自己的公钥2并索要正规网站的公钥1。 3. 客户端使用中间人的公钥2对数据进行加密并发送到中间人那里。 4. 中间人使用自己的私钥2对密文进行解密同时假装自己是客户端使用正规网站的公钥1加密解密的数据并发送到正规网站。 5. 至此中间人就已经完整获取到了整套规则后面就是收集客户端的数据并篡改数据发送至正规网站收集正规网站发送的数据并篡改数据发送至客户端。此时的客户端和服务器之间的通信也不存在任何安全性了中间人不仅能够窃听到消息的内容也能够对数据进行修改。 那么客户端如何知道自己接收到的公钥是来自正规网站的还是被中间人篡改了的呢这时候就需要使用到数字证书了。数字证书的概念就像身份证一样专门用于验证通信实体的的身份数字证书需要向认证中心申请的。 那么浏览器又是如何得到认证中心的公钥呢会不会这中间又会被中间人进行伪造呢其实实际的电脑操作系统中会内置这些认证中心的公钥所以可以放心使用以Chrome浏览器为例如果发现一个网站的数字证书无效就会进行提示
SSL /TLS握手 简单总结一下上面HTTPS解决HTTP存在的问题 1HTTPS通过混合加密算法解决了HTTP传输数据容易被窃听的问题这个过程需要协商会话密钥。 2HTTPS通过摘要算法解决HTTP传输数据容易被篡改问题这个过程需要协商鉴别密钥。 3HTTPS通过数字证书解决HTTP身份容易被伪造的问题这个过程需要呵护短验证服务器的证书。 那么有一个问题通信双方在什么时候协商会话密钥、鉴别密钥以及证书的合法性验证的呢其实这就是人们经常提到的“三次握手”之后的第四次握手了也就是SSL/TLS协议握手的时候。 在HTTPS协议中当客户端与服务器通过三次握手建立TCP连接之后并不会直接传输数据而是会先经过一个SSL/TLS握手的过程用于协商会话密钥、鉴别密钥以及证书的验证等操作之后就可以保证数据的安全传输。 在总结HTTPS协议中的SSL /TLS握手之前我们需要先提前了解HTTP协议中的经典面试题“三次握手四次挥手”。
TCP建立连接三次握手 刚开始的时候客户端处于close状态服务器处于listen状态。 第一次握手客户端给服务器发一个SYN包并指明客户端的初始化序列号ISN。此时的客户端处于SYN_Send状态。 第二次握手服务器接收到来自客户端的SYN报文之后就会以自己的SYN报文作为应答并且也是指定了自己的初始化序列号ISN同时会把客户端的ISN1作为ACK的值一并发送到客户端表示自己已经接收到了来自客户端的SYN包此时的服务器处于SYN_RECEIVED的状态。 第三次握手客户端在接收到服务器传来的SYN包的时候会发送一个ACK报文表示已经接收到了服务器的SYN包此时的客户端处于established状态。 最后服务器接收到ACK报文后也会处于established状态此时双方就已经建立起了连接。
三次握手中常见的面试题
三次握手的作用 1确认双方的接收能力、发送能力是否正常。 2指定自己的初始化序列号为后面的可靠传输做准备。 3如果是HTTPS协议的话三次握手的过程中还会进行密钥的生成以及数字证书的验证等。
ISN是固定的吗 ISN是动态生成的。三次握手的一个重要功能是客户端和服务器交换ISN以便让对方知道接下来接收数据的时候如何按照序列号组装数据。如果ISN是固定的那么攻击者会很容易猜出后续的确认号因此ISN是动态生成的。
什么是半连接队列 服务器第一次收到客户端的SYN包之后就会处于SYN_RECEIVED状态此时双方还没有完全建立连接服务器会把这种状态下请求连接放在一个队列中我们将这种队列称为是半连接队列。当然也还有一种是全连接队列就是已经完成三次握手的这种将建立已经起来的连接都会存放到全连接队列中如果队列满了之后就有可能会出现丢包的现象。 补充服务器在发送完SYNACK包之后如果一直未收到客户端传来的确认包服务器将会进行重传超时重传如果重传的次数超过了系统的规定最大重传次数那么系统将会把该连接信息从半连接队列中删除每次超时重传的等待时间不一定是相同的一般情况下是会按照指数增长的规律。
如何处理丢包问题和乱序问题 TCP为每个连接都建立了一个发送缓冲区在这个缓冲区上的每一个字节都会对应一个序列号递增的之后在发送缓冲区中取出一些数据并在前面加上序列号和长度进而组成一个发送报文当接收方收到这个报文之后就需要进行回复确认确认内容是ACK序列号长度其实也就是告诉对方下一包数据需要的起始序列号。进行这样的操作发送端其实就可以一次性发送连续的多包数据接收端只需要回复一次ACK就可以了这样的话发送端就可以将一段数据分割成一系列碎片发送出去而接收端只需要根据序列号和长度对这些数据进行重组构建出完整的数据这样的好处就是不仅可以完美避免乱序的问题而且在丢包的时候也可以及时发现并且要求发送端对这段根据序列号长度指定的数据进行重传。 注意上述的发送端和接收端是不区分服务器还是客户端的原因是TCP连接是全双工的对于两端来说都是符合这个机制的。
三次握手的过程中可以携带数据吗 第三次握手的时候可以携带数据第一、二次握手是不可以携带数据的。 假如在第一次握手的时候携带数据的话如果有人要恶意攻击服务器那么他每次都在第一次握手中的SYN报文中放入大量的数据因为攻击者根本就不理服务器的接收、发送能力是否正常如果此时一直重复发SYN报文的话这会让服务器花费大量的时间、空间来接收这些报文总而言之就是很容易让服务器受到攻击。但是对于第三次握手的话此时的客户端已经是处于连接的状态并且也已经知道了服务器的接收、发送能力是正常的所以来携带数据就允许了。
为什么要进行三次握手 当进行第一次握手的时候可能会由于说网络的状况不好导致堵塞的情况使得请求没有到达服务器。但是TCP连接是有超时重传的机制所以会再一次发送请求这时候服务器如果接收到了来自客户端的请求就会返回一个请求这就是第二次握手。但是如果这时候原来在阻塞状态下的请求由于网络重新恢复畅通后传输到服务器那么此时的服务器就又会给客户端返回一个新的请求这时候服务器的资源就会被这个请求所占用来等待来自客户端的请求所以为了避免这一现象就需要进行第三次握手发送一个请求给服务器。
TCP断开连接四次挥手 第一次挥手客户端发送一个FIN报文报文中会指定一个序列号此时客户端处于FIN_WAIT状态。 第二次挥手服务器收到FIN之后会发送ACK报文且把客户端的序列号1作为ACK报文的序列号值表明已经收到了客户端的报文了此时服务器处于CLOSE_WAIT状态。 第三次挥手如果服务器也想断开连接了和客户端的第一次挥手一样发送一个FIN报文且指定一个序列号此时服务器处于LAST_ACK状态。 第四次挥手客户端收到FIN之后一样发送一个ACK报文作为应答且把服务器的序列号值1作为自己ACK报文的序列号值此时客户端处于TIME_WAIT状态需要过一段时间来确保服务器接收到自己的ACK报文之后才会进入CLOSED状态。 服务器在接收到ACK报文之后就处于关闭连接了CLOSED状态。 四次挥手中常见的面试题
为什么客户端需要等待超时时间进行第四次挥手 原因是我们需要确保服务器是否已经接收到了ACK报文如果没有收到的话服务器会重新发送FIN报文给客户端客户端也就会再次发送ACK报文如果是没有这第四次挥手那么客户端在发送完ACK之后会直接进入关闭状态但是这时候如果传输的过程中发生丢包的话那么服务器这边就不能断开连接了。至于TIME_WAIT持续的时间至少是一个报文的来回时间一般都是会设置一个计时如果超过这个时间仍然没有再次接收到FIN报文则表示服务器这边是关闭成功的反之则需要重新更新计时的时间。
HTTPS协议的握手 了解完HTTP协议中的“三次握手四次挥手”之后接下来就是正题HTTPS协议的握手。 第一次握手 客户端向服务器发起加密通信请求 1. 客户端支持的SSL/TLS协议版本。 2. 客户端生产的随机数1用于后续生成会话密钥和鉴别密钥。 3. 客户端支持的密码套件列表每个密码套件包含用于传输会话密钥的非对称加密算法、用于验证数字证书的非对称加密算法、用于传输数据的对称加密算法、用于验证报文完整性的摘要算法。
第二次握手 服务器收到客户端加密通信请求后向客户端发出响应 1. 确认的SSL/TLS协议版本如果双方支持的版本不同则会关闭加密通信。 2. 服务器生产的随机数2用于后续生成会话密钥和鉴别密钥。 3. 确认的密码套件。 4. 服务器的数字证书。
第三次握手 客户端接收到服务器的回应之后会验证其数字证书是否合法如果证书是合法的则继续进行第三次握手 1. 客户端生产的另一个随机数3此随机数会被服务器的公钥加密。客户端根据随机数1和随机数2以及前主密钥计算出主密钥接着将主密钥切片得到两个会话密钥和两个鉴别密钥。 2. 加密通信算法改变通知表示之后数据都将用会话密钥进行加密。 3. 客户端握手结束通知表示客户端的握手阶段已经结束。客户端会生成所有握手报文数据的摘要并用会话密钥加密后发送给服务器用来供服务器校验。
第四次握手 服务器收到客服端的消息后利用自己的私钥解密出前主密钥并根据随机数1和随机数2以及前主密钥计算出主密钥接着将主密钥切片得到两个会话密钥和两个鉴别密钥。之后就进行第四次握手 1. 加密算法改变通知表示之后数据都将用回话密钥进行加密。 2. 服务器握手结束通知表示服务器的握手已经结束。服务器会生成所有握手报文数据的摘要并用会话密钥加密后发送给库福段用来供客户端校验。 到这里整个SSL/TLS的握手阶段就结束了。
常见的面试题
为什么第三次、第四次握手要发送所有握手报文的摘要呢 主要的原因就是防止握手信息被篡改。比如客户端支持的密码套件列表中有些加密算法比较弱有些加密算法比较强而此密码套件是明文传输的万一黑客将此密码套件列表进行了修改只留下一些安全性比较低的加密算法那么服务器就只能从这些安全性比较低的加密算法中选择安全性也就大大降低了。因此需要通过发送摘要的形式防止握手信息被篡改。
为什么不直接发送一个主密钥而是用两个随机数加一个前主密钥重新生成主密钥呢 主要的原因就是防止连接重放。如果没有两个随机数仅仅有客户端生成一个密钥并通过服务器公钥加密发送给服务器。那么黑客在嗅探了服务器与客户端之间的所有报文后可以再次冒充客户端向服务器发送相同的报文虽然黑客不知道内容是什么因为报文信息都是之前客户端和服务器验证过的因袭服务器会认为是客户端与其进行通信导致又一次连接。而如果有了前两个随机数即使黑客冒充客户端想要连接重放然而由于随机数的不同生成的密钥也是不同的黑客重新发送的内容将失效。
