- 1java中常见的限流算法详细解析_java中固定窗口算法
- 29.4.k8s的控制器资源（job控制器，cronjob控制器）
- 3git cherry-pick同步commit到多个分支_git cherry-pick多个commit
- 4Vue+springboot+java民宿管理系统_共享民宿 开源 java
- 5dpdk使用intel-82599网卡SRIOV的VF时，需要将VF网卡绑定到vfio_82599ec vf
- 6【大数据开发运维解决方案】超级详细的VMware16安装Redhat8&挂载镜像配置本地yum源&安装unixODBC教程_redhat8.0挂载镜像
- 7python装饰器详解_def fun1(func): func()
- 8人工智能在模拟空战中击落人类飞行员
- 9MacOSX 安装ffmpeg_install_name_tool -change ffmpeg
- 10中文文本关键词抽取的三种方法（TF-IDF、TextRank、word2vec）_word2vec和tfidf的区别
HTTP协议安全性分析_http安全吗
赞
踩
HTTP协议安全性分析
一、具体介绍
HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是万维网的数据通信的基础。
请求方法
| 方法 | 意义 |
|---|---|
| OPTIONS | 请求一些选项信息，允许客户端查看服务器的性能 |
| GET | 请求指定的页面信息，并返回实体主体 |
| HEAD | 类似于 get 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改 |
| PUT | 从客户端向服务器传送的数据取代指定的文档的内容 |
| DELETE | 请求服务器删除指定的页面 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断 |
状态码（Status-Code）
- 1xx：表示通知信息，如请求收到了或正在进行处理
- 100 Continue：继续，客户端应继续其请求
- 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议
- 2xx：表示成功，如接收或知道了
- 200 OK: 请求成功
- 3xx：表示重定向，如要完成请求还必须采取进一步的行动
- 301 Moved Permanently: 永久移动。请求的资源已被永久的移动到新 URL，返回信息会包括新的 URL，浏览器会自动定向到新 URL。今后任何新的请求都应使用新的 URL 代替
- 4xx：表示客户端的差错，如请求中有错误的语法或不能完成
- 400 Bad Request: 客户端请求的语法错误，服务器无法理解
- 401 Unauthorized: 请求要求用户的身份认证
- 403 Forbidden: 服务器理解请求客户端的请求，但是拒绝执行此请求（权限不够）
- 404 Not Found: 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置 “您所请求的资源无法找到” 的个性页面
- 408 Request Timeout: 服务器等待客户端发送的请求时间过长，超时
- 5xx：表示服务器的差错，如服务器失效无法完成请求
- 500 Internal Server Error: 服务器内部错误，无法完成请求
- 503 Service Unavailable: 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中
- 504 Gateway Timeout: 充当网关或代理的服务器，未及时从远端服务器获取请求
请求：
POST http://www.baidu.com HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Content-Length: 7
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
wd=HTTP
- 1
- 2
- 3
- 4
- 5
- 6
- 7
相应
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Thu, 14 Feb 2019 07:23:49 GMT
Transfer-Encoding: chunked
<html>...</html>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
二、HTTP安全性
HTTP 协议使用起来确实非常的方便，但是它存在一个致命的缺点：不安全，容易出现中间人攻击。
2.1 明文攻击
HTTP 协议中的报文都是以明文的方式进行传输，不做任何加密，这样会导致什么问题呢？下面来举个例子：
（1）小明在 JAVA 贴吧发帖，内容为 我爱JAVA：
（2）中间人攻击
（3）可以看到在 HTTP 传输过程中，中间人能看到并且修改 HTTP 通讯中所有的请求和响应内容，所以使用 HTTP 是非常的不安全的
2.2 对称加密
这个时候可能就有人想到了，既然内容是明文那我使用对称加密的方式将报文加密这样中间人不就看不到明文了吗，于是如下改造:
（1）双方约定加密方式
（2）使用AES加密
（3）破解
这样看似中间人获取不到明文信息了，但其实在通讯过程中还是会以明文的方式暴露加密方式和秘钥，如果第一次通信被拦截到了，那么秘钥就会泄露给中间人，中间人仍然可以解密后续的通信：
2.3 非对称加密
1、非对称原理
加密和解密的密钥不是一个
（1）B要先生成两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的。
（2）A获取B的公钥，然后用它对信息加密。
（3）B得到加密后的信息，用私钥解密。
理论上如果公钥加密的信息只有私钥解得开，那么只要私钥不泄漏，通信就是安全的。
2、演示
在约定加密方式的时候由服务器生成一对公私钥，服务器将公钥返回给客户端，客户端本地生成一串秘钥(AES_KEY)用于对称加密，并通过服务器发送的公钥进行加密得到(AES_KEY_SECRET)，之后返回给服务端，服务端通过私钥将客户端发送的AES_KEY_SECRET进行解密得到AEK_KEY,最后客户端和服务器通过AEK_KEY进行报文的加密通讯，改造如下：
（3）破解
可以看到这种情况下中间人是窃取不到用于AES加密的秘钥，所以对于后续的通讯是肯定无法进行解密了，那么这样做就是绝对安全了吗？
所谓道高一尺魔高一丈，中间人为了对应这种加密方法又想出了一个新的破解方案，既然拿不到AES_KEY，那我就把自己模拟成一个客户端和服务器端的结合体，在用户->中间人的过程中中间人模拟服务器的行为，这样可以拿到用户请求的明文，在中间人->服务器的过程中中间人模拟客户端行为，这样可以拿到服务器响应的明文，以此来进行中间人攻击：
这一次通信再次被中间人截获，中间人自己也伪造了一对公私钥，并将公钥发送给用户以此来窃取客户端生成的AES_KEY，在拿到AES_KEY之后就能轻松的进行解密了。 中间人这样为所欲为，就没有办法制裁下吗，当然有啊，接下来我们看看 HTTPS 是怎么解决通讯安全问题的。
三、HTTPS安全性
3.1 SSL
HTTPS 其实是SSL+HTTP的简称,当然现在SSL基本已经被TLS取代了，不过接下来我们还是统一以SSL作为简称，SSL协议其实不止是应用在HTTP协议上，还在应用在各种应用层协议上，例如：FTP、WebSocket。
其实SSL协议大致就和上一节非对称加密的性质一样，握手的过程中主要也是为了交换秘钥，然后再通讯过程中使用对称加密进行通讯，大概流程如下：
这里我只是画了个示意图，其实真正的 SSL 握手会比这个复杂的多，但是性质还是差不多，而且我们这里需要关注的重点在于 HTTPS 是如何防止中间人攻击的。
通过上图可以观察到，服务器是通过 SSL 证书来传递公钥，客户端会对 SSL 证书进行验证，其中证书认证体系就是确保SSL安全的关键，接下来我们就来讲解下CA 认证体系，看看它是如何防止中间人攻击的。
3.2 CA证书
上一节我们看到客户端需要对服务器返回的 SSL 证书进行校验，那么客户端是如何校验服务器 SSL 证书的安全性呢。
（1）权威认证机构
在 CA 认证体系中，所有的证书都是由权威机构来颁发，而权威机构的 CA 证书都是已经在操作系统中内置的，我们把这些证书称之为CA根证书：
（2）签发证书
我们的应用服务器如果想要使用 SSL 的话，需要通过权威认证机构来签发CA证书，我们将服务器生成的公钥和站点相关信息发送给CA签发机构，再由CA签发机构通过服务器发送的相关信息用CA签发机构进行加签，由此得到我们应用服务器的证书，证书会对应的生成证书内容的签名，并将该签名使用CA签发机构的私钥进行加密得到证书指纹，并且与上级证书生成关系链。
这里我们把百度的证书下载下来看看
可以看到百度是受信于GlobalSign G2，同样的GlobalSign G2是受信于GlobalSign R1，当客户端(浏览器)做证书校验时，会一级一级的向上做检查，直到最后的根证书，如果没有问题说明服务器证书是可以被信任的。
（3）如何查验证书
那么客户端(浏览器)又是如何对服务器证书做校验的呢，首先会通过层级关系找到上级证书，通过上级证书里的公钥来对服务器的证书指纹进行解密得到签名(sign1)，再通过签名算法算出服务器证书的签名(sign2)，通过对比sign1和sign2，如果相等就说明证书是没有被篡改也不是伪造的。
这里有趣的是，证书校验用的 RSA 是通过私钥加密证书签名，公钥解密来巧妙的验证证书有效性。这样通过证书的认证体系，我们就可以避免了中间人窃取AES_KEY从而发起拦截和修改 HTTP 通讯的报文
中间人替换CA证书攻击是没有意义的，即使截获到客户端的信息，由于没有服务器私钥，也无法识别。
这还没完，虽然客户端安全获取到服务器的公钥，是可以使用公钥加密使用非对称加密算法进行和服务器通讯，但是非对称加密算法的性能大家也是知道的，所以https结合非对称加密算法和对称加密算法的特点，使用非对称加密算法来协商对称加密算法，这样即兼顾了性能，也保证了后续使用对称加密算法的安全性。对称加密算法是在真正要通讯前客户端和服务器临时协商出来的，每个客户端都不同，这样即使中间人冒充客户端充其量也只是一个普通客户端。
