HTTPS 我想看简单点的

前言

在平常的开发中iOS不像前端一样要接触到很多网络知识, 通常只是一个AFN就基本上不管了, 只管post,get其他的咱也不知道. 所以大部分非科班出身的移动端开发网络都相对薄弱, 今天记录一下https希望可以更清晰的表达出来.

本文只是一个入门知识, 需要深入看要进入相对应的协议中一个一个进行学习.

正文

什么是http

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上. 那么TCP又是什么, 真是让人头大.下面是OSI的一组模型图

网络分层协议.png

补一点基础, 网络七层协议也可以叫分四层, 我一般都脑子就是

应用层 应用程序可做的HTTP就是在这里要传输的数据以及头部信息, 基于TCP/IP
传输层 通过TCP进行传输(图上还有很多协议, 这里只说一个流程)
互联网层 依靠IP进行寻址
网络接口层 就是网卡和硬件大概就这么多7层无非是吧应用层分出了表示层``会话层, 网络接口层分为数据链路层和物理层, 每一层的协议想要细致学习可以自己深入.

回到HTTP

由上面大致可以了解到HTTP是属于应用层的协议，它是基于TCP/IP的，它只是规定一些要传输的内容，以及请求头信息，然后通过TCP协议进行传输，最后通过IP协议进行寻址, 找到对应的网络地址, 进行数据传输.

客户端发送和服务端响应接收,就这样就完成了一次通信.没有任何加密手段, 它是不安全的, 比如中间人进行拦截获取, 获取传输和响应的数据, 早成数据泄露. 怎么办呢?

为了解决安全问题, 加密

我们采用对称加密, 客户端和服务端使用同一个密钥M, 客户端对明文进行加密, 服务端对明文进行解密.

那么问题解决了吗?

密钥被中间人获取

加入很多客户端, 其中一个被攻破了, 中间人得到了这个密钥那么在传输的过程中, 中间人就可以随意的篡改信息.依旧没有办法完成:

这样的话, 中间人拿到密钥就可以无限的传输和获取数据了, 服务端和客户端无法验证信息真伪.

那么接下来, 我们怎么样去保证密钥的安全性呢?

对称加密密钥的传输问题

在这里首先说到, 现在最常用的就是AES高级加密标准, 需要初始化向量,一般使用CBC模式.

对于加密想不明白的不要纠结, 就把所有的加密都当做数学计算就可以了. 对称加密过程可以想象成位运算a^M^M=a, 所以就把密钥想象成一个足够大的数就可以了.
客户端a^M=d, 服务端获取到d之后, d^M得到服务端需要的数据a. 上述只是为了便于理解杜撰的, 并不是真实的实现, 为了不清楚的伙计有个大致的了解.

由于对称加密密钥的安全问题, 注定了我们不可能在传输中光明正大的传输密钥, 不管是对密钥进行在加密或者其他方式, 都无法保证传输过程中被密钥被截获破解的风险, 因此延伸出了非对称加密也叫公开加密

非对称加密

之前有写过有兴趣的可以了解一下, 非对称加密

简单概述一下就是

非对称加密需要公钥和私钥, 一般来说服务端掌管私钥, 客户端掌管公钥

一般是使用公钥加密传输给服务端, 服务端使用私钥解密获取数据.

最常用的RSA,我们苹果的证书一系列的都是这样的, 比如我们平常往下分发的p12文件, 就是私钥. 实际上RSA的原理中, 不管是公钥或者私钥都可以进行加密, 对应的去进行解密.

在openssl中, 使用公钥进行加密就是正常的-encrypt, 对应公钥解密-decrypt, 使用私钥进行加密就是-sign(签名), 公钥-verify叫法也不同. 传输过程如下:

这里我们可以保证, 我们传输的内容L在公钥M的加密下无法被攻破. 但是我们还是无法保证公钥M的安全. 假设公钥M被中间人拿到篡改.

如上图所示, 我们的整个过程还是可以被中间人攻击.

我们要继续思考, 怎么去解决或者验证我们客服端拿到的公钥是真假这么一个问题.

客户端怎么去分辨公钥真假

因为客户端无法分辨传回公钥的到底是中间人，还是服务器, 所以导致了上述这么一个问题.

在https使用了数字证书+签名的方式来解决这个问题.(假设使用的认证机构为CA)

