http://blog.csdn.net/terryzero/article/details/5921791SSL的原理以前一直很模糊,看了下面这篇文章后清楚了许多,为了方便以后的回顾,所以转载下

RSA的公用密钥密码系统广泛地应用于计算机工业的认证和加密方面。

 
    公用密钥加密技术使用不对称的密钥来加密和解密,每对密钥包含一个公钥和一个私钥,公钥是公开,而且广泛分布的,而私钥从来不公开,只有自己知道。
 
    用公钥加密的数据只有私钥才能解密,相反的,用私钥加密的数据只有公钥才能解密,正是这种不对称性才使得公用密钥密码系统那么有用。
 
    认证是一个验证身份的过程,目的是使一个实体能够确信对方是他所声称的实体。
 
    下面使用 {something}key 表示something 已经用密钥 key 加密或解密。
 
    实例:现在有两个家伙 A 和 B,其中 B 想要联系 A,此时 A 要验证 B 真的就是 B,其中 B 有一对密钥对,一个公钥,一个私钥,首先,
    
    1,B 会偷偷的告诉 A 他的公钥(如何偷偷的,马上再说)。
        * B --> A       public-key
 
    2,收到 B 发送来的请求(其中包含 B 的公钥)后,A 产生了一段随机消息,并发送给了 B:
        * A --> B       rand-msg
 
    3,B 收到这段 rand-msg 后,拿出自己的私钥进行了加密,并将加密后的消息返回给了 A:
        * B --> A       {rand-msg}B-private-key
 
    4,此时,A 收到的是 B 发送过来的经过 B 的私钥加密后的消息,然后掏出第一个 B 发送给他的公钥去解密,并且和自己在上一次产生的 rand-msg 进行比较,如果一样的话,他就会开心了,果然是 B。
 
  ====> 看上去很美
 
    一切听上去好像很完美了,可是事实并不像看上去的那么美... ...
 
    我们再举个例子,离实际生活近一点的例子,仍然是 A 和 B 两个家伙,两人都是哑巴,他们的通信都是通过传递小纸条的。其中 A 胆子很小,一天到晚都呆在家里,一天,B 要去找 A,在 A 的门口敲门,
 
    1,并把一个他的公钥写在纸条上通过门缝里传给 A,
        * B --> A       b-public-key
 
    2,此时,A 传了纸条给 B
        * A --> B       你是 B 吗?
 
    3,B 收到 A 传来的消息,很自觉地回了消息,并且还用自己的私钥给消息加了密,可是消息好像不太对:
        * B --> A       {嗨!兄弟是我!我是 C!}b-private-key
 
    4,A 从门缝里接过小纸条,再拿出 B 第一次给他的 b-public-key 进行解密,解开了,B 也在门外等了好久,人没有见着,回去了... ...
 
    从这里看出,B 必须对自己需要加密的东西有所了解,还有,这个私钥只有你才有!
 
  ====> 数字签名
 
    现在的改进是在第三步,当 B 接收到 A 的随机消息后,并不是简单的用私钥加密一下就好了,而是根据 A 的随机消息来构造一个消息摘要,然后再对这个消息摘要进行加密。
 
    通过使用这个消息摘要,A 通过 b-public-key 解密收到这个加密后的消息摘要,并还原成随机消息来比较他之前发送给 B 的 rand-msg。
 
    ~~~ 个人感觉,这里主要多了一个对消息进一步的消息摘要的构造过程。多了一层保护,因为一般是不知道如何构造摘要的。
 
    而这个改进技术就是数字签名技术。正如我个人感觉的这里的消息摘要(签名)只是多了一层消息的构造过程,同样有些危险。因此,我们的认证协议需要一次以上的协议(来保证更安全的保护),让部分(or全部)的数据由 B 来产生(好像也更人性化了一点:P):
 
    A --> B     Hello, are you B ?
    B --> A     A, This is B!{Digest[A, This is B!]}b-private-key
 
    此处,我们可以看到了变化:
 
    * B 发送了自己想要发送的消息摘要
    * 多了发送的另一部分经过 b-private-key 加密的消息摘要,这个主要用于让 A 来验证 B 是否就是真的 B,感觉充分使用了这个别人不知道的 b-private-key :P
 
  ====> 证书
    
    上面我们提到过,在一开始 B “偷偷的” 发送了一个 public-key 给 A(否则任何人都可以是 B 了),为了解决这个问题,标准化组织发明了一个叫做证书的咚咚,一个证书主要包含如下信息:
 
  * 证书的发行者姓名 
  
  * 发行证书的组织 
  
  * 标题(主题)的公钥 
  
  * 邮戳
 
    证书使用发行者(这里如 B )的私钥加密。每一个人(如 A )都知道证书发行者的公钥(这样,每个证书的发行者拥有一个证书)。证书是一个把公钥与(证书的发行者)姓名绑定的协议。通过使用证书技术,每一个人(如 A )都可以检查 B 的证书,判断是否被假冒。假设 B 控制好他的私钥,并且他确实是得到证书的 B,就万事大吉了。
 
  1,A-->B    hello
  2,B-->A    Hi, 兄弟,我是 B, 看,这是我的证书 b-certificate
  3,A-->B    别以为你有了 B 的证书 b-certificate,我就真的以为你是 B 了,证明你是 B
  4,B-->A    A, This Is B{Digest[A, This Is B] }b-private-key    
 
    再次解释一下:当 A 收到 B 的第一条消息(2 步)后,他可以检查并核实证书,以及签名(如上,使用了消息摘要和公钥加密),然后再核实主题(B 的名字)来确定是不是真的 B。这样,A 就可以确信这个公钥的确是 B 的公钥,下面,再次要求 B 证明他的身份。B 则重新进行如上的过程,计算消息摘要,然后使用 private-key 进行加密... ...
 
    * 不是有了证书,你就可以进 A 的家门的
    * 因为你没有 B 的私钥,所以你无法构造一个可以让 A 相信这是来自 B 的消息。
    
  ====> 交流秘密
    
    下面终于可以进入 A 的家门了,B 好辛苦啊,但是下面的交流还是秘密啊,不能被旁人看到,那可是国家机密哦:)
    
    当然,A 之后发送的消息就是只有 B 才能解码的消息了,如下:
 
    * A-->B     {secret} b-public-key
 
    分析一下上面这个 secret,发现这个 secret 的方法只有使用 B 的私钥 b-private-key 来解密,交换秘密是公用密钥密码系统的另一种强大的用法。即使 A 和 B 之间的通信被监视,除了 B,也没有人能够得到秘密。
 
    因为 A(这是他自己传送的秘密) 和 B(他有私钥) 都知道这个秘密,所以他们就可以初始化一个对称的密码算法(如DES,RC4,IDEA),然后开始传输用它加密的消息。下面是修正后的协议:
 
  A --> B hello
  B --> A Hi, I'm B, b-certificate
  A --> B prove it
  B --> A A, This Is b{ digest[A, This Is B] } b-private-key
  A --> B ok b, here is a secret {secret} b-public-key        // A 传了一个 secret 
  B --> A {some message}secret-key
 
    其中,secret-key 的计算取决于协议的定义,但是它可以简化成一个 secret 的副本。
 
  ===> Hacker 来袭
 
    有些 Hacker 很坏,他们虽然不能 “窃听” 到 A 和 B 之间的国家级机密的对话,但是他们可以从中作梗:
 
  A-->M hello
  M-->B hello
  
  B-->M Hi, I'm B, B-certificate
  M-->A Hi, I'm B, B-certificate
  
  A-->M prove it
  M-->B prove it
  
  B-->M A, This Is B{ digest[A, This Is B] } B-private-key
  M-->A A, This Is B{ digest[A, This Is B] } B-private-key
  
  A-->M ok B, here is a secret {secret} B-public-key
  M-->B ok B, here is a secret {secret} B-public-key
  
  B-->M {最近国际形势不太乐观啊!}secret-key
  M-->A Garble[ {最近国际形势不太乐观啊!}secret-key ] // 如果 M 够 “幸运” 的话,可能变成了 “你这个大笨蛋!”
    
    可以看到这个 Hacker 好坏,他一直等到 A 和 B 开始交流机密了,然后通过改变 B 发送给 A 的机密的方式开始作梗,而此时 A 已经相信这是 B 的机密了(可能变成了: 你这个大笨蛋!:P ),结果悲剧再一次上演... ...
 
    为了防止这种破坏,A 和 B 在他们的协议中引入了一种消息认证码(Message Authentication Code, MAC)。MAC 是根据秘密的密钥和传输的数据计算出来的,上面描述的消息摘要算法的属性正好可以用于构造抵抗 M 的MAC功能。
 
    MAC := Digest[ some message, secret ]
 
    注:我们发现之前的消息摘要只是对消息进行构造,此处,包括了 secret。
 
    因为 M 不知道这个秘密的密钥,所以他无法计算出这个摘要的正确数值。即使 M 随机的改变消息,如果摘要数据很大的话,他成功的可能性也会很小。例如,通过使用 MD5(RSA公司发明的一种很好的密码摘要算法),A 和 B 能和他们的消息一起发送 128 位的 MAC 值。M 猜中这个正确的 MAC 值的几率只有 1/18,446,744,073,709,551,616。
 
    下面是又一次的修正协议:
 
    A --> B 你好 
    B --> A 嗨,我是 B,b-certificate
    A --> B prove it
    B --> A {digest[A, 我是 B] } b-private-key
    A --> B ok B, here is a secret {secret}b-public-key
    B --> A {some message,MAC}secret-key
 
    现在 M 已经无技可施了。他如果下面想要干扰了得到的消息,A 和 B 能够发现伪造的 MAC 值并且立即停止交谈。这样 M 不再能与 B 通讯。
   
