前言
App
的安全问题是我们在开发过程中每个人都会遇到的,而由于iOS
平台的封闭性,遭遇到的安全问题相比于Android
来说要少得多。但除系统安全之外,我们还是面临很多的安全问题:比如网络安全,下面就简单的了解一下HTTPS
是怎么处理网络安全问题的。
HTTPS
下面就来了解一下HTTPS
;😺
HTTPS的重要性
我们知道HTTP
本身是不具备加密功能的,所以也无法做到对通信整体(使用 HTTP
协议通信的请求和响应的内
容)进行加密。即,HTTP
报文使用明文方式发送。可是不光在HTTP
协议中,在其他未加密的协议中都会存在类似问题:
1️⃣:通信过程中使用的是未加密的明文,内容会被取抓。
2️⃣:对于服务器或者客户端来说,不会验证通信方的身份,因此有可能遭到中间人的伪装。
3️⃣:无法验证所发送报文的完整性和安全性,而且报文的内容也有可能是中间人篡改之后发送过来的。
为了统一解决上述这些问题,需要在 HTTP
上再加入加密处理和认证等机制。我们把添加了加密及认证机制 的 HTTP
称为 HTTPS
。HTTPS
开发的主要目的,是提供对网络服务器的身份认证,保护交换数据的隐私与完整性。
HTTPS介绍
HTTPS
超文本传输安全协议是一种网络安全传输协议。在计算机网络上,HTTPS
经由超文本传输协议HTTP
进行通信,但利用SSL/TLS
来加密数据包。TLS/SSL
全称安全传输层协议Transport Layer Security
, 是介于TCP
和HTTP
之间的一层安全协议,不影响原有的TCP
协议和HTTP
协议,具有身份验证、信息加密和完整性校验的功能。

HTTP
协议直接放置在TCP
协议之上,而HTTPS
则是在HTTP
和TCP
中间加上一层加密层SSL
。从发送端看,这一层负责把HTTP
的内容加密后送到下层的TCP
,从接收方看,这一层负责将TCP
送来的数据解密还原成HTTP
的内容。所以严格地讲,HTTPS
并不是一个单独的协议,而是对工作在一加密连接TLS/SSL
上的常规HTTP
协议的称呼。
HTTP + 加密 + 证书 + 完整性保护 = HTTPS

加密方式
在了解HTTPS
通信加密过程之前先来了解几个基本概念:
密钥
密码学中:密钥是一种参数,它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。
对称加密(共享密钥加密)
加密和解密同用一个秘钥的方式称为对称加密

举个小例子🌰:比如我想寄一些贵重的东西给女朋友,然后我就搞了个保险柜,然后把物品存在保险柜里(💰💰💰),然后我在锁好保险柜之后,把保险柜邮寄出去,然后把保险柜密码告诉女朋友,可是不小心隔墙有耳👂,有人听到了这个密码,那么完蛋了,我的保险柜有危险了。这里物品就是明文信息,保险柜就是加密后的密文,保险柜密码就是密钥,你看这样是不是不安全?
⚠️⚠️:注意这里有个危险,如果不发送密钥给对方,对方就无法解密,但是如果在发送密钥的过程中,密钥有可能会被截获,一旦密钥泄漏,密码也就有可能被破解。那么怎么解决这个问题呢?🤔🤔🤔
那就是下面这个非对称加密了!!!👇👇👇
非对称加密(公开密钥加密)
非对称加密使用一对非对称密钥,一个叫私有密钥,另一个叫公开密钥公有密钥随意发送,任何人都可以获得,私有密钥不让任何人知道。


HTTPS混合加密
从上面我们可以了解到,对称加密解密的速度比较快,适合数据比较长时的使用,但是缺乏安全性,非对称加密和解密花费的时间长、速度相对较慢,只适合对少量数据的使用,但是相对安全,任何一种方式都无法满足HTTPS
:所以HTTPS
采取混合加密的方式;

