一 生成自签名数字证书
说明:
1> 什么是证书--->带签名的公钥(公钥+签名)
2> 自签名证书的特点 ---> 不受信任,只有受CA组织签名的证书才被信任.
生成自签名证书主要步骤如下:
1> 生成私钥
$ openssl genrsa -out private.pem 1024 // 1024 表示强度,也可以是512
2> 创建证书请求 (.csr 证书请求文件)
$ openssl req -new -key private.pem -out rsacert.csr
// 注意这个证书请求发出后会询问你很多信息,
//比如: 国家,城市,公司,姓名等等,因为我们是自己签名 随便填写即可.
3> 生成证书并签名,有效期1年,也可以填写10 年都可以(.crt base64格式的证书)
openssl x509 -req -days 365 -in rsacert.csr -signkey private.pem -out rsacert.crt
// x509 表示的是一种证书的格式 ,-days 365 表示证书有效时长,
// -in rsacert.csr 生成证书的请求证书 ,
//-signkey private.pem 表示生成证书的私钥,rsacert.crt 生成的证书.
4> 将PEM格式的文件装换成DER(.der 二进制格式的证书)
openssl x509 -outform der -in rsacert.crt -out rsacert.der
// x509 证书格式, -outform der 输出证书格式 ,-in rsacert.crt( PEM格式的证书) ,
//-out rsacert.der (转换的der 格式证书,这个是公钥的证书)
5>导出p12文件 (.p12 私钥)
$ openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt
// 将我们的私钥private.pem 和证书一起导出p12文件.n
注意:
1> 在iOS开发中,不能直接使用pem 格式的证书,因为其内部进行了base64编码
2> 在iOS开发中应该使用der格式的证书,是二进制格式的.
3> Openssl 默认生成的是pen个事的证书
二 基本术语
1> "HTTP":是一个专门用来传输web内容的协议。
版本历史：
2>"SSL":是Secure Sockets Layer的缩写，翻译成中文叫做安全套接字层。上世界90年代由网景公司设计（该公司还发明了"!!!，js脚本等）,HTTP协议在传输数据的时候是明文传输的，可能存在数据泄露（被嗅探）和篡改的问题,而SSL协议就是为了解决上述问题而提出的。到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。所以，SSL和TLS可以视作同一个东西的不同阶段。
3>"HTTPS":即 HTTP + SSL
三 HTTP和TCP的关系
- 1>"HTTP协议和TCP协议"
TCP协议是HTTP协议的基石，即HTTP协议需要依靠TCP协议来传输数据。
1> HTTP是应用层协议之一。
2> TCP是传输层协议之一。
有很多应用层的协议（如HTTP|SMTP等）都以 TCP协议为基础来进行数据传输。
传输层协议主要有TCP和UDP两种，区别在于TCP协议是可靠的。
- 2 "短连接和长连接"
HTTP 对TCP连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，英文为“Keep-Alive”或“Persistent Connection”）
- 3)HTTP各个版本中TCP的连接方式
假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS 文件和 JS 文件。
> 在“短连接”的模式下，浏览器会先发起一个 TCP 连接，拿到该网页的 HTML 源代码
（拿到 HTML 之后，这个 TCP 连接就关闭了）。
然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（图片、CSS、JS）。
然后针对【每一个】外部资源，再分别发起一个个 TCP 连接，把这些文件获取到本地
（同样的，每抓取一个外部资源后，相应的 TCP 就断开）
> 相反，如果是“长连接”的方式，浏览器也会先发起一个 TCP 连接去抓取页面。
但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。
然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。
> HTTP1.0 版本默认使用短连接，也叫作一次性连接。
因为那个时候网页简单。
> HTTP1.1 版本中默认使用长连接，因为此时网页已经变得足够复杂，如果继续使用短连接的方式效率太低
（因为建立TCP连接需要时间和CPU成本）
四 HTTPS协议为什么要设计成这样？（WHY）
- 1)兼容性问题 比如：
1> 已有的web应用应该尽可能无缝的迁移到HTTPS，最好是做到零成本。
2> 浏览器厂家改动应该尽可能的小
> "HTTPS协议还是基于TCP来进行传输"
> "把HTTP协议包裹起来成为一个新的协议"
> 好比以前的HTTP协议是塑料水管容易戳破，现在就在以前塑料水管的基础上再包上一层金属管。
这样就可以做到，原有的管道能够照常运行，且不再容易被戳破。
- 2)可扩展性
SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，
来强化这些应用层协议的安全性
如果把SSL看成是一层金属管，那么他不仅能够对输水管道进行加固，
而且也能对输电管道，输煤气管道进行加固。
- 3)保密性
说白了以前是透明的塑料管道，随便花点功夫就能够知道传输的内容，
而现在能够做到足够好的保密性。
- 4)完整性
能够确保HTTP协议的内容不被修改。
因为你的网络流量需要经过 ISP 的线路才能到达公网。
如果你使用的是明文的 HTTP，ISP 很容易就可以在你访问的页面中植入广告
- 5)真实性
HTTPS 协议必须有某种机制来确保“真实性”的需求。
如何确定我们访问的网站是真实的，关于这一点仅仅根据域名来判断是不靠谱的。
因为我们的DNS系统本身就是不可靠的（域名欺骗和域名劫持），所以我们看到的网址里面的域名未必是真实的。
- 6)性能
使用HTTPS的时候性能不能太差，因此在设计的时候需要考虑两个问题：
1> 加密和解密采用什么样的方式来进行：对称加密还是非对称加密？
2> 采用什么样的连接方式：短连接还是长连接
五 设计HTTPS协议的难点
个人认为最难的地方在于对传输数据进行加密和解密这一块，也就是密钥交换。
如果客户端和服务器端需要进行HTTPS通信，那么首先需要协商双方应该采用什么样的加密算法，
确定了加密算法之后还需要传输加密和解密中可能涉及到的密钥，
而此时尚处于握手阶段，所有的数据传输都还是明文的，
那么应该如何安全的传输密钥成为最大的问题。
七 解决密钥安全传输的问题
- 1）单独使用对称加密来传输
完全使用对称加密来传输"不具备可行性"，因为如果要使用对称加密，
那么浏览器和客户端之间势必需要先交换"对称加密的密钥"。
如果这个密钥直接用明文来传输，则很有可能会被攻击者偷窥到。
2）使用非对称加密来传输 效率太低.
3）使用非对称加密+对称加密：存在中间人攻击隐患（需要具备篡改通信数据的能力）[伪造公钥][MITM].
4）正是因为"缺乏身份认证机制"，所以我们需要考虑身份认证的问题。
七 身份认证的几种方式
- 基于某些私密共享的信息 |前提——通信双方认识彼此熟悉.
2)基于双方都信任的公证人 |如果通信双方都不认识彼此，那么就只能采用该模式（如C2C）
那么，谁来充当这个公证人呢？"CA"华丽登场如何解决SSL的身份认证问题：使用CA
CA数字证书在技术实现上依赖于非对称加密技术
八 SSL协议握手的过程：
通过握手，客户端和服务器协商各种参数用于创建安全连接：
1> 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合
（加密密码算法和加密哈希函数），握手开始。
2> 服务器从该列表中决定加密和散列函数，并通知客户端。
3> 服务器发回其数字证书，此证书通常包含服务器的名称、
受信任的证书颁发机构（CA）和服务器的公钥。
4> 客户端确认其颁发的证书的有效性。
5> 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，
并将其发送到服务器，只有服务器才能使用自己的私钥解密。
6> 利用随机数，双方生成用于加密和解密的对称密钥。
以上就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。
九 HTTPS协议中关于SSL/TLS层握手过程的说明
- '阶段一：协商加密方式等参数
客户端 :
1> 我想要和你[服务端]进行安全的通话，
我这里的支持的对称加密算法有DES|AES|RC5,
密钥交换算法有RSA和DH,
消息摘要算法有MD5和SHA1|SHA256
[我说完了]
服务端 :
1> 我们使用AES-RSA-SHA256的组合方式吧。
2> 服务器端证书发送给客户端，并说[这是我的证书，
里面有我的信息和公钥，你拿去验证一下我的身份吧]。
[我说完了]
"该阶段双方已经协商好了
加密[AES]__
会话密钥交换[RSA]_
消息校验[SHA256]的一套方法。"
- '阶段二：验证证书的有效性并交换会话密钥
客户端:
1>检查证书上面的信息，并通过已有的CA证书验证服务器端证书的真实性，
如果有误则发出警告并断开连接。
2> 客户端从接收到的证书中提取出公钥
3> 生成随机数作为会话密钥，即session key,
该密钥将被在建立安全通道后用作对称加密的密钥。
4> 使用提取出来的公钥加密之前生成的会话密钥，封装成一个ClientKeyExchange消息[其实就是使用公钥对会话密钥进行加密之后的密文]。
5> 以后我就要使用session key对消息进行加密来和你进行通信了！
[我说完了]
服务端:
1> 使用自己的私钥对收到ClientKeyExchange消息进行解密，得到会话密钥，即session key。
"【注】该消息由客户端使用服务器端发送给其的公钥进行加密，所以服务器端可以使用私钥来解密。
2> 使用会话密钥加密初始化向量
"【注】如果采用的是CBC分组模式进行加密处理则需要用到初始向量
3> 加密HMAC的密钥
4> 以后我也要使用session key对消息进行加密来和你进行通信了！
[我说完了]
"该阶段完成会话密钥session key的安全交换。
- '阶段三：使用会话密钥加密消息，所有的消息在安全的信道中传输
客户端 :
1> 要发送给服务端的消息是CMsg:我的小秘密是....
2> 使用会话秘钥对CMsg进行对称加密得到密文CMsg1:xxxxxooooooo
3> 把CMsg1发送给服务器端
服务端:
1> 接收到客户端发送来的消息CMsg1:xxxxxooooooo
2> 使用本地的会话密钥对收到的消息Msg1进行解密，得到原文为CMsg:我的小秘密是....
3> 对客户端的消息进行响应，要发送给客户端的消息为SMsg:其它人不会听到的，我也有个小秘密...
4> 使用会话密钥对SMsg进行对称加密得到密文SMsg1:oooooxxxxxxx
5> 把SMsg1发送给客户端
"该阶段在传输之前使用会话密钥对所有的消息进行对称加密处理。
十 ATS (APP Transport Security)
HTTP
- 1）iOS9中新增App Transport Security（简称ATS）特性, 让原来请求时候用到的HTTP，全部都转向TLS1.2协议进行传输。
- 2）这意味着所有的HTTP协议都强制使用了HTTPS协议进行传输。
- 3）如果我们在iOS9下直接进行HTTP请求是会报错。系统会告诉我们不能直接使用HTTP进行请求，需要在Info.plist中控制ATS的配置。
"NSAppTransportSecurity"是ATS配置的根节点，配置了节点表示告诉系统要走自定义的ATS设置。 "NSAllowsAritraryLoads"节点控制是否禁用ATS特性， 设置YES就是禁用ATS功能。
HTTPS
-
4）有两种解决方法:
一种是修改配置信息继续使用以前的设置。另一种解决方法是所有的请求都基于基于"TLS 1.2"版本协议。 （该方法需要严格遵守官方的规定，如选用的加密算法、证书等）
如果发送的请求是HTTPS请求
1> 证书是受信任的,那么可以什么都不用做
2> 证书是不受信任的(自签名)
[01] 修改info.plist中控制ATS的配置。
[02] 安装并信任该证书
ATS默认的条件
1)服务器TLS版本至少是1.2版本
2)连接加密只允许几种先进的加密
3)证书必须使用SHA256或者更好的哈希算法进行签名，要么是2048位或者更长的RSA密钥，要么就是256位或更长的ECC密钥。
