SSL的那些事儿
Https，SSL 平时我们都听的挺多，知道它是用来加密的，但是对于里面的工作原理不是很清楚，所以在这里我也总结下 SSL 的工作原理，希望大家能够帮助到大家。
PS：其实这篇文章写了很久了，是在一次公司的内部培训准备的，写了几天PPT，也看了好多资料，虽然讲完了，但是一直放在自己的iCloud里了，最近又突然看到它了，想到毕竟也是花了时间在上面，还是想整理下发出来，和大家一起学习探讨。
目录
不安全的Case
SSL出现的背景
SSL的演进
SSL的工作流程
小结
一，不安全的Case
明文传输
众所周知，明文传输肯定是不安全的。下面这个例子里，A 告诉 B 的每一句话，都会被 C 看到。
密文传输
这种对称加密传输的过程是需要通信双方都能提前知道加密密钥，然后才能读懂双方发送的密文。一旦双方其中有一方泄露了加密密钥，整个通信过程就会有危险了。下面这个例子，如果 C 不管通过什么途径获取到了加密密钥，那么 C 就能看到 A 和 B 之间的通信内容了。
二，SSL出现的背景
基于万维网的电子商务和网上银行等新兴应用，极大地方便了人们的日常生活，受到人们的青睐。由于这些应用都需要在网络上进行在线交易，它们对网络通信的安全性提出了更高的要求。传统的万维网协议HTTP不具备安全机制——采用明文的形式传输数据、不能验证通信双方的身份、无法防止传输的数据被篡改等，导致HTTP无法满足电子商务和网上银行等应用的安全性要求。
与此同时，所有行业都面临着如下三大风险：
窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信。
那么什么是SSL呢？相信大家都会有这个疑问。
SSL(Secure Socket Layer)是netscape公司设计的主要用以保障在Internet上数据传输安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听。一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。
在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了简化，提出了WTLS协议（Wireless Transport Layer Security），以适应无线的特殊环境。
三，SSL的演进
在讲到SSL演进之前，还是先跟大家讲下我们的对称加密和非对称加密。
对称加密 symmetric cryptographic
简单的说就是加密和解密用的同一个密钥。常见的有DES，RC5。
优点：加解密速度快。缺点：容易暴露密钥。
公式：E(msg, key) = emsg， D(emsg, key) = msg。
非对称加密 asymmetric cryptographic
是指一对加密密钥与解密密钥，这两个密钥是数学相关，用某用户密钥加密后所得的信息，只能用该用户的解密密钥才能解密。如果知道了其中一个，并不能计算出另外一个。因此如果公开了一对密钥中的一个，并不会危害到另外一个的秘密性质。称公开的密钥为公钥；不公开的密钥为私钥。
简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
优点：安全性高，不用暴露私钥。缺点：加解密速度慢。
公式：E(msg, publickey) = emsg， D(emsg, publickey) != msg， D(emsg, privatekey) = msg。
公钥加密和私钥解密
下面这个图例子里，其实是有两个场景：
B手上是有一对密钥的，一个公钥和一个私钥，然后在A和B通信的过程中，B把公钥交给A，私钥是自己保管的，然后A就可以拿着这个公钥去加密谈话内容了，而且这个加密的内容只能是B才能解密的。流程是
1里面是一样的，主要是加密的内容换成了一个对称密钥，然后用对称密钥去保证通信安全。
但是，如果只是提供公钥和私钥，任何人都可以是 B，只要跟 C 谎称自己就是那个 B，然后提供公钥代替 B 的公钥，这样的导致的结果是 A 根本不知道自己是在跟一个假 B 在聊天，后果很严重。
证书
由于存在上面的身份不确认的问题，这里我们引入了证书来帮助证明 B 就是 B，而不是假 B。
那么什么是证书呢？ 简单的理解证书是一个包含身份ID（类似我们的身份证），和公钥信息的一个数字文件。
数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，其作用类似于司机的驾驶执照或日常生活中的身份证。它是由一个由权威机构-----CA机构，又称为证书授权（Certificate Authority）中心发行的，人们可以在网上用它来识别对方的身份。数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名
目前数字证书的格式普遍采用的是X.509V3国际标准，一个标准的X.509数字证书包含以下一些内容：
刚才上面有讲，证书其实是由 CA 发放的，这里就会牵扯到 CA 的概念了。简单点讲，CA 是一个信任中心，可以理解是跟央行一样，央行发行的纸，你信吗？ 这个纸，你当然不信，但是你信任央行啊，信任政府啊，自然这个纸它就值钱了。所以同理，CA 发放的证书自然也是真实可靠的。
CA机构，又称为证书授证（Certificate Authority）中心，作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。它负责产生、分配并管理所有参与网上交易的个体所需的数字证书，因此是安全电子交易的核心环节。由此可见，建设证书授权（CA）中心，是开拓和规范电子商务市场必不可少的一步。为保证用户之间在网上传递信息的安全性、真实性、可靠性、完整性和不可抵赖性，不仅需要对用户的身份真实性进行验证，也需要有一个具有权威性、公正性、唯一性的机构，负责向电子商务的各个主体颁发并管理符合国内、国际安全电子交易协议标准的电子商务安全证书。
数字证书颁发过程一般为：管理员只需生成“证书请求”（后缀大多为.csr），它包含你的个人信息和公钥，然后把这份请求交给诸如Globlesign，verisign等有CA服务公司（当然，连同几百美金），你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在server上导入这个证书就行了。
下图就是 CA 到 用户证书 的一个组织结构：
所以，只要引入了证书，那相当于，客户端会去获取到服务器的证书，然后会去判断这个证书是否是我们的 CA 所发放的，自然就校验了证书的合法性。最后的结构就是我们的 B 小伙终于可以证明自己了，而不用哭晕在厕所里了。
说到这里，可能有的小伙伴会问，由于商业证书都是要买的，没有钱怎么办？或者是说我们的服务都是内网的，不用考虑太多。那有什么可以满足这种诉求吗？ 既然有我们的 CA，那有没有不是 CA 的呢？ 答案是有的。就是我们可以自己来当这个非官方 CA，相当于搭建一个私服，自己玩，自己嗨。
Self-signed certificate：由自己的私钥签名而非第三方CA签发的证书。如果你不想花那笔钱，可以自己做CA，现在有一些工具（openssl，keynote）可以帮助生成自定义的CA，服务器的证书和自签名。当服务器端安装好有自定义CA签名的证书时，这个时候客户端是需要导入自定义的CA证书，意味着客户端“信任”这个CA签署的证书）。而商业CA的一般不用，因为它们已经内置在系统中了。
但是建议商业服务器还是要买个证书来保证安全。
数字签名
由于公钥加密只能协商出一个会话密钥，通过会话密钥可以保证通信的机密性。但是不能保证通信的完整性。简单的说就是证书能够保证通信的内容不被破解，但是不能保证内容被篡改。
在下面的例子里，A 小伙和 B 小伙通过一段时间的沟通已经互有好感，此时 B 小伙想要告诉 A 小伙："我喜欢你"。但是居心叵测的 C 非要过来插一脚，在后面补一句变成了："我喜欢你 我去年买了个表"，可想而知，从此世界少了一对，不知道 C 是出于什么心态啊。不管怎么样，C 成功篡改了通信内容。
那么问题来了，有什么办法可以让 A 小伙和 B 小伙在一起呢。
duang，duang，duang，数字签名来了。数字签名就是为了解决信息被篡改的干活。
数字签名是指用原文进行HASH运算得到摘要信息并用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
有了数字签名的帮助，谁都无法阻止 A 和 B 在一起了。而这一切都是 SSL 自动帮我们做了，就是这么自然，但是了解里面的原理还是很有必要的。
四，SSL的工作流程
首先来说下它的架构，SSL是一个介于HTTP协议与TCP之间的一个可选层。
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－
SSL层: 借助SSL层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求，SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果
TCP层：与web server的443端口建立连接，传递SSL处理后的数据。
SSL协议可分为部分： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
握手的过程
简单的说客户端会发出一个 ClientHello 来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，服务器端会回应一个 ServerHello，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。客户端在收到这个消息后会生成一个秘密消息，用服务器的公钥加密后传过去，然后服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来安全通信了。
举个更形象的例子：
我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...]
小结
自此，我们终于拨开了 SSL 的迷雾，SSL 一个看似简单的东西，里面涵盖了对称加密，非对称加密，证书 和 数字签名。对 SSL 感兴趣的小伙伴了解下这些还是有好处的，至少都是和我们学习工作息息相关的。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。