https 为什么是安全的?

 

https本质(CA验证的过程,核心就是预埋root公钥加密的过程): 1. 源公钥线下给(root公钥 操作系统默认安装)  [避免了中间人攻击,公钥不是在线给]

                  2. 公钥端生成对称密码  [对称密码不是服务端给,避免了中间人攻击,]

                  3. 公钥是加密用的,不是解密用的 [ 公钥虽然公开,但是加密后的数据只要私钥才能解开, 私钥不是加密用,因为私钥加密的数据,公钥都能解开. 服务端应该用临时生成的密码去加密, 这样就能保证一会话一秘钥.]

                  4. 1次非对称加密,n 次对称加密. [提高性能].

                   https的每个网站交互的公钥证书A是 服务端提供的,但是可以根据 内置好的root证书进行 ca验证. 确保该公钥证书A是该网站的公钥证书. 加密数据,中间人无法解密.

                  5. 公钥除了1. 加密数据传递给服务端,2. 另外一个作用就是本地签名验证. CA的证书验证是本地的.

两种攻击:

               1. 中间人攻击,截取信息: 1.1. 通过https的证书验证解决 1.2. 自有协议,本地公钥,一session一对称秘钥, 每次先生成一个对称秘钥,将秘钥加密后告知服务端. 只有服务端才能解,后续用对称秘钥加密.

                2. 模拟用户,插入数据. 2.1 一机一密(自有设备可以,提前分配)   2.2  普通用户, 通过密码方式. 

                3. 正常用户的机器被攻击, 加入了https可信任证书,公钥替换攻击, 截取了用户交互密码.  [一session一秘钥这种,只有破解了内存,才能截取用户数据. 秘钥不是服务端给的. 故自有app一般都先预埋公钥,]

 

 

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html 这篇文章最大的问题是 给你一个错觉,公钥是在线实时给的. 一旦是服务端在线给的,都会被中间人攻击.

为什么能安全: 证书最终被 root 证书校验,root 证书是正版系统内置的,只要系统正版,就能保证安全性. 故即使证书机构的证书下载过程被拦截也不怕.因为会被 root 证书验证. "信用链"

为什么不怕中间人拦截: 如上所说.

颁发的证书: 证书公钥部分, 证书私钥部分.证书公钥部分传递给客户端,客户端验证后,用此来加密,通信获取对称加密串.

 

核心是: 加密 + 签名

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

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

 

安全的前提是:

  1. 有签名

  2. 有非对称加密

 

本文为了回答,为什么即使有中间人(中间人概念见下文附件)的存在,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秒钟。