SSL原理

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,交换秘密

时间: 2024-10-18 04:27:40

SSL原理的相关文章

12.17 Nginx负载均衡;12.18 ssl原理;12.19 生产ssl密钥对;12.20 Nginx配置ssl

扩展: 针对请求的uri来代理 http://ask.apelearn.com/question/1049 根据访问的目录来区分后端web http://ask.apelearn.com/question/920 12.17 Nginx负载均衡 1. 安装dig命令: [[email protected] ~]# yum install -y bind-utils 2. 用dig获取qq.com的ip地址: [[email protected] ~]# dig qq.com 3. 创建ld.co

https/ssl原理

在此总结下https协议原理. http问题 1)明文传输数据,被抓包后很容易可以看出传输内容,传输敏感数据有安全问题. 2)不能保证进行http通信的客户端与服务器是合法的. 为了解决这两个问题,需要对http数据进行加密和对通信双方进行认证.https就是在http协议的下层加了一个ssl协议,通过ssl实现了上述加密和认证的功能. https协议原理 通常,http直接和tcp通信.而https协议,则是http和ssl通信,ssl和tcp通信,加解密的功能在ssl层实现.ssl是独立于h

linux的Nginx负载均衡、ssl原理、生成ssl密钥对、Nginx配置ssl介绍

Nginx的负载均衡 1. 查找www.qq.com域名对应IP做测试 [[email protected] ~]# yum install -y bind-utils //安装dig命令包 [[email protected] ~]# dig www.qq.com ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> www.qq.com ;; global options: +cmd ;; Got answer: ;

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

Nginx负载均衡 Nginx负载均衡即为当代理服务器将自定义的域名解析到多个指定IP时,通过upstream来保证用户可以通过代理服务器正常访问各个IP. 代理一台机器叫做代理,代理两台及两台服务器就能叫做负载均衡. 负载均衡配置 创建一个配置文件/usr/local/nginx/conf/vhost/load.con [[email protected] ~]# vim /usr/local/nginx/conf/vhost/load.conf upstream qq.com #借助upst

LNMP(Nginx负载均衡,SSL原理,Nginx配置SSL,生产SSL密钥对)

一.Nginx负载均衡 负载均衡:单从字面上的意思来理解就可以解释N台服务器平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况.那么负载均衡的前提就是要有多台服务器才能实现,也就是两台以上即可. 在开始部署负载均衡之前,我们先来介绍一个命令,dig命令需要yum安装一下 [[email protected] ~]# yum install bind-utils [[email protected] ~]# dig qq.com            (dig后加域名,他可以返回2个

12.17 Nginx负载均衡;12.18 ssl原理;12.19 生产ssl密钥对;12.20 N

12.17 Nginx负载均衡:12.18 ssl原理:12.19 生产ssl密钥对:12.20 Nginx配置ssl 扩展: 针对请求的uri来代理 : http://ask.apelearn.com/question/1049 根据访问的目录来区分后端的web : http://ask.apelearn.com/question/920 nginx长连接 : http://www.apelearn.com/bbs/thread-6545-1-1.html nginx算法分析 : http:/

12.17 Nginx负载均衡 12.18 ssl原理 12.19 生成ssl密钥对 12.20 N

12.17 Nginx负载均衡 [[email protected] ~]# yum install -y bind-utils[[email protected] ~]# dig www.qq.comANSWER SECTION:www.qq.com. 73 IN A 59.37.96.63www.qq.com. 73 IN A 14.17.42.40www.qq.com. 73 IN A 14.17.32.211[[email protected] ~]# curl -x127.0.0.1:

2018-3-16 12周5次课 Nginx负载均衡、ssl原理、秘钥、配置

12.17 Nginx负载均衡 在upstream下定义多个ip 如何查到网站解析的ip?--使用dig命令 需要安装bind-utils [[email protected] ~]# yum install -y bind-utils (过程省略) [[email protected] ~]# dig qq.com (这是网站的两台服务器ip) [[email protected] vhost]# vim ld.conf ip_hash 网站有两台服务器提供服务,想让始终访问一台服务器,用ip

Nginx负载均衡,ssl原理,生成ssl密钥对,Nginx配置ssl

Nginx负载均衡负载均衡就是:将本应该这台机器(或集群)要处理的请求(工作或负载),根据一定的算法,平均地分配到其他的机器(或集群)上去处理,这样可以大大减少这台机器(或集群)的工作量,防止因负载过大而造成响应超时或down机等意外情况的发生.一般大的网站和系统都使用了负载均衡!首先进入/usr/local/nginx/conf/vhost/目录下然后编辑文件 vim /usr/local/nginx/conf/vhost/load.conf然后加入下列配置upstream qq_com{ip

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

五十.Nginx负载均衡.ssl原理.生成ssl密钥对.Nginx配置ssl 一.Nginx负载均衡 代理一台机器叫代理,代理两台机器就可以叫负载均衡. 代理服务器后有多个web服务器提供服务的时候,就可以实现负载均衡的功能. dig命令:解析域名的IP.常用的域名查询工具,可以用来测试域名系统工作是否正常,可以反馈多个IP. 需要安装这个包:# yum install -y bind-utils # dig qq.com ; <<>> DiG 9.9.4-RedHat-9.9.4