安全架构之Https--让你的隐私数据不再暴露

一.常见的加密方式
  对称加密和非对称加密

二.对称加密算法




特点：加密和解密的密钥相同
问题：网络是不安全的，如何实现密钥的安全传输？

三. 非对称加密算法


特点：发送方和接收方各持有一对钥匙(公钥 和私钥)，用公钥（私钥）加密的数据只有对用的私钥（公钥）才能解密。

四.非对称加密 + 对称加密
(1)发送方或接收方事先生成一个对称加密算法的密钥，用RSA方式安全的发送给对方；
(2)对方接受到这个密钥，以后发送的数据就采用对称加密的方式传输；

五.中间人攻击
假设A发消息给B,采用上面的非对称加密+对称加密的方式，首先，A要获取B的公钥，如果B在发送给A公钥时，有个中间人，截获了B的公钥，然后把自己的公钥发给了A，冒充B，那么A发的消息就用中间人的公钥加了密，中间人不就可以解密看到消息了？

六.你到底是谁？
如何安全的分发公钥？公钥是不用保密的，那如何声明这个公钥确实是服务端发送的，而不是别人的？
数字签名
可以效仿现实中的公证处，服务端把他的公钥和基本信息用一个Hash算法生成一个信息摘要，这个Hash算法有个极好的特性，只要输入数据有一点点变化，那生成的消息摘要就会有巨变，这样就可以防止别人修改原始内容。

可是作为攻击者的中间人笑了： “虽然我没办法改公钥，但是我可以把整个原始信息都替换了， 生成一个新的消息摘要， 你不还是辨别不出来？”

这时就要搬出有公信力的认证中心CA来了，用它的私钥对消息摘要加密，形成签名，这还不算，还把原始信息和数据签名合并， 形成一个全新的东西，叫做“数字证书”。

当服务端把他的数字证书发给客户端的时候，客户端会用同样的HASH算法再次生成消息摘要，然后用CA的公钥对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了！如果没人篡改， 客户端就可以安全的拿到服务端的公钥喽，有了公钥， 后序的加密工作就可以开始了。虽然很费劲， 但是为了防范偷窥者，实在是没办法啊。

中间人恶狠狠地说： “算你小子狠！ 等着吧，我还有别的招。 对了，我且问你， 你这个CA的公钥怎么拿到？　难道不怕我在你传输ＣＡ公钥的时候发起中间人攻击吗？　如果我成功的伪装成了ＣＡ，你这一套体系彻底玩完。”

折腾了半天，又回到了公钥安全传输的问题！

不过转念一想，想解决鸡生蛋，蛋生鸡的问题必须得打破这个怪圈才行，服务端必须得信任CA，并且通过安全的的方式获取他们的公钥，这样才能把游戏玩下去。

这些CA本身也有证书来证明自己的身份，并且CA的信用是像树一样分级的，高层的CA给底层的CA做信用背书，而操作系统／浏览器中会内置一些顶层的CA的证书，相当于你自动信任了他们。这些顶层的CA证书一定得安全地放入操作系统／浏览器当中，否则世界大乱。

七.HTTPS如何实现安全传输
一个简化的（例如下图没有包含Pre-Master Secret）https流程图是这样的， 如果你理解了前面的原理，这张图就变得非常简单：

八.数字证书

• 数字证书格式
  

• 数字证书转换
  

• http和https及ssl之间的关系
  
  
  
  

• 各种类型SSL数字证书区别
  
  

• SSL证书优势
  

• HTTP和HTTPS区别
  

• HTTPS加密流程
  

• 传统环境SSL证书部署
  
  

• Nginx集群环境SSL证书部署
  
  

• 操作部署流程