und*_*one 9 security ssl cryptography certificate ssl-certificate
我已经阅读了有关SSL协议的内容,现在,我知道它如何加密数据.但有一些我无法理解的东西.使用SSl,您确定要向正确的服务器发送数据并从中获取数据.但怎么样？
我的意思是,如果我创建假证书并将其发送给特殊网站的请求,浏览器(或其他程序)如何检测假证书？
编辑:我不是要创建一个自签名证书.我的意思是,如果我创建一个证书,证明其发行人和主题等是真正的证书,我怎么能验证我的证书!(唯一不真实的是公钥和签名)
emb*_*oss 16
TL; DR摘要:
服务器证书的有效性通过以下方式建立:
假设您要连接到https://mail.google.com(您可以在浏览器中试用它!).
(真实)服务器将使用颁发的证书进行响应mail.google.com,即在证书的"主题"字段中,您将找到公用名(CN)'mail.google.com' - cf. RFC 5280有关证书字段的详细信息.主题链接到站点URL的事实对于整个模型的安全性非常重要,并且它由TLS实现("主机名验证")主动检查,因为否则将存在Man-In-的空间中间攻击.也就是说有人可以获得一个其他有效的证书并模仿mail.google.com而你没有注意到它.
除主机名验证外,您的TLS实施还将检查证书的"有效性".整个过程相当复杂,包括检查证书的可信度,但另外还会检查很多其他内容,更多内容将在一分钟内完成.
如果您在浏览器中查看Google Mail的证书,您会注意到实际上显示了三个证书:
模型是有一些(很好,不幸的是不再那么少)受信任的根证书颁发机构("根CA"),您可以自己选择,也可以(更有可能)预先配置您的软件(例如浏览器)盲目信任.这些受信任的权威机构构成了"PKI"(公钥基础设施)的整个信任模型的锚点.基本思想是,可信实体可以向其他权限颁发证书,并授予他们再次颁发证书的权限(这些权限称为中间证书颁发机构).中间CA可以再次递归地将该过程应用到某一点,实际的最终实体证书和根CA证书之间的中间CA的数量通常是有限的.
有一次,中间CA会向"最终实体"(在我们的示例中为"mail.google.com")颁发证书.现在,颁发证书的过程实际上意味着请求证书的一方将首先创建公钥/私钥对,并使用它们来验证发送给证书颁发机构的证书请求.发布机构通过使用诸如RSA的非对称算法以及通过在新的内部附加地包括请求方的公钥来使用其自己的私钥"签署"该证书来为下级实体(中间CA或最终实体)创建证书.生成证书.根CA拥有所谓的自签名证书,即根CA是唯一可以签署自己的证书并包含其自己的公钥的权限.当然,私钥在任何时候都是隐藏的.
证书颁发过程的递归性质意味着对于每个最终实体证书,存在建立证书"链"的唯一方式,该证书链通向根证书颁发机构.现在,当您在尝试连接到受TLS保护的站点时获得最终实体证书时,将以递归方式应用以下过程,直到您最终获得根CA证书:
如果所有检查都是肯定的,您最终将获得自签名证书,即主题也是发行人(例如我们示例中的VeriSign证书).现在你需要验证的最后一件事是这个证书是否是你盲目信任的证书之一:如果是,一切都很好,连接将成功,如果不成功,连接尝试将被拒绝.
好像这已经不够复杂了,到目前为止所描述的检查并不处理曾经有效证书突然变得流氓的情况,例如证书被盗或私钥被泄露的情况(想想Comodo和DigiNotar).在这些情况下,正常的程序是"撤销"那些坏的证书,也就是说你想从一个不同的时间点开始将它们标记为无效(无论如何它们将在某个时候到期,但在那段时间的剩余时间内)它们已被标记为无效).对于这些情况,CA可以发出CRL(声明为无效的证书目录)或OCSP响应(一个或极少数情况下是一组证书的信息),为客户提供有关给定证书是否已被标记为无效的信息或不.需要检查链中所有证书的撤销状态,如果其中一个被标记为无效,则无法信任最终实体证书,并且也必须拒绝连接.
SSL证书由证书颁发机构(CA)签名,证书颁发机构是用户已经信任的人(或者更有可能是设计其操作系统信任的人员).
CA使用公钥加密对证书进行数字签名.基本的解释是CA有一个"私钥",以及每个人都知道的"公钥".通过一些数学我不明白,CA可以使用其私钥创建签名,可以使用其公钥轻松验证(但公钥不能用于创建新签名).
当您从服务器获得SSL证书时,您将获得服务器的公钥,以及来自CA的签名,说明它是有效的(以及其他一些信息).如果您知道并信任该CA,则可以检查签名并确定其是否有效.您还可以使用证书吊销列表来确保它未被撤销.
基本上,您可以识别错误的SSL证书,因为它没有您信任的证书颁发机构签名.
| 归档时间： |
|
| 查看次数： |
16644 次 |
| 最近记录： |