CA证书扫盲,https讲解。

不少关于CA证书的讲解。html

1.什么是CA证书。git

 

看过一些博客,写的比较形象具体。算法

 ◇ 普通的介绍信浏览器

  想必大伙儿都据说过介绍信的例子吧?假设 A 公司的张三先生要到 B 公司去拜访,可是 B 公司的全部人都不认识他,他咋办捏?经常使用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽......云云。而后在信上敲上A公司的公章。安全

  张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,并且 A 公司是常常和 B 公司有业务往来的,这位李小姐就相信张先生不是歹人了。服务器

这里,A公司就是CA证书tcp

◇ 引入中介机构的介绍信函数

  好,回到刚才的话题。若是和 B 公司有业务往来的公司不少,每一个公司的公章都不一样,那前台就要懂得分辨各类公章,很是滴麻烦。因此,有某个中介公司 C,发现了这个商机。C公司专门开设了一项“代理公章”的业务。工具

  从此,A 公司的业务员去 B 公司,须要带2个介绍信:加密

  介绍信1

  含有 C 公司的公章及 A 公司的公章。而且特意注明:C 公司信任 A 公司。

  介绍信2

  仅含有 A 公司的公章,而后写上:兹有张三先生前往贵公司办理业务,请给予接洽......云云。

  某些不开窍的同窗会问了,这样不是增长麻烦了吗?有啥好处捏?

  主要的好处在于,对于接待公司的前台,就不须要记住各个公司的公章分别是啥样子的;他/她只要记住中介公司 C 的公章便可。当他/她拿到两份介绍信以后,先对介绍信1的 C 公章,验明正身;确认无误以后,再比对介绍信1和介绍信2的两个 A 公章是否一致。若是是同样的,那就能够证实介绍信2是能够信任的了。

 

◇ 什么是证书?

  “证书”洋文也叫“digital certificate”或“public key certificate”(专业的解释看“这里”)。

  它是用来证实某某东西确实是某某东西的东西(是否是像绕口令?)。通俗地说,证书就比如例子里面的公章。经过公章,能够证实该介绍信确实是对应的公司发出的。

  理论上,人人均可以找个证书工具,本身作一个证书。那如何防止坏人本身制做证书出来骗人捏?请看后续 CA 的介绍。

  ◇ 什么是CA?

  CA是Certificate Authority的缩写,也叫“证书受权中心”。(专业的解释看“这里”)

  它是负责管理和签发证书的第三方机构,就比如例子里面的中介——C 公司。通常来讲,CA必须是全部行业和全部公众都信任的、承认的。所以它必须具备足够的权威性。就比如A、B两公司都必须信任C公司,才会找 C 公司做为公章的中介。

 ◇ 什么是CA证书?

  CA 证书,顾名思义,就是CA颁发的证书。

  前面已经说了,人人均可以找工具制做证书。可是你一个小破孩制做出来的证书是没啥用处的。由于你不是权威的CA机关,你本身搞的证书不具备权威性。

  这就比如上述的例子里,某个坏人本身刻了一个公章,盖到介绍信上。可是别人一看,不是受信任的中介公司的公章,就不予理睬。坏蛋的阴谋就不能得逞啦。

  文本后续说起的证书,若无特殊说明,均指 CA 证书。

 

2.证书的签发过程

 

a.服务方 S 向第三方机构CA提交公钥、组织信息、我的信息(域名)等信息并申请认证;

b.CA 经过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的全部权等;

c.如信息审核经过,CA 会向申请者签发认证文件-证书。

证书包含如下信息:申请者公钥、申请者的组织信息和我的信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;

签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,而后,采用 CA 的私钥对信息摘要进行加密,密文即签名;

d.客户端 C 向服务器 S 发出请求时,S 返回证书文件;

e.客户端 C 读取证书中的相关的明文信息,采用相同的散列函数计算获得信息摘要,而后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,若是一致,则能够确认证书的合法性,即公钥合法;

f.客户端而后验证证书相关的域名信息、有效时间等信息;

g.客户端会内置信任 CA 的证书信息(包含公钥),若是CA不被信任,则找不到对应 CA 的证书,证书也会被断定非法。

在这个过程注意几点:

1.申请证书不须要提供私钥,确保私钥永远只能服务器掌握;

2.证书的合法性仍然依赖于非对称加密算法,证书主要是增长了服务器信息以及签名;

3.内置 CA 对应的证书称为根证书,颁发者和使用者相同,本身为本身签名,即自签名证书;

