https 为什么是安全的?

核心是: 加密 + 签名

加密: 1.防止被看 2. 防止穿改, 被改后也不怕,解密数据后就无意义了 (乱码, 只是造成骚扰,但业务数据不会错乱)

签名作用: 签名一定要加密,签名不加密其实也没啥作用. 非对称加密的意义.

安全的前提是:

  1. 有签名

  2. 有非对称加密

  3.

本文为了回答,为什么即使有中间人(中间人概念见下文附件)的存在,https 也能保证安全?

首先先想想中间人能做什么?

     1. 能窃取你和 ca 认证机构交互的过程

     2. 能窃取你和业务服务器(例如,sina,支付宝等)交互的过程.

不能做什么?

     不能改变操作系统中或者浏览器中原有的数据.

  

哪怕你中间人也有自己的公钥,也没用. 因为本地会去通过公钥上的上级证书,验证的数据包括 网址+加密过的公钥数据=签名.

由于中间人只有自己网址的公钥.

    证书的作用就是解决: 大家都可以生成公钥、私钥对，无法确认公钥对到底是谁的。[1]

一个数字证书包含下面的具体内容：[1]

• 证书的发布机构
• 证书的有效期
• 公钥
• 证书所有者（Subject）
• 签名所使用的算法
• 指纹以及指纹算法

记住一点: 证书!=公钥,证书>公钥

利用上级机构的公钥 进行解密解密. 并且 公钥+网址+相关数据 对 签名值 进行验证.

因为该签名是有 机构服务端的私钥+网址 加密的.

  1. 所以一旦中间人变了相关数据,也无法构造出合适的签名值. 客户端不认可中间人给的证书. 不会用中间人给的公钥加密传输数据

  2. 即使中间人知道了公钥,也没有用. 客户端用公钥加密过的数据,只有服务端才知道.中间人不知道

操作系统中,原有系统中原有的数据是什么?

   根ca 的数据,公钥. ( 这个是 https 是安全的地基,所以不要乱装盗版系统)

我本来的错误的理解是: 1. ca 公钥获取 和 请求 sina 系统之间打个时间差  2. 获取支付宝服务器公钥 和 请求支付宝转账之间打个时间差.

附件内容总结:

     通过操作系统中内置公钥, 衍生到各服务器公钥, 最终保证了信息的加密, 以及通过验证加密的签名来保证信息的正确性.

附件:

[1] 数字证书原理 http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html  

[2] CA链 http://www.ywnds.com/?p=2546

理解下 https 的原因 ,由来? 

https原理通俗了解[转]

http://blog.jobbole.com/110354/

摘要：本文尝试一步步还原HTTPS的设计过程，以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程。在阅读本文时，你可以尝试放下已有的对HTTPS的理解，这样更利于“还原”过程。

我们先不了聊HTTP，HTTPS，我们先从一个聊天软件说起，我们要实现A能发一个hello消息给B：

如果我们要实现这个聊天软件，本文只考虑安全性问题，要实现

A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容

如何做到真正的安全？

这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~

而我想说，加密算法只是解决方案，我们首先要做的是理解我们的问题域——什么是安全？

我个人的理解是：

A与B通信的内容，有且只有A和B有能力看到通信的真正内容

好，问题域已经定义好了（现实中当然不止这一种定义）。对于解决方案，很容易就想到了对消息进行加密。

题外话，但是只有这一种方法吗？我看未必，说不定在将来会出现一种物质打破当前世界的通信假设，实现真正意义上的保密。

对于A与B这样的简单通信模型，我们很容易做出选择：

这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。

只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。

但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：

如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？请读者思考21秒钟。