进行到这里会不会觉得一切都结束了,HTTPS
安全加密的问题搞定了,其实这里还存在另外一个安全隐患😨😨😨:由于公钥是透明公开的,在公钥的传输过程中,正确的公钥有可能会被中间人攻击而替换掉,则可能造成数据的篡改。那么如何证明收到的公开密钥是原本预想那台服务器发行的密钥呢?🤔🤔🤔
数字证书
为了解决上述问题,可以使用由数字证书认证机构(CA
,Certificate Authority
)和其相关机关颁发的公开密钥证书。
https协议中身份认证的部分是由CA
数字证书完成的,证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL
请求后,服务端会将数字证书发给客户端,客户端会对证书进行验证(验证这张证书是否是伪造的?也就是公钥是否是伪造的),如果证书不是伪造的,客户端就获取用于对称密钥交换的非对称密钥(获取公钥).
数字证书有三个作用:
1️⃣:身份授权,确保浏览器访问的网站是经过CA
验证的可信任的网站。
2️⃣分发公钥,每个数字证书都包含了注册者生成的公钥(验证确保是合法的,非伪造的公钥)。在SSL
握手时会通过certificate
消息传输给客户端。
3️⃣:验证证书合法性,客户端接收到数字证书后,会对证书合法性进行验证。只有验证通过后的证书,才能够进行后续通信过程。
那么怎么就能保证这个公开密钥是一个正确的公钥,而不是由中间人伪造的呢?
下面来看一下CA
证书的申请流程:

web
网站的证书:

GlobalSign Root CA
是指受信任的根证书颁发机构GlobalSign Domain Validation CA - SHA256 - G2
是指受信任的根证书颁发机构下的中级证书颁发机构juejin.in
是指用户的SSL
证书(是在"受信任的根证书颁发机构"下的"中级证书颁发机构"下颁发的证书)
这个三级证书是我们将自己生成的CSR
提交给签名商,他们用中级证书机构的私钥Private
Key
给我们的签名成证书。而他们的的证书又是通过Root CA
颁发的(即Root CA
通过它的私钥对中级机构提交的CSR
进行了签名)。
HTTPS通信机制
经过上面的简单了解,大概已经知道了HTTPS
的一个简单流程,在HTTPS
的实际应用中,使用的就是数字证书这种校验方式。
下面通过一个流程图来了解一下HTTPS
通信机制:

以上流程图可以总结为一下几个步骤:
1️⃣:客户端发起请求,以明文传输请求信息,包含SSL
版本信息,加密套件候选列表,随机数random_c
,扩展字段等信息。
2️⃣:服务端返回选择使用的协议版本,选择的加密套件,选择的压缩算法、随机数random_s
等,其中随机数用于后续的密钥协商。服务端也会配置并返回对应的证书Certificate
,用于身份验证与密钥交换。然后会发送Server Hello Done
信息用于通知服务端信息发送结束。
3️⃣:客户端对收到的证书进行校验,校验其合法性。
4️⃣:证书验证合法后, 客户端计算产生随机数字Pre-master Key
(预设主密钥),并用服务端证书中的公钥加密,然后发送给服务端。同时客户端会根据已有的三个随机数根据相应的生成协商的通信密钥(预主密钥+两个随机数通过复杂算法生成真正的传输密钥)。客户端会通知服务端后续的通信都采用协商的通信密钥和加密算法进行加密通信。然后客户端发送Finished
消息用于通知客户端信息发送结束。
5️⃣:服务端利用私钥解密得到预主密钥,也会根据已有的两个随机数使用相应的算法生成通信密钥,然后会通知客户端后续的通信都采用协商的通信密钥和加密算法进行加密通信。然后发送Finished
消息用于通知服务端信息发送结束。
6️⃣:客户端和服务器数据传输开始使用通信密钥进行加密通信。直到客户端发送断开连接的报文。
为什么不一直使用 HTTPS
这里可能会有疑问,既然 HTTPS
那么安全可靠,那什么还会见到有网站使用HTTP
呢,为何所有的 Web
网站不一直使用 HTTPS
?
因为加密通信会消耗更多的 CPU
及内存资源。如果每次通信都 加密解密,会消耗相当多的资源。这对于访问量较大的网站来说是有一定的压力的。因此,如果是非敏感信息则使用 HTTP
通信,只有在包含个人信息,密码等敏感数据时,才利用 HTTPS
加密通信。比如http://www.zhenai.com/
除此之外,想要节约购买证书的开销也是原因之一。
要进行 HTTPS
通信,证书是必不可少的。而使用的证书必须向认证机构(CA
)购买。证书价格可能会 根据不同的认证机构略有不同。那些购买证书并不合算的服务以及一些个人网站,可能只会选择采用 HTTP
的通信方式。
总结
HTTPS
就是要使客户端与服务器端的通信过程得到安全保证。HTTPS
利用非对称加密建立连接,利用对称加密进行数据通信,数字认证等等,虽然过程很复杂,在保证安全的同时,也提高访问速度。所以为了保证数据的安全,维护网络稳定,还是要多使用HTTPS
协议。
文中如有错误还请各位大佬指出。
感谢《图解HTTP》一书
