密码学09--SSL与TLS认证概述
目录
1.相关名词
1.1 公钥证书PKC
1.2.公钥基础设置PKI
1.3 SSL和TLS
2.SSL和TLS工作原理
2.1 握手准备
2.2 第一次握手
2.3 第二次握手
2.4 第三次握手
3.应用SSL/TLS的HTTPS优势与弊端
3.1 优势
3.2.缺陷
4.PKCS的15个标准
4.1 名称
4.2 标准
5.Mac环境下通过OpenSSL生成根证书
5.1 OpenSSL由来
5.2 HeartBleed
5.3 Mac OSX与OpenSSL
5.4 Mac 环境安装新版OpenSSL
5.5 颁发自签名证书
1.相关名词
1.1 公钥证书PKC
公钥证书（public-key certificate）是使用证书机构CA的私钥对个人公钥进行数字签名后生成的文件，一般简称证书。
1.2.公钥基础设置PKI
公钥基础设施（Public-Key infrastructure）是为了能够更有效地运用公钥而制定的一系列规范和规格的总称。
1.3 SSL和TLS
SSL（Secure Socket Layer，安全套接层）是NetScape利用数据加密(Encryption)技术所研发的，用以保障在Internet上数据传输之安全、确保数据在网络上之传输过程中不会被截取及窃听的技术。
TLS（Transport Layer Security，传输层安全性协议）是SSL技术的升级版本，目的也是为互联网中的通信提供数据的机密性和完整性保障，目前TLS已经成为互联网中保密通信的工业标准。
ps：SSL最大版本为3.0版本，而TLS1.0则相当于SSL3.0之后的一个版本，并且TLS 1.0包括了可以降级到SSL 3.0的实现。
2.SSL和TLS工作原理
感谢http://www.cnblogs.com/bhlsheji/p/4586597.html对SSL工作原理的细致介绍，本文中一些内容也借鉴了其博客内的相关知识。在这里细节部分就不再赘述来班门弄斧，详细内容可以去上述博客中查看。在这里主要说明SSL和TLS的双向认证过程，即三次握手认证工作原理。
2.1 握手准备
客户端与服务端如果想要进行SSL或TLS通信(以下简称ST通信)，那么必须双端都预先在CA中进行公钥认证操作从而获得公钥证书，这证书是后续的握手操作中用来验明双端身份的重要标识。当然这个操作并不是在开始握手通信之前才能执行，而是可以在预备通信之前预先准备好。例如：双端预先生成密钥对，然后私钥留存，公钥则交付给CA来注册双端公钥证书留待校验使用。
2.2 第一次握手
所谓的握手，其实就是客户端和服务器之间的一次“来回”数据传递。第一次握手通常是客户端向服务器首先发送数据，因为从客观上来说客户端一般都作为用户使用者的身份，用户总是希望获得某些服务，那么对用户而言享受服务之前先确认对方是自己需要的服务的提供者这个确认操作必然是用户身份先发起。所以：
（1）客户端会首先向服务器通过url地址发送消息（message），发送客户端的SSL/TLS规格、能够支持的加密算法（也就是稍后完成身份验证之后，用于通信的密钥长度，说白了就是对称加密密钥的长度）等信息。
（2）服务器接收到客户端通过url地址发来的消息（message），此时消息并不是加密处理的（还没开始通信，怎么可能加密）。服务器此时需要将客户端发来的SSL/TLS版本等信息与自己支持的进行校验，如果能够匹配则通信继续，否则直接断开链接（客户端会得到通信失败之类的信息）即可。
（3）当服务器对客户端发来的消息校验完毕后，将如下内容打包作为刚刚请求的响应反馈给客户端，至此SSL/TLS的第一次握手完毕。
- 双方用于通信的加密算法信息
- 服务器经过CA公正的服务器公钥证书
- 服务器向客户端发起客户端经过CA公正的客户端公钥证书
- 附带回应：刚刚的从客户端发来的消息接收成功
2.3 第二次握手
第二次握手的发起人仍然是客户端，因为在第一次握手完毕后服务器将SSL/TLS加密通信的必要信息全都发送到了客户端。那么是否继续进行握手就必然还是由客户端来发起。所以：
(1)客户端收到服务器第一次回应后应当首先执行VSC（Verify Server CA Certification，对服务器身份进行校验），而不是立即给出回应。由于刚才服务器已经将它经过CA公正过的公钥证书发送过来，所以通过去CA信任链中的机构认证这份证书是否的确是由客户端想要访问的url地址发出，就能够确认服务器真实身份（核验并不是只核验url，比如服务器证书颁发机构的可信度、证书的有效期之类的）。当然，如果CA给出了你这个证书并不是想要访问的服务器发送给你的，那就说明你第一次握手的url地址已经收到了 欺诈或者篡夺，那么也就意味着你如果继续使用这个证书进行通信就是不安全的。客户端或者说浏览器就会给出类似“该链接可能包含木马或者不安全信息”等警告字样，从而阻止客户端对服务器的继续通信，通信也就终止。
(2)如果核验通过那么此时客户端需要生成一个用于通信消息加密的对称加密key，然后通过刚刚的服务器公钥证书对这个对称加密key进行加密。而后当加密数据准备完毕后向服务器发起第二次握手通信，通信内容应当包括：
- 使用服务器公钥证书进行加密的对称加密key数据
- 客户端自己的公钥证书（这个是否使用服务器公钥证书加密都无所谓，毕竟公钥证书必须CA公正才能生效，基本不存在篡夺可能）
- 使用服务器公钥证书进行加密的服务器公钥证书校验结果，这个结果用于告知服务器我客户端已经对你校验通过。
(3)服务器接收到客户端的第二次握手通信数据，依然首先执行VCC（Verify Client CACertification，对客户端身份进行校验），而不是立即给出回应。此时服务器对证书的校验过程和客户端对证书的校验过程基本完全相同，所以不做过多说明。当校验证书通过后就能够通过本地的服务器私钥去解析客户端发来的通过服务器公钥加密的数据，这次解析能够得到对称加密key和客户端给出的回应信息。
(4)当校验客户端身份完毕后，服务器需要对客户端发来的第二次握手通信给出回应。由于此时服务器已经获知了客户端发来的用于后续通信加密的对称加密key，因此服务器直接将客户端公钥证书的校验结果用对称加密key加密后反馈客户端，告知客户端我服务器对您的校验通过。至此SSL/TLS的第二次握手完毕
2.4 第三次握手
第三次握手是身份确认的最后一步，在前两次握手操作中服务器和客户端互相之间的确通过CA验明了身份，并且服务器知道自己的确收到了客户端发来的对称加密key，但是此时客户端还不知道【服务器已经收到了对称加密key】这件事，所以第三次握手与其说是身份验证的最后一步，不如说是让客户端确认通过对称加密key加密发送的数据能够被服务器解读这件事。所以：
(1)客户端收到服务器发来的第二次握手的反馈内容，经对称加密key解密获知服务器已经知道了用于数据传递的对称加密key。于是客户端向服务器发起第三次握手通信。本次握手发送一次对称加密key加密的消息通信，而通信内容只有一个内容就是：告知服务器，我客户端已经准备完毕，接下来的所有通信都要通过对称加密key来完成数据传递了。
(2)服务器接收到第三次握手通信消息，使用对称加密key完成消息解密之后获知客户端已经准备完毕，随后通过对称加密key向客户端也发送一次握手消息回应，而回应内容也只有一个：告知客户端，我服务器也已经准备完毕，接下来所有同科可以通过对称加密key来完成数据传递了。至此SSL/TLS的第三次握手完毕，三次握手全部完成。
3.应用SSL/TLS的HTTPS优势与弊端
3.1 优势
- 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
- HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
- 谷歌曾在2014年8月份调整搜索引擎算法，并称 “比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
3.2.缺陷
- HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
- HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
- SSL/TLS证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
- SSL/TLS证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
- HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
4.PKCS的15个标准
4.1 名称
PKCS，即Public-Key Cryptography Standards 。是由 RSA 实验室与其它安全系统开发商为促进公钥密码的发展而制订的一系列标准。这时它的官网：What is PKCS
4.2 标准
PKCS 目前共发布过 15 个标准，其中PKCS1就是我们之前在加密或认证或签名中使用频率最高的一种加密标准。
PKCS#1：RSA加密标准。==PKCS#1定义了RSA公钥函数的基本格式标准，特别是数字签名==。它定义了数字签名如何计算，包括待签名数据和签名本身的格式；它也定义了PSA公/私钥的语法。
PKCS#2：涉及了RSA的消息摘要加密，这已被并入PKCS#1中。
PKCS#3：Diffie-Hellman密钥协议标准。PKCS#3描述了一种实现Diffie- Hellman密钥协议的方法。
PKCS#4：最初是规定RSA密钥语法的，现已经被包含进PKCS#1中。
PKCS#5：基于口令的加密标准。PKCS#5描述了使用由口令生成的密钥来加密8位位组串并产生一个加密的8位位组串的方法。PKCS#5可以用于加密私钥，以便于密钥的安全传输（这在PKCS#8中描述）。
PKCS#6：扩展证书语法标准。PKCS#6定义了提供附加实体信息的X.509证书属性扩展的语法（当PKCS#6第一次发布时，X.509还不支持扩展。这些扩展因此被包括在X.509中）。
PKCS#7：密码消息语法标准。PKCS#7为使用密码算法的数据规定了通用语法，比如数字签名和数字信封。PKCS#7提供了许多格式选项，包括未加密或签名的格式化消息、已封装（加密）消息、已签名消息和既经过签名又经过加密的消息。
PKCS#8：私钥信息语法标准。PKCS#8定义了私钥信息语法和加密私钥语法，其中私钥加密使用了PKCS#5标准。
PKCS#9：可选属性类型。PKCS#9定义了PKCS#6扩展证书、PKCS#7数字签名消息、PKCS#8私钥信息和PKCS#10证书签名请求中要用到的可选属性类型。已定义的证书属性包括E-mail地址、无格式姓名、内容类型、消息摘要、签名时间、签名副本（counter signature）、质询口令字和扩展证书属性。
PKCS#10：证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了一个唯一识别名、公钥和可选的一组属性，它们一起被请求证书的实体签名（证书管理协议中的PKIX证书请求消息就是一个PKCS#10）。
PKCS#11：密码令牌接口标准。PKCS#11或“Cryptoki”为拥有密码信息（如加密密钥和证书）和执行密码学函数的单用户设备定义了一个应用程序接口（API）。智能卡就是实现Cryptoki的典型设备。注意：Cryptoki定义了密码函数接口，但并未指明设备具体如何实现这些函数。而且Cryptoki只说明了密码接口，并未定义对设备来说可能有用的其他接口，如访问设备的文件系统接口。
PKCS#12：个人信息交换语法标准。PKCS#12定义了个人身份信息（包括私钥、证书、各种秘密和扩展字段）的格式。PKCS#12有助于传输证书及对应的私钥，于是用户可以在不同设备间移动他们的个人身份信息。
PDCS#13：椭圆曲线密码标准。PKCS#13标准当前正在完善之中。它包括椭圆曲线参数的生成和验证、密钥生成和验证、数字签名和公钥加密，还有密钥协定，以及参数、密钥和方案标识的ASN.1语法。
PKCS#14：伪随机数产生标准。PKCS#14标准当前正在完善之中。为什么随机数生成也需要建立自己的标准呢？PKI中用到的许多基本的密码学函数，如密钥生成和Diffie-Hellman共享密钥协商，都需要使用随机数。然而，如果“随机数”不是随机的，而是取自一个可预测的取值集合，那么密码学函数就不再是绝对安全了，因为它的取值被限于一个缩小了的值域中。因此，安全伪随机数的生成对于PKI的安全极为关键。
PKCS#15：密码令牌信息语法标准。PKCS#15通过定义令牌上存储的密码对象的通用格式来增进密码令牌的互操作性。在实现PKCS#15的设备上存储的数据对于使用该设备的所有应用程序来说都是一样的，尽管实际上在内部实现时可能所用的格式不同。PKCS#15的实现扮演了翻译家的角色，它在卡的内部格式与应用程序支持的数据格式间进行转换。5.Mac环境下通过OpenSSL生成根证书
5.1 OpenSSL由来
OpenSSL 是一个安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议，并提供丰富的应用程序供测试或其它目的使用。
5.2 HeartBleed
OpenSSL在2014年4月被曝出现严重安全漏洞后，发现多数通过SSL协议加密的网站使用名为OpenSSL的开源软件包。OpenSSL漏洞不仅影响以https开头的网站，黑客还可利用此漏洞直接对个人电脑发起“心脏出血”（Heartbleed）攻击。据分析，Windows上有大量软件使用了存在漏洞的OpenSSL代码库，可能被黑客攻击抓取用户电脑上的内存数据。
5.3 Mac OSX与OpenSSL
Mac OSX一般自带的有OpenSSL。但因为上述OpenSSL“HeartBleed”事件，Mac OSX 自 10.11 El Capitan 起，将原有的 OpenSSL 替换为 LibreSSL 。在以上这些系统中应该除了实测必须要用 OpenSSL 软件外，应该都可以用 LibreSSL 取代 OpenSSL。而对于其他大多数还没有将系统自带的 OpenSSL 替换为 LibreSSL 的会麻烦一些，并且也可能做不到彻底替换。只是对于编译安装的软件，可以尽量用 LibreSSL 取代 OpenSSL。（其他用LibreSSL 取代 OpenSSL的系统还有：OpenBSD 自 5.6 起，Alpine Linux 自 3.5.0 起）例如：现在使用Mac OSX 10.11 或以后的更高版本，通过终端命令openssl version可以看到本地显示的是LibreSSL的版本：
～/ $ openssl version
LibreSSL 2.2.7
此外苹果现在是弃用OpenSSL，使用他自己维护的TLS和加密库。
5.4 Mac 环境安装新版OpenSSL
如果你看了我之前的博客，就知道在Mac环境下Homebrew是个好东西：OpenSSL可以通过brew指令来完成下载更新的各种操作。
- 确认已安装的openssl的版本和位置：【～/ $ which openssl】
- 确定版本：【～/ $ openssl version】
- brew安装openssl：【～/ $ brew install openssl】
- brew更新openssl：【～/ $ brew upgrade openssl】
- brew强制链接到openssl：【～/ $ brew link openssl --force】
5.5 颁发自签名证书
颁发自签名证书虽然听起来有点臭不要脸，毕竟自己给自己发个证书有什么用？别人又不承认。其实自签名证书可以在开发测试或者公司内部使用，毕竟一个CA机构认证的证书少则好几百，多则好几千甚至上万。所以秉持程序员节约精神，那就能省则省吧。
(1)随便创建一个路径，这个路径用来存放密钥、中间文件和最终颁发证书
(2)然后在这个路径下进入终端命令，执行【～/ $ openssl】
(3)通过openssl工具生成一个RSA私钥，注意私钥生成的时候需要提供一个至少4位的密码(一会不用可以删掉)。
#默认加密算法采用des3加密，当然也可以算则des或者aes。
#私钥名称随便写，这个名字就是最终私钥的名字。
#密钥长度是生成的密钥内容bit数，2014年往后，国际标准化组织要求密钥长度不允许小于2048
genrsa -加密算法 -out 私钥名称.key 密钥长度这步执行完，会在路径下生成一个.key密钥
(4)生成CSR证书请求中间文件
#私钥名称必须是刚刚生成的私钥名称
#中间文件名不用必须是和私钥名称一样，但通常一致避免记忆混淆
req -new -key 私钥名称.key -out 中间文件名.csr这步执行完，会在路径下生成一个.csr中间文件
(5)[可选] 删除私钥中的密码, 第一步给私钥文件设置密码是必须要做的, 但是如果不想要可以在这一步删掉
#一般如果不需要私钥有密码，那么就把私钥名称和后面的名称写一样就可以了
rsa -in 私钥名称.key -out 删除密码后的私钥名称.key(6)生成自签名证书
#证书有效时间：写数字就行。例如365就是一年有效期，730就是两年有效期
#中间文件名：刚刚生成的中间文件名字
#私钥名称：刚刚生成发的私钥的名字
#自签名证书名：随便起，反正这个就是最终自己给自己颁发的证书
x509 -req -days 证书有效时间 -in 中间文件名.csr -signkey 私钥名称.key -out 自签名证书名.crt