4.证书=公钥+申请者与颁发者信息+签名;

 

 3.http存在的问题(引用:http://blog.csdn.net/wangjun5159/article/details/51510594)

http通讯存在的问题

  • 容易被监听 
    • http通讯都是明文,数据在客户端与服务器通讯过程当中,任何一点均可能被劫持。好比,发送了银行卡号和密码,hacker劫取到数据,就能看到卡号和密码,这是很危险的
  • 被假装 
    • http通讯时,没法保证通行双方是合法的,通讯方多是假装的。好比你请求www.taobao.com,你怎么知道返回的数据就是来自淘宝,中间人可能返回数据假装成淘宝。
  • 被篡改 
    • hacker中间篡改数据后,接收方并不知道数据已经被更改

共享密钥加密和公开密钥加密

后续内容的须要,这里插播一段共享密钥加密和公开密钥加密

  • 共享密钥加密 
    • 共享密钥的加密密钥和解密密钥是相同的,因此又称为对称密钥
  • 公开密钥加密 
    • 加密算法是公开的,密钥是保密的。公开密钥分为私有密钥和公有密钥,公有密钥是公开的,任何人(客户端)均可以获取,客户端使用公有密钥加密数据,服务端用私有密钥解密数据。
  • 异同 
    • 共享密钥加密与公开密钥加密相比,加解密处理速度快,但公开密钥更适应互联网下使用

https解决的问题

https很好的解决了http的三个缺点(被监听、被篡改、被假装),https不是一种新的协议,它是http+SSL(TLS)的结合体,SSL是一种独立协议,因此其它协议好比smtp等也能够跟ssl结合。https改变了通讯方式,它由之前的http—–>tcp,改成http——>SSL—–>tcp;https采用了共享密钥加密+公开密钥加密的方式

  • 防监听 
    • 数据是加密的,因此监听获得的数据是密文,hacker看不懂。
  • 防假装 
    • 假装分为客户端假装和服务器假装,通讯双方携带证书,证书至关于身份证,有证书就认为合法,没有证书就认为非法,证书由第三方颁布,很难伪造
  • 防篡改 
    • https对数据作了摘要,篡改数据会被感知到。hacker即便从中改了数据也白搭。

https链接过程

  • 客户端发送请求到服务器端
  • 服务器端返回证书和公开密钥,公开密钥做为证书的一部分而存在
  • 客户端验证证书和公开密钥的有效性,若是有效,则生成共享密钥并使用公开密钥加密发送到服务器端
  • 服务器端使用私有密钥解密数据,并使用收到的共享密钥加密数据,发送到客户端
  • 客户端使用共享密钥解密数据
  • SSL加密创建………

 

客户端认证的通讯的过程

  • 客户端须要认证的过程跟服务器端须要认证的过程基本相同,而且少了最开始的两步。这种状况都是证书存储在客户端,而且应用场景比较少,通常金融才使用,好比支付宝、银行客户端都须要安装证书

后续的问题

    • 怎样保证公开密钥的有效性 
      • 你也许会想到,怎么保证客户端收到的公开密钥是合法的,不是伪造的,证书很好的完成了这个任务。证书由权威的第三方机构颁发,而且对公开密钥作了签名。
    • https的缺点 
      • https保证了通讯的安全,但带来了加密解密消耗计算机cpu资源的问题 ,不过,有专门的https加解密硬件服务器
    • 各大互联网公司,百度、淘宝、支付宝、知乎都使用https协议,为何? 
      • 支付宝涉及到金融,因此出于安全考虑采用https这个,能够理解,为何百度、知乎等也采用这种方式?为了防止运营商劫持!http通讯时,运营商在数据中插入各类广告,用户看到后,怒火发到互联网公司,其实这些坏事都是运营商(移动、联通、电信)干的,用了https,运营商就无法插播广告篡改数据了。

4.比较完整的过程:

1. 客户端发起HTTPS请求

  这个没什么好说的,就是用户在浏览器里输入一个https网址,而后链接到server的443端口。

  2. 服务端的配置

  采用HTTPS协议的服务器必需要有一套数字证书,能够本身制做,也能够向组织申请。区别就是本身颁发的证书须要客户端验证经过,才能够继续访问,而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择,有1年的免费服务)。这套证书其实就是一对公钥和私钥。若是对公钥和私钥不太理解,能够想象成一把钥匙和一个锁头,只是全世界只有你一我的有这把钥匙,你能够把锁头给别人,别人能够用这个锁把重要的东西锁起来,而后发给你,由于只有你一我的有这把钥匙,因此只有你才能看到被这把锁锁起来的东西。

  3. 传送证书

  这个证书其实就是公钥,只是包含了不少信息,如证书的颁发机构,过时时间等等。

  4. 客户端解析证书

  这部分工做是有客户端的TLS来完成的,首先会验证公钥是否有效,好比颁发机构,过时时间等等,若是发现异常,则会弹出一个警告框,提示证书存在问题。若是证书没有问题,那么就生成一个随机值。而后用证书对该随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,否则看不到被锁住的内容。

  5. 传送加密信息

  这部分传送的是用证书加密后的随机值,目的就是让服务端获得这个随机值,之后客户端和服务端的通讯就能够经过这个随机值来进行加密解密了。

  6. 服务段解密信息

  服务端用私钥解密后,获得了客户端传过来的随机值(私钥),而后把内容经过该值进行对称加密。所谓对称加密就是,将信息和私钥经过某种算法混合在一块儿,这样除非知道私钥,否则没法获取内容,而正好客户端和服务端都知道这个私钥,因此只要加密算法够彪悍,私钥够复杂,数据就够安全。

  7. 传输加密后的信息

  这部分信息是服务段用私钥加密后的信息,能够在客户端被还原。

  8. 客户端解密信息

  客户端用以前生成的私钥解密服务段传过来的信息,因而获取了解密后的内容。整个过程第三方即便监听到了数据,也一筹莫展。

 

5.总结整个过程:

1.服务器向CA机构获取证书(假设这个证书伪造不了),当浏览器首次请求服务器的时候,服务器返回证书给浏览器。(证书包含:公钥+申请者与颁发者的相关信息+签名

2.浏览器获得证书后,开始验证证书的相关信息,证书有效(没过时等)。(验证过程,比较复杂,详见上文)。

3.验证完证书后,若是证书有效,客户端是生成一个随机数,而后用证书中的公钥进行加密,加密后,发送给服务器,服务器用私钥进行解密,获得随机数。以后双方便开始用该随机数做为钥匙,对要传递的数据进行加密、解密。

 

 

 

 

关于https:http://blog.csdn.net/wangjun5159/article/details/51510594

 

 

 

 

 

 

 

 

 

 

 

引用参考博客:http://kb.cnblogs.com/page/194742/

关于https的误解:http://www.admin5.com/article/20150523/600106.shtml

相关文章
相关标签/搜索