一般情况下, 浏览器会内置一些权威三方认证机构的公钥，比如VeriSign、Symantec以及GlobalSign等等，验证签名的时候直接就从本地对应的三方机构的公钥，对私钥加密后的数字签名进行解密得到真正的签名，然后客户端利用签名生成规则进行签名生成，看两个签名是否匹配，如果匹配认证通过，不匹配则获取证书失败。

所以整个流程如下:

上述流程最后一步解释, 有些人在这儿很迷:

1. 三方机构的公钥对数字证书中的加密签名进行解密, 获取到服务端生成的签名数据S.(这个是服务端真实签名数据)
1. 获取到紫色框框中的数据, 根据签名规则, 生成签名信息S1.
1. 对比S和S1, 相等则安全, 不相等则请求失败.

如果中间人也去第三方请求公钥怎么办.

中间人拿到证书信息将公钥, 网站, 公钥加密方式等信息都改成自己的. 然后解密签名, 修改成自己的签名, 在用自己的私钥进行加密. 然后传递给客户端, 这个时候客户获取到证书, 从网站获取公钥, 解密签名, 然后是不是就又被侵入了.

这里面有几个问题:

1.首先三方认证机构改掉之后, 在客户端是会有问题的, 因为一般都是权威机构常识性.
2.中间人必须知道签名的生成规则, 才能保证客户端对比签名的解密的时候不会出错.
3.签名规则需要用到证书中基本的所有信息, 保证签名的唯一性, 所以是极其困难的.

所以上面这种情况确实有可能, 但是如果不是自家服务端内部人员可以做到这个地步, 必须要有大量的数据进行支撑研究破解, 还不一定成功. 一般侵入的第三方被发现后会被直接拉入黑名单, 想要获取大批传输数据也是极其困难的.

HTTPS流程

上述过程中

1.HTTPS使用非对称加密传输服务端公钥.
2.客户端拿到服务端公钥之后, 会随机生成一个对称加密密钥, 使用服务端公钥加密传输给服务端
3.最后服务端和客户端使用对称加密密钥, 开始进行服务端和客户端的交互.

简单点看, 就是HTTP加上一个安全验证过程, 就是HTTPS.

客户端发送支持的摘要算法方案和随机数给服务端
服务端发送摘要算法和随机数给客户端
服务端发送证书给客户端
客户端验证服务器
客户端产生随机数(pre-master secret)使用服务端公钥加密, 发送给服务端
服务端解密得到pre-master secret(相当于对称加密密钥)
客户端和服务端计算keys
客户端发送完成信号, 服务端也发送完成信号.
SSL数据传输阶段, 数据交互.

最近导师田斌全网认爹笑死我了, 我决定用我粗烂的造图技术进行一波操作和HTTPS强行绑定.

一些在线业务（比如在线支付）最重要的一个步骤是创建一个值得信赖的交易环境，能够让客户安心的进行交易，SSL/TLS 就保证了这一点，SSL/TLS 通过将称为 X.509 证书的数字文档将网站和公司的实体信息绑定到加密密钥来进行工作有时会听到x509这个词, 比较熟悉, 摘录了一下. 大概就是公开密钥证书的标准格式，这个文档将加密密钥与（个人或组织）进行安全的关联。

补充

访问同一个服务器的https, 是不必要每次都建立TLS握手的, 因为涉及到服务器证书, 密钥计算等, 需要大量的加解密以及幂运算等, 非常消耗CPU资源.

为了解决这个问题, 服务器会维护一个session ID为索引的结构体, 用于存放临时的session key, 并在TLS握手阶段分享给浏览器. 当浏览器重新链接https服务器的时候, TLS握手阶段, 传输自己的session ID, 服务器获取到, 以此为索引, 可以获得和浏览器一样的session key, 就避免了大量的计算.

优点

可认证用户和服务器，保证一定程度的安全性

缺点

耗时,性能消耗高
证书成本
ssl证书需要绑定ip，一个ip不能绑定多个域名，增加了ipv4的消耗(摘录)
加密范围有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面不起作用。ssl证书的信用链体系并不安全，在某些国家可以控制CA根证书的情况下，中间人攻击一样可行(摘录)

总结

HTTPS大方面看大概就这么点东西, 这里就是做一个简短的了解, 记录一下加深一下印象, 因为毕竟平常不怎么用. 但是里面涉及到了加密知识的巩固, 所以一般人问HTTPS可能也是想对各种加密方案的使用以及问题了解一下.

以后想起来什么在写什么吧...

如有错误, 欢迎指正.