思路
假设甲跟乙需要通信，他们之间隔着若干个中间人（路由，网关）。他们说什么这些中间人都可以截取到。
如果是http的方式，甲跟乙的通话都是明文，那么这些中间人可以非常轻易的获取到甲跟乙的通话内容，如果这些通话内容涉及一些隐私内容，那么这种方式就不太合适了。
对于这个问题，我们对明文加密就可以了。这样即使中间人看到了甲乙的通话内容，也没有关系。下面考虑选择什么方式进行加密呢？对称还是非对称？
首先考虑对称加密，对称加密需要甲跟乙有相同的秘钥才行。那这个秘钥要怎么传输呢？（鸡生蛋，蛋生鸡）。甲跟乙当然可以私下约定一个秘钥，只有他两个知道。但是甲跟丙通信，甲跟丁通信，等等呢。在只有一对一通信的场景下，私下约定也可以作为一个不错的选择。但是实际情况大多都不是一对一的。对称加密不太合适。
那我们考虑使用非对称加密。甲跟乙都有自己的公钥跟私钥，甲跟乙通信的时候都用对方的公钥加密。这样解决了使用对称加密的问题。但是非对称加密耗时且对加密的长度有限制，在实际情况中也并不十分合适。
https对明文加密这块选择的是非对称跟对称结合的方式。
甲跟乙说我要跟你对话，乙将自己的公钥发给甲，甲生成一个随机的字符串作为对称加密的秘钥，然后用乙的公钥对该秘钥加密之后发送给乙。乙解密之后就有了对称加密的秘钥。之后的通信内容都用该秘钥进行加密。
以上解决明文传输的问题。
再考虑一个新的问题，乙将自己的公钥发给甲的过程中，中间人也收到了乙的公钥，假如中间人把自己的公钥发给甲，然后甲同样生成一个随机的字符串作为对称加密的秘钥，之后用中间人发的公钥对对称加密的秘钥加密之后发给中间人，中间人再用自己的私钥解密，此时中间人就获取了对称加密的秘钥，之后它再用乙的公钥对对称加密的秘钥加密之后转发给乙。在整个过程中甲跟乙都没有办法check到有个中间人修改了通信内容。
其实这个问题说的底是甲没有办法确认自己收到的公钥是乙的公钥而不是其他人的。
为了解决上面的问题，我们需要引入如下概念：
ca
数字签名
数字证书
ca在网络通信中扮演的角色相当于现实世界中的公证处，它拥有自己的公钥跟私钥。我们可以认为这个私钥只有该公证处知道，那些中间人是不可能知道的。
数字签名跟现实生活中的签名作用是一样的。可以唯一标识一个“人”。
数字证书在现实生活中相当于身份证，它有你的个人信息，还有你的签名（身份证号），还有公钥。
它们三者之间的关系是这样的，ca会给乙颁发数字证书，该证书中包含乙的公钥，乙的个人信息以及乙的数字签名。签名制作过程是这样的，ca会对数字证书中的个人信息，以及公钥做个hash，算出信息摘要，之后用自己的私钥对该信息摘要加密生成数字签名。
我们接着思考上述问题，首先甲跟乙说我要跟你对话，之后乙不是将公钥而是将ca给自己的证书发给甲，首先中间人会收到该证书，假设中间人用自己的公钥替换了证书中的公钥，（因为它没有ca的私钥，所以它没有办法修改证书中的签名），之后他把伪造的证书转给甲。甲收到证书之后首先会对证书中的信息做同样的hash运行获取信息摘要。之后用ca的公钥对证书中的签名做解密，获得另一个信息摘要，之后比对这两个信息摘要，因为中间人对证书中的公钥做了修改，所以这两个信息摘要肯定是不一致的，这样甲就知道了我即将使用到的公钥是伪造的。
或者中间人也跟ca申请到了自己的证书，然后它将自己的证书给了甲，这种情况下，甲会对证书中的个人信息做一个检查，很轻易的甲就会发现我想要访问的跟我真实访问的并不是同一个对象。
概念
HTTPS是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
解决什么问题
- 通信过程中明文传输问题
- 通信过程中中间人攻击问题
怎么解决的
- 数据加密传输，对称跟非对称加密
- 服务端身份认证，证书（数字签名）