整个过程:
 
    1,分发证书
    2,验证证书,验证身份
    3,交换秘密

SSL原理的更多相关文章

  1. SSL 原理及 https 配置

    目录 1. SSL 原理 1.1. SSL 简介 1.2. 主要概念 1.3. 建立安全连接的过程 2. https 配置 (以 nginx 为例) SSL 原理 SSL 简介 SSL (Secure ...

  2. nginx负载均衡、nginx ssl原理及生成密钥对、nginx配制ssl

    1.nginx负载均衡 新建一个文件:vim /usr/local/nginx/conf/vhost/load.conf写入: upstream abc_com{ip_hash;server 61.1 ...

  3. Nginx负载均衡、SSL原理、生成SSL密钥对、Nginx配置SSL

    6月12日任务 12.17 Nginx负载均衡12.18 ssl原理12.19 生成ssl密钥对12.20 Nginx配置ssl扩展 针对请求的uri来代理 http://ask.apelearn.c ...

  4. Linux centosVMware Nginx负载均衡、ssl原理、生成ssl密钥对、Nginx配置ssl

    一.Nginx负载均衡 vim /usr/local/nginx/conf/vhost/load.conf // 写入如下内容 upstream qq_com { ip_hash; 同一个用户始终保持 ...

  5. 浅析HTTPS与SSL原理

    版权声明:本文由盛旷 原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/134 来源:腾云阁 https://www.qclo ...

  6. 单点登录 SSO, 自动登录 , java 加密,ssl原理, Tomcat配置SSL

    韩梦飞沙  韩亚飞  313134555@qq.com  yue31313  han_meng_fei_sha 单点登录的英文简称为SSO(single sign on),单点登录功能使得用户只要登录 ...

  7. ssl原理及应用

    今天学习网络通信,看到使用ssl(Secure Sockets Layer)进行加密,由于对ssl只是有些概念上的了解,对于具体应用原理.过程和如何使用不慎了解,于是学习了一番,总结如下: 1. 为什 ...

  8. ssl 原理简介

    要想弄明白SSL认证原理,首先要对CA有有所了解,它在SSL认证过程中有非常重要的作用.说白了,CA就是一个组织,专门为网络服务器颁发证书的,国际知名的CA机构有VeriSign.Symantec,国 ...

  9. ssl 原理和建立连接过程

    ssl ("Secure Sockets Layer")加密原理 和https的关系https = http + ssl ssl 位置: SSL握手 证书主要作用是在SSL握手中, ...

  10. ssl原理,非对称加密握手,对称加密传输

    SSL的基本思想是用非对称加密来建立链接(握手阶段),用对称加密来传输数据(传输阶段).这样既保证了密钥分发的安全,也保证了通信的效率. SSL握手,单方服务器认证(一般的浏览器上网) SSL握手,双 ...

随机推荐

  1. 寻路DEMO

    网格场景的寻路算法DEMO 灰色格子为默认正常蓝色格子表示为障碍物,不可进入红色细条在格子周围,表示格子的墙,用于阻碍行走紫色为当前鼠标选中格子黄色为寻路的起始位置和结束位置.鼠标左键设置,CTRL+ ...

  2. Linux进程调度的运行队列

    当Linux内核要寻找一个新的进程在CPU上运行时,必须只考虑处于可运行状态的进程,(即在TASK_RUNNING状态的进程),因为扫描整个进程链表是相当低效的,所以引入了可运行状态进程的双向循环链表 ...

  3. SQL语句大小写是否区分的问题,批量修改整个数据库所有表所有字段大小写

    一.实例介绍 SQL语句大小写到底是否区分呢?我们先从下面的这个例子来看一下: 例: --> 创建表,插入数据: declare @maco table (number int,myvalue ...

  4. 利用CSS、JavaScript及Ajax实现图片预加载的三大方法及优缺点分析

    预加载图片是提高用户体验的一个很好方法.图片预先加载到浏览器中,访问者便可顺利地在你的网站上冲浪,并享受到极快的加载速度.这对图片画廊及图片占据很大比例的网站来说十分有利,它保证了图片快速.无缝地发布 ...

  5. Maven私库安装与配置

    Maven私库安装与配置 https://www.cnblogs.com/dengyulinBlog/p/6398310.html

  6. Ubuntu 或 UbuntuKyLin14.04 Unity桌面側边栏和顶层菜单条显示异常解决方法

    近期一直想要回到Linux以下去开发,正好Ubuntu14.04桌面版系统在近期公布,所以趁此机会下载了最新版的Ubuntu版本号.并在虚拟机VMware软件上面搭建一改Ubuntu系统,因为眼下有适 ...

  7. 微信公众号开发之如何使用JSSDK

    微信开发交流群:148540125 欢迎留言.转发.打赏 系列文章参考地址 极速开发微信公众号 项目源码参考地址 点我点我--欢迎Start 查看公众号是否有使用JSSDK的权限 服务号.订阅号可以通 ...

  8. Discuz常见大问题-如何允许用户插入视频-如何自己在页面中插入视频

    从视频的下面分享中获取html代码 然后粘贴到你创建页面的指定位置(注意从优酷复制的视频宽度和高度可能比较小,你可以自己调整,或者占据100%) 最终的实现效果

  9. wepy - 与原生有什么不同(事件更改)

    对于repeat,详情见官方文档 <style lang="less"> .userinfo { display: flex; flex-direction: colu ...

  10. wepy - 使用vsCode编辑器安装插件

    完成后,高亮以及智能补全代码. 1. 首先ctrl+shift+p打开扩展,安装以下三个插件 2. 复制以下文件内容到你的vsCode配置 files.associations { "fil ...