[计算机网络]简单入门HTTPS : 确保Web网站安全

前言

今天也是刚好看到HTTPS, 感觉HTTPS有许多需要总结的地方, 这里也是花点时间给大伙总结下

今天会从下面几个点入手给大伙介绍

1. HTTPS如何解决现有的HTTP安全问题
2. 和HTTP的区别
3. HTTPS建立连接的过程
4. HTTPS的缺点
5. 其他

HTTPS如何解决现有的HTTP安全问题

首先先要看看现有的HTTP存在什么安全问题

1. 通信使用明文传输, 内容可能被窃听
2. 不验证通信双方的身份, 用户身份可能被伪造
3. 无法证明报文的完整性, 可能内容会伪造

那么这些缺点要怎么解决呢?

明文传输问题可以通过对报文进行加密来防止内容被窃取
一般会使用SSL和TLS组合使用, 用于加密HTTP的通信内容

身份伪造问题SSL也一带解决了, 因为SSL是需要配合数字证书来保证用户身份的, 只有第三方可信赖机构颁发的证书才可以证明服务器的真实存在

对于报文可能存在篡改的问题, 可以由服务器和用户使用一定的校验算法来实现(比如MD5, SHA-1等散列值校验方式), 用户确认内容的数字签名

• 下面来介绍下HTTPS是如何保证安全的

首先要先了解下密钥加密 : 解决了信息泄漏的风险

首先要知道如何进行加密, 目前的加密思路主要还是带盐加密, 通过携带密钥的方式交给对方去解密, 而我方发送的报文也得通过密钥加密的方式来进行加密

于是就出现了在通信双方协商好密钥的情况下, 使用规定好的加密算法来加密内容传递报文的方式
但是这种方式在一开始就存在一个致命的问题 : 加密的密钥如何安全协商
在没有密钥的情况下任何报文的传输都可能泄漏, 所以不能存在我只有一个报文会交换密钥, 黑客不可能运气这么好刚好截取到这种想法, 所以非对称加密就出现了

非对称加密的思路是通信双方都将持有两个密钥, 一个公钥一个私钥, 公钥加密的数据只能通过配对的加密来解密, 靠公钥是解密不了的
通信双方只需要相互交换公钥, 然后用各自的公钥进行加密后将报文进行发送即可, 公钥泄漏了也无所谓, 因为只有持有对应私钥的机器可以正确解密

思路是美好的, 但是现实是骨感的, 公钥私钥加密的思路是好, 但是加密解密的时间效率比使用单一密钥加密解密低太多, 但是单一密钥的安全性无法保证, 所以HTTPS就采取了一个折中的混合加密方式

• 混合加密方式

通信双方会先使用非对称加密的方式, 保证接下来网络报文的安全传输, 在保证安全的情况下通信算法交换统一密钥, 在确认密钥安全交换的前提下使用共享密钥的方式来加密报文

同时HTTPS还会使用数字证书来保证公钥的安全性, 服务器会将由认证机构颁发的公钥证书发送给客户端来让客户端校验公钥的有效性

摘要算法 + 数字签名 : 解决信息被篡改的问题

摘要算法就是通过一定的算法, 对当前要传输的内容进行一个计算标记, 计算出一个唯一标识出来用于校验内容是否篡改

然后在报文发送的时候顺带将这个唯一标识发送给对方, 这样对方就能通过这个唯一标识对报文中的内容进行校验了

唯一需要注意的就是这个摘要算法需要防止泄漏, 避免黑客作出针对性的攻击, 所以摘要算法的协商会放在一开始非对称加密协商共有密钥的时候协商摘要算法

HTTPS和HTTP的区别

1. HTTP消息明文传输, 而HTTPS是在TCP和HTTP的网络层之间加入了SSL / TLS的安全协议, 报文是使用加密传输的
2. HTTP是三次握手, HTTPS在原有的三次握手的基础上加上了SSL / TLS握手过程
3. HTTP默认端口是80, HTTPS是443
4. HTTPS协议需要向 CA (证书权威机构) 申请数字证书来确保服务器身份可行

HTTPS建立连接的过程

首先要知道HTTPS需要在原先HTTP 3次握手的基础上加上SSL / TLS的 4 次握手, 基本的流程是

1. 客户端向服务器索要并验证服务器的公钥
2. 双方协商产生当前会话的密钥
3. 双方采用密钥进行加密通信交换共有密钥
4. 进行加密通信

下面细节点讲, 这边是有两种握手方式的分别是RSA握手和ECDHE握手, 下面先来讲讲RSA握手

首先要知道的是RSA算法是一种密钥交换协商的算法, 客户端和服务器端在交互的时候会使用随机密钥来作为本次连接会话的共有密钥

首先客户端会先生成第一个随机数, 然后发送TLS握手请求给服务器端

服务器端收到客户端的随机数请求后, 会返回要使用的密钥套件和数字证书以及第二个随机数给客户端

