HTTPS=HTTP + SSL / TLS
阅读原文时间:2024年06月21日阅读:1

以下的两个链接作为本次编辑的参考

https://www.bennythink.com/school-1.html
https://www.bennythink.com/school-2.html

应一个前辈的强烈安利,并且经过他的一番刻苦指导,总结了一下关于为什么要用HTTPS以及HTTPS是如何实现的知识

首先先说说HTTP

HTTP协议(HyperTextTransfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议,是一个基于TCP/IP 协议的应用层协议。

但是HTTP协议由诸多不足,比如说:

1 . 通信使用明文(也就是不加密),内容可能被窃听
2 . 不验证对方身份,可能遭遇伪装
3 . 无法证明报文的完整性,报文可能被篡改

于是为了防止以上的不安全的情况发生人们普遍会想到把浏览器和服务器之间的通信在HTTP的基础上进行加密,也就是把通信间的数据进行加密, 对原来为明文的文件或数据按某种算法进行处理,让其成为不可读的一段代码,通常称为“密文”,使其只能在输入相应的密钥之后才能显示出本来内容,通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。

加密的技术通常分为两大类:对称式加密技术和非对称式加密技术

1、对称加密技术:

通俗来说对称式加密也就是说加密和解密使用同一个密钥。

2、非对称加密技术:

而非对称式加密就是加密和解密所使用的不是同一个密钥,也就是说通常有两个密钥,分别称为“公钥”和“私钥”,它们两个必需配对使用,否则不能打开加密文件。“公钥”顾名思义也就是可以对外公布的,“私钥”就是私有的,只能由持有人一个人知道的。而且有一个好处就是,公钥和私钥没有必然的联系,也就是完全没有关系的两个密钥,通俗说:也就是公钥无法推出私钥,相反私钥也无法推出公钥。

接下来我们开始了给HTTP发送和接收的数据进行加密处理

1、首先假设我们单独用对称加密技术进行加密:

也就是说浏览器把要发送的数据用密钥进行加密,发送给服务器,那么问题来了,本次回话的密钥密钥怎么交给服务器,如果不给服务器,那岂不是服务器也不知道浏览器发的是什么,也就无法回应浏览器了,所以瞬间陷入了一个死循环, 所以算法和密钥泄露,加密也就就无意义了。于是这个方法被pass掉了。

2、然后我们开始想使用单独的非对称加密技术:

也就是说浏览器用公钥把数据进行加密,然后服务器再根据私钥进行解密, 因为私钥是私密的,所以算法和公钥公开也是无法解密,也就是说此时是安全的,服务器解密了数据报,但是,想要把响应的数据报加密发送给浏览器,应该拿什么加密!于是这个方法也被pass掉了。

3、把对称和非对称一起考虑:

  • 第一步:

服务器先基于非对称加密,随机生成一对密钥(K1,K2)

  • 第二步:

服务器吧k1保留,把k2发送给浏览器(k2有可能被偷窥,但是没有关系,因为K1和K2没有联系)

  • 第三步:

浏览器拿到K2后,首先随机生成一个对称加密的密钥(K)
然后用K2加密K,得到K' (K'是一个加密的结果)
浏览器把K'发送给服务器
由于K1和K2 是一对非对称的密钥,所以只有K1能够解密K2 加密的结果
因此这个过程中,即使被偷窥,偷窥者也无法从K'解密得到K

  • 第四步:

服务器拿到K'后,用K1 进行解密,也就是得到了K
到现在为止 ,浏览器和服务器之间完成了密钥的交换,也就是说,双方都知道K,貌似偷窥者也无法拿到K,接下来,浏览器和服务器就可以用K来进行数据的双向传输的加密了。

但是!!!!!!!!!!!!!!!!!!!!!!!!!!!!!但是!!!!!!!!!!!!!!!
假设有个攻击者,他在A和B的中间,对A称自己的B,对B称自己是A,那么他就可以随意的篡改信息,

通俗点说就是你和我语言不通,需要翻译,那么这个翻译实际上就充当了我们两个之间的中间人,我们说了什么他都知道,而且还能随意的篡改信息,也就是所说的中间人攻击。于是这个方法也被pass掉了。

那么我们想想为什么第三种方法行不通?因为他 缺乏有效的身份认证机制,也就是说, 浏览器不知道跟它通信的是真正的服务器还是别人伪装的服务器。所以引进了CA证书,也就是双方都信任的“公证人 ”

CA证书

关于CA证书可以参考以下链接,写的很详细,很棒
https://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html

HTTPS

墨迹半天终于说到正题HTTPS了
众所周知 HTTPS能够加密信息,以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

隐私性:通信无法别劫持(理论上不可能做到)
保密性:防止被嗅探,即使被嗅探了也无法解密、也就等于防止泄密了
正确性(认证):发送给了真正的接受者
完整性:通信完整无缺,防止篡改。

HTTPS不是一种新的协议,是HTTP + SSL/TLS, 也就是在TCP(负责网络数据传输)和HTTP层之间,增加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过SSL/TLS进行加密,所以传输的数据都是加密后的数据。


  其中SSL是Secure Sockets Layer安全套接层的缩写,TLS Transport Layer Security缩写,传输层安全协议
  SSL是比较古董的、使用广泛的,后来人们给他标准化了,就叫TLS了,也就是说SSL和TLS是不同事物在不同阶段的名称

具体加密解密的过程如下所示:

浏览器向服务器发一个请求

服务器配置一套证书:这套证书其实就是一对公钥和私钥相当于我上面说的(K1,K2)。

服务器传送证书中的公钥(K1)给浏览器,其中也包含了很多信息,如证书的过期的时间啊等。

浏览器吧证书公钥解析,由SSL/TLS来完成,首先会验证公钥是否有效,如果有异常情况,就会弹出一个警告,提示证书有问题。否则,就生成一个随机的值(相当于上面说的K)。然后用证书中的公钥对该随机值进行加密。得到的加密后的随机值(相当于面说的K')发送给服务器,以后浏览器和服务器之间的的通信就可以用这个随机值(K)来进行加密解密了。

于是就实现了我们通常所说的安全的传输HTTPS。

没有绝对意义上的好嘛

在这里我也不得不说一下HTTPS本身也是存在一些弊端的:

就比如说SSL/TLS证书存在滥用问题,一些著名证书授权机构错误地签名了大量的伪造和欺诈的证书,直接损害数以万计的Mozilla用户的安全。

NSA( 美国国家安全局) 为了解密,不遗余力地收集着 SSL/TLS 流量(但是好几年前的事情了,现在已经解决了,我简单的查了一下,效率也相当的高)

等等(还有一些漏洞等等,我大概查了一下,但是基本上都是很快就解决了。)

但是在网络化科技发达的今天,所谓的网络安全是很重要的,非常重要的(也可以这么说),所以相对于 传统意义上的不安全的HTTP, 毫无疑问,你应该使用HTTPS。