https的设计原理
参考文章：
这两篇文章写的非常好，本文是读后笔记
-------------------------------------------------------------------------------
我们都知道日常上网使用的http协议是不安全的，比如日常开发中我们就可以利用一些工具比如青花瓷等进行抓包，然后更改请求内容进行发送。中间人(黑客)当然也可以这么做，这样的话我们的信息安全水平就非常的低，对于银行转账一类的操作就无法在网上进行，基于安全的需求，也就诞生了https。通常我们说https协议是加密的http协议，是安全的，这么说也没有错，但实际上https要比http复杂的多的多的多。
想信息不被获取或更改，我们最先想到的办法是加密。客户端跟服务端在不见面的情况下，密钥如何传递就是个问题。关于这个问题，参见：http://blog.jobbole.com/113883/
通过信鸽问题理解了https的逻辑处理过程，我们来看https具体是如何处理的。
几个角色跟名词：
客户端：理解为我们日常上网的pc
服务端：各个网站的服务器，比如银行网站服务器
中间人：黑客，介于客户端跟服务端中间，从网络上窃取数据的不明人士
证书：客户端识别服务器返回信息是否经过篡改的依据文件
认证机构：制作证书的公司
数字签名：证书中的一部分内容，用于跟其他内容联合鉴别证书真伪
服务端搭建过程
网站管理员从认证机构申请证书，然后搭建网站，并将证书放到网站服务器上。申请证书的过程根据证书颁发机构的不同略有差异，具体部署网站的过程也跟所使用web服务器是nginx，apache还是tomcat的不同而不同。
客户端访问
客户端通过浏览器访问网站，网站返回证书给客户端，证书中包含加密算法，公钥等相关信息(这些信息是被加密的)。客户端拿到证书后进行解密，获取服务端所给的公钥。这里有个问题，服务端所给的证书是加密的，客户端拿到后是怎么解密的呢？总不能再请求一次证书颁发机构获取解密信息吧，这访问量有点大，也不安全；实际上，客户端操作系统或者浏览器中就包含证书如何解密的信息，这些内容是证书颁发机构跟操作系统厂商浏览器厂商协调沟通后内置进去的，这里边主要内容就是颁发机构加密证书对应的公钥(认证机构加密证书用的私钥)。
题外话：由于证书的解密方式是内置到操作系统中或浏览器的，如果证书是可信任的，访问的时候就可以正常访问，并且地址栏会有绿色的锁头标志，点击可以查看证书信息，如果证书不可信任，浏览器就会提示“您的连接不是私密连接”。那么问题来了，网站如果不使用https，用户信息就有泄露的危险，如果使用自己制作的，就会有提示而且页面看上去挺有问题的，那只能找认证机构购买证书交保护费了。对了，既然证书公钥可以在浏览器上，如果我自己开发一个浏览器，，，那显示谁有问题不就是我说了算么，哎呀，一本万利的买卖啊，，，难怪难怪。
交互过程
现在客户端拿到了网站返回的证书，然后用本地浏览器内置的公钥打开证书，拿到网站给的公钥，然后就可以用公钥加密信息跟网站进行通信了。不过https(实际是ssl)不是这么干的，因为非对称加密效率一般，不如对称加密来的快，所以一般是用公钥加密一个对称加密的密钥给服务端，然后双方用这个对称加密的密钥加密信息进行通信；这就是为什么https既有对称加密又有非对称加密的原因。
思考
这个过程真的安全吗？
1、如果中间人也有有认证机构的公钥，解开了证书内容拿到了网站公钥
a、如果不修改网站公钥，那么下次客户端发来的加密私钥就无法解读(中间人没有网站私钥)
b、如果修改了网站公钥，证书就会被客户端识别错误(证书会根据网站域名，公钥等信息生成一个证书编号，客户端会根据证书描述，计算自己生成的证书编号跟证书中的是否相同，不同则被修改。中间人想要篡改证书，就要了解认证机构的证书编号生成规则，这个是基本无法做到的，因此伪造证书难度非常高)。
2、如果中间人也从认证机构申请了证书，对客户端申请的证书进行了调包
这种情况下，中间人有自己证书的私钥，只要客户端信任这个证书就万事ok。很遗憾，也不行，因为当初中间人从认证机构申请证书的时候也需要填写域名等相关信息，这些也是客户端证书校验的一部分，中间人的域名跟客户端请求的网站地址肯定是不一样的(要不那个中间人就是真实网站了)，也就导致证书无法验证通过。
-------------------------------------------------------------------------------
工作中用到https，简单记一下，权作笔记吧