客户端在验证数字证书有效后, 会使用数字证书中的公钥加密, 然后发送第三个随机数给服务器端, 在含有第三个随机数的报文中, 客户端会使用3个随机数计算出一个会话密钥出来, 然后发送再发送请求给服务器端

• 此时这个请求相当于通知服务器端准备使用加密的方式来进行报文传输
• 这里发送的报文会使用这里计算出来的随机密钥加密一段信息发送给服务器方

服务器端在收到客户端的第三个随机数后, 也会和客户端一样计算出一个随机密钥出来, 然后尝试解析客户端发送的信息, 这个信息是客户端根据前面几次消息交互计算出来的, 服务器端通过解析这个信息来验证自己计算出来的随机密钥是否和客户端一致

验证完成后, 服务器端会学客户端也使用随机密钥加密一段信息, 并将该报文发送给客户端确认, 此时4次握手完成, 服务器和客户端双方各自持有一个共有随机密钥, 可以开始加密传输消息了

RSA算法缺陷

不具备前向安全性, 前面3次握手的时候需要使用到公钥私钥来解密客户端发送的随机数, 如果服务器端的私钥泄漏的话会导致报文泄漏

总结来说RSA算法的缺陷是因为在4次握手的时候需要使用到服务器的私钥来保证第三次握手的安全, 但是私钥可能会泄漏, 所以报文的传输会存在安全问题

既然私钥会泄漏, 那么就不用私钥了, 也使用随机的密钥来进行握手过程, 这样不就安全了吗?所以ECDHE算法出现了

ECDHE 算法 : 数学万岁

来看看如何保证单向推导的公私钥协商

(a ^ i) % p = b, 知道 i 和 p 可以很快计算出 b, 但是知道 b 要逆推出 i 缺非常困难, 并且当质数p非常大的时候, 即使知道a和b也很难计算出来 i
所以可以利用上面离散对数的公式, 将 i 和 p 公开, 然后客户端和服务器端根据自己的私钥 a 生成对应的公钥b

然后利用离散对数的交换律, 使用对方的公钥b1和自己的私钥a2计算出来的 b1 ^ a2 % p的结果是相同的, 这个相同的值就可以作为客户端和服务器端使用的对称加密的密钥了, 破解的难度也是非常高

实际的ECDHE算法就是通过这种离散对数的思想来实现的, 同时还利用到了椭圆曲线的知识, 这里不展开提

ECDHE 的 握手过程

1. 客户端发送请求, 会发送一个随机数给服务器并附带客户端使用的TLS版本号, 让服务器查看是否支持
2. 服务器也会响应一个随机数给客户端并且会将自己的数字证书发送给客户端, 同时会将自己计算出来的公钥发送给客户端, 这里还会发送本次会话要使用的加密算法等信息
3. 客户端会根据服务器的公钥和自己生成的私钥计算出一个共享公钥, 然后再在共享公钥的基础上加上前两次握手的两个随机数计算出一个会话密钥作为本次会话的共享密钥, 然后会使用共享密钥加密一段数据给服务器, 顺带发送自己的公钥给服务器
4. 服务器会根据收到的客户端公钥按照相同的算法计算出一个相同的共享密钥, 然后验证客户端的信息并回应一段信息告知客户端我也持有共享密钥了, 可以开始加密通话了

可以发现ECDHE握手的全过程没有用到一个固定的密钥, 全程都是使用随机数来实现的, 所以ECDHE的安全性要比RSA高一截
同时在第三次握手的时候, 客户端是可以同时发送握手结束后要发送的请求报文给服务器, 不必等待服务器第四次握手后再发送请求, 所以在握手的时间上看是比RSA要少一RTT(消息往返时间)的

HTTPS的缺点

SSL在通信和处理速度上都比较慢, 会消耗客户端和服务器端的CPU资源
不适用HTTPS两个原因 1. 不想花钱买证书 2. HTTPS通信消耗大

其他

HTTPS也不是完全安全的, 因为HTTPS使用的IP地址是无法隐藏的, 所以如果服务器的数字证书泄漏的话, 黑客是可以通过伪造服务器, 在服务器和客户端的中间多增加一个中间层来窃取用户的信息的

同时HTTPS虽然保证了报文传输的安全性, 但是在HTTPS的网站中可能还是存在一些通过http请求来获取的资源, 黑客可以通过篡改这些资源来实现入侵HTTPS的网站

所以HTTPS不是100 %安全的

总结

HTTPS在不改动当前HTTP协议的基础上对当前HTTP协议进行了增强, 增加了传输的安全性, 从多个方面解决了HTTP协议报文传输的安全问题, 但是局限于HTTP + TCP / IP协议栈的报文传输, 还是存在中间人攻击的风险, 同时无法保证HTTPS网站中资源获取的完全安全, 所以还是不能完全相信HTTPS网站的安全性