iOS :HTTPS简析

2,953 阅读10分钟

前言

App的安全问题是我们在开发过程中每个人都会遇到的,而由于iOS平台的封闭性,遭遇到的安全问题相比于Android来说要少得多。但除系统安全之外,我们还是面临很多的安全问题:比如网络安全,下面就简单的了解一下HTTPS是怎么处理网络安全问题的。

HTTPS

下面就来了解一下HTTPS;😺

HTTPS的重要性

我们知道HTTP本身是不具备加密功能的,所以也无法做到对通信整体(使用 HTTP 协议通信的请求和响应的内 容)进行加密。即,HTTP 报文使用明文方式发送。可是不光在HTTP协议中,在其他未加密的协议中都会存在类似问题:

1️⃣:通信过程中使用的是未加密的明文,内容会被取抓。

2️⃣:对于服务器或者客户端来说,不会验证通信方的身份,因此有可能遭到中间人的伪装。

3️⃣:无法验证所发送报文的完整性和安全性,而且报文的内容也有可能是中间人篡改之后发送过来的。

为了统一解决上述这些问题,需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制 的 HTTP 称为 HTTPSHTTPS开发的主要目的,是提供对网络服务器的身份认证,保护交换数据的隐私与完整性。

HTTPS介绍

HTTPS超文本传输安全协议是一种网络安全传输协议。在计算机网络上,HTTPS经由超文本传输协议HTTP进行通信,但利用SSL/TLS来加密数据包。TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCPHTTP之间的一层安全协议,不影响原有的TCP协议和HTTP协议,具有身份验证、信息加密和完整性校验的功能。

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

HTTP + 加密 + 证书 + 完整性保护 = HTTPS

加密方式

在了解HTTPS通信加密过程之前先来了解几个基本概念:

密钥

密码学中:密钥是一种参数,它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。

对称加密(共享密钥加密)

加密和解密同用一个秘钥的方式称为对称加密

也就是说在发送密文的同时,也会把密钥发送给对方。

举个小例子🌰:比如我想寄一些贵重的东西给女朋友,然后我就搞了个保险柜,然后把物品存在保险柜里(💰💰💰),然后我在锁好保险柜之后,把保险柜邮寄出去,然后把保险柜密码告诉女朋友,可是不小心隔墙有耳👂,有人听到了这个密码,那么完蛋了,我的保险柜有危险了。这里物品就是明文信息,保险柜就是加密后的密文,保险柜密码就是密钥,你看这样是不是不安全?

⚠️⚠️:注意这里有个危险,如果不发送密钥给对方,对方就无法解密,但是如果在发送密钥的过程中,密钥有可能会被截获,一旦密钥泄漏,密码也就有可能被破解。那么怎么解决这个问题呢?🤔🤔🤔

那就是下面这个非对称加密了!!!👇👇👇

非对称加密(公开密钥加密)

非对称加密使用一对非对称密钥,一个叫私有密钥,另一个叫公开密钥公有密钥随意发送,任何人都可以获得,私有密钥不让任何人知道。

也就是说,发送密文方使用对方的公开密钥进行加密,对方接受到加密信息后,再使用自己的私有密钥进行解密。利用这种方式不再需要发送密钥,也不用担心密钥被中间人获取。重要的是在不使用私有密钥情况下很难还原被加密的信息。(就好比把熟鸡蛋🥚还原成生鸡蛋🥚)

再来举个例子🌰:经过上次的事情之后,我学聪明了,我买了一个高级的保险柜,这个保险柜有两个密码,一个锁上的密码,一个打开的密码,然后女朋友设置完这两个密码之后,把锁上的密码告诉我了,然后我把物品装到保险柜之后,再次寄出去,这次就不怕别人知道密码了,因为打开保险柜的密码,只有女朋友知道,其他人即是知道保险柜锁上的密码也没有任何用。

HTTPS混合加密

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

利用两种加密方式互补,也就是说,利用非对称加密方式安全地交换在对称密钥加密中要使用的密钥,在确保密钥安全前提下,使用对称密钥加密方式进行通信。

进行到这里会不会觉得一切都结束了,HTTPS安全加密的问题搞定了,其实这里还存在另外一个安全隐患😨😨😨:由于公钥是透明公开的,在公钥的传输过程中,正确的公钥有可能会被中间人攻击而替换掉,则可能造成数据的篡改。那么如何证明收到的公开密钥是原本预想那台服务器发行的密钥呢?🤔🤔🤔

数字证书

为了解决上述问题,可以使用由数字证书认证机构(CACertificate 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》一书