目录
一、Http请求的构造
1.1 通过form表单进行构造
1.2 通过Ajax构造
二、HTTPS
2.1 HTTPS是什么
2.2 HTTP中的加密协议(TLS/SSL)
2.2.1对称加密
2.2.2 非对称加密
2.2.3 HTTPS总结
构造HTTP请求的常见方式有,通过form表单构造,通过ajax构造,这两者都是使用HTML/JS。当然也可以利用Java代码使用Socket进行构造(该方法较为少见,这里我们就不进行介绍),使用软件PostMan进行构造。
直接上代码:
form参数说明:
但是像上面这样写,无法进行请求的提交,需要搭配input标签才可以进行构造:
书写GET请求
input参数说明:
使用fiddler进行抓包:
可以得知,我们构造的请求,Bing服务器并没有做出特殊的处理,只是返回了Bing的主页。
后序在书写服务器代码中,可以根据需求,来获取url中的query string 来完成不同的功能。
书写POST请求
对于from构造的post请求,body里面的数据格式和query string是非常相似的,两者都为键值对形式。(键和值之间使用 = 来分割,键值对之前使用 & 来进行分割)。
何为Ajax?
AJAX即“Asynchronous JavaScript and XML”(异步的JavaScript与XML技术),指的是一套综合了多项技术的浏览器端网页开发技术。
在代码中如何使用ajax呢?
js原生提供ajax的api,但是原生api并不好用,于是我们采用jquery提供的api(其是针对原生API的封装),更为简单。
注意:这里报错的原因是因为我们只看到了构造的请求,无法获取正确的响应,因为发送请求给搜狗服务器,并没有得到回应。(相当于是在麦当劳点了一份肯德基一般,无法回复客户端。)
分析:
理解 success 回调函数
success函数:顾名思义,是表示从客户端发送http请求成功后,回调函数就会在服务器响应返回到浏览器时触发该回调,正是这个回调体现所谓的异步。
一般来说,success 这个回调函数中,需要写入的业务逻辑,一般就是为了展示给用户观看的内容。即前端开发人员决定在这里面实现什么给用户看。
问1:那么业务逻辑的数据从哪来?
答:业务逻辑的数据就是从 success 函数中,传入的参数 data 中获取到的。
问2:那么 data 从哪来?
答:data 就是从 HTTP 响应的正文 body 来获取的。
问3:正文 body 又从哪来?
答:HTTP 响应的正文 body 其实就是服务器端的代码构造的,常用的就是 json 格式数据,因为 json 格式的数据是可以将很多复杂的文本组合在一起。所以,后端的开发人员,一般通过将 Java 对象转换成 json 格式的数据,放到 响应的 body 中。
HTTPS(超文本传输安全协定,HyperText Transfer Protocol Secure,常称为 HTTP over TLS,HTTP over SSL 或HTTP Secure)是一种透过计算机网络进行安全通讯的传输协议。HTTPS经由HTTP进行通讯,但利用SSL/TLS来加密封包。
HTTPS的主要作用是在不安全的网络上创建一个安全信道,并使用适当的 加密套件/服务器证书 来 通过验证/获取信任。对窃听和中间人攻击提供合理的防护。
加密是什么?
Tips:
TLS与SSL之间的关系
传输层安全性协议(英语:Transport Layer Security,缩写:TLS)前身称为安全套接层(英语:Secure Sockets Layer,缩写:SSL)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。
由于TLS是SSL的改进版本,其优势也相当明显:TLS在与高层的应用层协议(如HTTP、FTP、TELNET等)无耦合。应用层协议能透明地运行在TLS协议之上,由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密,从而保证通信的私密性。
由于HTTP主要设计加密的部分是SSL,所以这里我们重点介绍这个:
加密的方法大致分为两大类:对称加密和非对称加密。
对称加密其实就是通过同一个 "密钥" , 把明文加密成密文, 并且也能把密文解密成明文。
在理想情况下,引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥。
但是这并不是绝对的,在客户端与服务器通讯之初,需要由客户端生成密钥,在由客户端传输给服务器。这时的密钥是通过明文传输的,如果这是密钥被黑客截取,后序客户端与服务器再通过密钥进行加密,就相当于掩耳盗铃了。
阅读完以上内容,可能会有一些问题:
密钥是谁生成的?
密钥是客户端生成的,且每个客户端生成的密钥是不相同的,因为如果相同的话,那么黑客自己创建一个客户端那么不就可以破解密钥了。
针对以上问题(密钥在明文传输的过程中可能会被黑客捕获),由此引入非对称密钥——密钥的传输也必须加密传输。
概念:使用公钥把明文加密后所得的密文,只能用相对应的私钥才能解密并得到原本的明文,最初用来加密的公钥不能用作解密。
公钥可以公开,可任意向外发布;私钥不可以公开,必须由用户自行严格秘密保管,绝不透过任何途径向任何人提供,也不会透露给被信任的要通信的另一方。
非对称加密的应用场景
由于,公钥和私钥是配对的. 最大的缺点就是运算速度非常慢,比对称加密要慢很多.因此如果在一些数据安全性要求不高的网站,可以直接使用对称加密。
运用方式:
服务器发送公钥给客户端,客户端在本地生成密钥,再通过公钥对密钥进行加密,服务器通过私钥对密文进行解密,获取信息——密钥是888888,由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密.
中间人攻击
如果仅仅只通过私钥公钥的方式进行传输是存在着一些漏洞的,如果黑客截取了来自服务器的公钥,然后自己生成了一对公钥,私钥,来伪造服务器参与中间的通讯就会产生很大的隐患。
为了方便描述,我们将服务器自身的公钥私钥记作,公钥1,私钥1。黑客伪造生成的公钥私钥记作:公钥2,私钥2。
举例:
引入证书(服务器在设立之初,需要去CA机构申请证书)
一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端,并且不被其他终端识破。中间人攻击是一个(缺乏)相互认证的攻击。
大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如,SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发,并且能执行双向身份认证。
举例:
在客户端与服务器刚一建立连接的时候,服务器会返回一个证书(当然了,这个证书中是包含公钥的),客户端拿到证书之后,会对证书进行校验,如果证书无效/过期等,浏览器会进行弹窗警告。
那么黑客是否会在证书上动手脚呢?
在讲解这个原因之前,我们先来看看到底什么是证书(来源百科):
包含了公钥信息、拥有者身份信息(主体)、以及数字证书认证机构(发行者)对这份文件的数字签名,以保证这个文件的整体内容正确无误。
拥有者凭着此文件,可向电脑系统或其他用户表明身份,从而对方获得信任并授权访问或使用某些敏感的电脑服务。电脑系统或其他用户可以透过一定的程序核实证书上的内容,包括证书有否过期、数字签名是否有效,如果你信任签发的机构,就可以信任证书上的密钥,凭公钥加密与拥有者进行可靠的通信。
简而言之,认证机构用自己的私钥对需要认证的人(或组织机构)的公钥施加数字签名并生成证书,即证书的本质就是对公钥施加数字签名。
判断证书篡改流程:
假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算hash值(比如md5), 结果为
BC4B2A76B9719D91
如果 hello 中有任意的字符被篡改了, 比如变成了 hella, 那么计算的 md5 值就会变化很大.
BDBD6F9CF51F2FD8。
然后我们可以把这个字符串 hello 和 哈希值1: BC4B2A76B9719D91 从服务器发送给客户端, 此时客户端如何验证 hello 是否是被篡改过?
那么就只要计算 hello 的 哈希值2(根据系统内置的公钥1,客户端使用同样的hash算法,针对其他字段再算一次hash值,得到hash2), 看看与BC4B2A76B9719D91(哈希值1)是否相等即可:
但是还有个问题, 如果黑客把 hello 篡改了, 同时也把哈希值重新计算下, 客户端就分辨不出来了,于是我们需要对传输中的哈希值1(BC4B2A76B9719D91)进行加密:
哈希值1需要通过服务器端的另外一个私钥加密(这个私钥是申请证书的时候, 证书发布机构给服务
器的, 不是客户端和服务器传输对称密钥的私钥).
然后客户端通过服务器在发送证书时候带上的公钥2进行解密, 还原出原始的哈希值1, 再进行校验。
如果黑客截取了数据,替换了证书上的公钥2,那么客户端算的hash2(根据客户端系统内置的公钥1)和前面通过证书上的公钥2(这个公钥2是被篡改的)解密出来的hash1就不相同,客户端立马就明白数据被篡改了。
另外,黑客无法获取私钥,即使自己算好新的篡改后的hash1值,也无法加密生成签名(伪造服务器的行为失败)。
Ps:公钥和私钥是配对的. 我们可以:
也可以反着用
完整流程如下:
总结:
HTTPS 工作过程中涉及到的密钥有三组: