ssl访问的原理

　　本文无图文对照解释，但力求通俗易懂。请读者边读边手绘各个流程，一便于理解。     

总体交互流程如下

     1. 客户端发起HTTPS请求

　　这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

　　2. 服务端的配置

　　采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

　　3. 传送证书

　　这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

　　4. 客户端解析证书

　　这部分工作是有客户端的TLS来完成的。

　　客户端（以 IE 浏览器为例，单击“工具”——“Internet 选项”——“内容”选项卡——单击“证书”）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

　　首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

　　5. 传送加密信息

　　这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

　　6. 服务段解密信息

　　服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密（解说:正式的交互数据使用对称加密，非对称加密性能差）。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

　　7. 传输加密后的信息

　　这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

　　8. 客户端解密信息

　　客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

几个关键的背景概念

1）数字签名——为了证明发件人身份，情景再现如下，

　　Alice与Bob互换公钥。
　　Alice用自己的私钥对TXT文件进行数字签名。
　　Alice用Bob的公钥对TXT文件进行加密。
　　Alice把经过数字签名和加密的文件TXT，通过邮件或其他传输途径，如QQ、MSN等）传给Bob。
　　Bob在收到签名并加密的邮件后首先用Bob自己的私钥进行文件加密的解密，然后再用Alice的公钥进行数字签名解密。
　　同样，在这个过程中Cinda也可以获取Bob、Alice的公钥和签名并加密的标书文件TXT。同时因无Bob的私钥而无法打开邮件。同时由于Alice在发送文件前已用自己的私钥进行了数字签名，所以当Bob在收到邮件后完全可以证实自己收到的就是Alice发来的邮件，而不可能是其他用户的。试想如果Cinda非法用户想要改变邮件，冒充Alice向Bob发送邮件，因Cinda没有Alice的私钥，所以在用其他用户的私钥进行数字签名时就不可能再以Alice的公钥来解密数字签名了。
　　在这里要注意文件加密和数字签名的先后顺序，一定是先签名再加密，这样加密技术就可以同时保证邮件中的数字签名了。如果先加密，而后签名，非法用户在得到邮件后就可通过获取的公钥破解数字签名了，因为公钥是可以公开的，很容易被一些别有用心的人得到。数字签名破解后很可能签名被替换。当然邮件中的内容在没有收件人私钥的情况下还是无法打开的。

2）证书的起源——这里也通过一个情景来展现

　　鲍勃有两把钥匙，一把是公钥，另一把是私钥。

　　鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。

　　苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。

　　鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。

　　鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用 Hash 函数，生成信件的摘要（digest）。

　　然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。

　　鲍勃将这个签名，附在信件下面，一起发给苏珊。

　　苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。

　　苏珊再对信件本身使用 Hash 函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。

　　复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃
的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。

　　后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称 CA），为公
钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。

　　鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。

　　苏珊收信后，用 CA 的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。

附件：一个较详细的实现流解析

http://www.fenesky.com/blog/2014/07/19/how-https-works.html