SSL如何真正起作用？

SSL如何工作？

证书在客户端(或浏览器？)和服务器(或Web服务器？)上安装在哪里？

当您将URL输入浏览器并从服务器获取页面时,信任/加密/身份验证过程如何开始？

HTTPS协议如何识别证书？当所有信任/加密/认证工作的证书是什么时,为什么HTTP不能使用证书？

1> Mark E. Haas..：

---

注意:我非常仓促地写了我原来的答案,但从那时起,这已成为一个相当受欢迎的问题/答案,所以我对它进行了一些扩展并使其更精确.

TLS功能

"SSL"是最常用于引用此协议的名称,但SSL特别指的是Netscape在90年代中期设计的专有协议."TLS"是基于SSL的IETF标准,因此我将在答案中使用TLS.现在,可能性几乎所有网络上的安全连接都使用TLS,而不是SSL.

TLS有几个功能:

加密您的应用程序层数据.(在您的情况下,应用程序层协议是HTTP.)

向客户端验证服务器.

将客户端验证到服务器.

#1和#2很常见.#3不太常见.你似乎专注于#2,所以我将解释那部分.

认证

服务器使用证书向客户端验证自身.证书是一团数据[1],其中包含有关网站的信息:

域名

公钥

拥有它的公司

什么时候发出

当它到期时

是谁发行的

等等.

您可以通过使用证书中包含的公钥来加密只能由相应私钥解密的消息来实现机密性(上面的#1),这些私钥应该安全地存储在该服务器上.[2] 让我们称这个密钥对KP1,以便我们以后不会混淆.您还可以验证证书上的域名是否与您访问的站点匹配(上面的#2).

但是,如果攻击者可以修改发送到服务器和从服务器发送的数据包,如果该攻击者修改了您提供的证书并插入了自己的公钥或更改了任何其他重要细节,该怎么办？如果发生这种情况,攻击者可以拦截并修改您认为安全加密的任何邮件.

为了防止这种非常大的攻击,证书由其他人的私钥加密签名,以便签名可以由具有相应公钥的任何人验证.让我们称这个密钥对KP2,以明确这些密钥与服务器使用的密钥不同.

证书颁发机构

那么谁创造了KP2？谁签了证书？

证书授权机构过度简化了一点,创建了KP2,他们销售使用私钥为其他组织签署证书的服务.例如,我创建了一个证书,我向Verisign这样的公司付款,用他们的私钥签名.[3] 由于Verisign没有人可以访问此私钥,因此我们都无法伪造此签名.

我将如何亲自获得KP2中的公钥以验证签名？

好吧,我们已经看到证书可以保存公钥 - 计算机科学家喜欢递归 - 那么为什么不将KP2公钥放入证书中并以这种方式分发呢？起初听起来有点疯狂,但实际上这正是它的工作原理.继续Verisign示例,Verisign生成一个证书,其中包含有关他们是谁,允许他们签署什么类型的事物(其他证书)以及他们的公钥的信息.

现在,如果我有Verisign证书的副本,我可以使用它来验证我想访问的网站的服务器证书上的签名.容易,对吧？!

好吧,不是那么快.我必须从某个地方获得Verisign证书.如果有人欺骗Verisign证书并将自己的公钥放在那里怎么办？然后他们可以在服务器的证书上伪造签名,我们就回到我们开始的地方:一个中间人攻击.

证书链

继续以递归方式思考,我们当然可以引入第三个证书和第三个密钥对(KP3)并使用它来签署Verisign证书.我们称之为证书链:链中的每个证书都用于验证下一个证书.希望您已经可以看到这种递归方法只是乌龟/证书.它停在哪里？

由于我们无法创建无限数量的证书,因此证书链显然必须停在某处,并且通过在自签名的链中包含证书来完成.

当你从脑袋里捡起脑部物质时,我会暂停片刻.自签名？

是的,在证书链的末尾(也就是"根"),将有一个证书使用它自己的密钥对来签署自己.这消除了无限递归问题,但它不能解决身份验证问题.任何人都可以创建一个自签名的证书,上面写着任何东西,就像我可以创建一个假的普林斯顿文凭,说我在政治,理论物理和应用屁股踢三个主要,然后在底部签署我自己的名字.

解决此问题的[有点令人兴奋]的解决方案就是选择一些您明确信任的自签名证书.例如,我可能会说,"我相信这张Verisign自签名证书."

有了明确的信任,现在我可以验证整个证书链.无论链中有多少证书,我都可以将每个签名一直验证到根目录.当我到达root时,我可以检查该根证书是否是我明确信任的证书.如果是这样,那么我可以相信整个链条.

授予信托

TLS中的身份验证使用授予信任的系统.如果我想雇用一名汽车修理工,我可能不相信任何我发现的随机技工.但也许我的朋友要为特定的机械师担保.因为我相信我的朋友,所以我可以相信那个技师.

当您购买计算机或下载浏览器时,它会附带几百个明确信任的根证书.[4] 拥有和运营这些证书的公司可以通过签署证书将这种信任授予其他组织.

这远非一个完美的系统.有时,CA可能会错误地颁发证书.在这些情况下,可能需要撤销证书.撤销是棘手的,因为颁发的证书将始终是加密正确的; 需要一个带外协议来找出哪些以前有效的证书已被撤销.在实践中,其中一些协议不是很安全,许多浏览器无论如何都不检查它们.

有时整个CA都会受到损害.例如,如果您要进入Verisign并窃取其根签名密钥,那么您可以欺骗世界上的任何证书.请注意,这不仅会影响Verisign客户:即使我的证书由Thawte(Verisign的竞争对手)签署,也无关紧要.我的证书仍然可以使用威瑞信的受感染签名密钥伪造.

这不仅仅是理论上的.它发生在野外.DigiNotar被着名的黑客入侵,随后破产.Comodo也遭到了黑客袭击,但令人费解的是他们至今仍在营业.

即使CA没有直接受到攻击,该系统也存在其他威胁.例如,政府使用法律强制迫使CA签署伪造证书.您的雇主可以在您的员工计算机上安装自己的CA证书.在这些不同情况下,您希望"安全"的流量实际上对控制该证书的组织完全可见/可修改.

已经提出了一些替代方案,包括Convergence,TACK和DANE.

尾注

[1] TLS证书数据根据X.509标准格式化.X.509基于ASN.1("抽象语法表示法#1"),这意味着它不是二进制数据格式.因此,X.509必须编码为二进制格式.DER和PEM是我所知道的两种最常见的编码.

[2]在实践中,协议实际上切换到对称密码,但这是一个与您的问题无关的细节.

[3]可以预测,CA实际上会在签署证书之前验证您的身份.如果他们没有这样做,那么我可以为google.com创建一个证书并要求CA签名.凭借该证书,我可以与google.com建立任何"安全"连接.因此,验证步骤是CA操作中非常重要的因素.不幸的是,目前还不是很清楚这个验证过程在世界各地的数百个CA中是多么严格.

[4]参见Mozilla的可信CA列表.

---

@KorayTugay:http://stackoverflow.com/questions/3603714/asymmetric-encryption

2> sanjay_kv..：

---

HTTPS是HTTP和SSL(安全套接字层)的组合,用于在客户端(浏览器)和Web服务器(此处托管应用程序)之间提供加密通信.

为什么需要？

HTTPS加密通过网络从浏览器传输到服务器的数据.因此,没有人可以在传输过程中嗅探数据.

如何在浏览器和Web服务器之间建立HTTPS连接？

浏览器尝试连接到https://payment.com.

payment.com服务器向浏览器发送证书.此证书包括payment.com服务器的公钥,以及此公钥实际属于payment.com的一些证据.

浏览器验证证书以确认它具有payment.com的正确公钥.

浏览器选择随机的新对称密钥K用于连接到payment.com服务器.它在payment.com公钥下加密K.

payment.com使用其私钥解密K. 现在浏览器和支付服务器都知道K,但没有其他人知道.

任何时候浏览器都想向payment.com发送内容,它会在K下对其进行加密; payment.com服务器在收到后对其进行解密.每当payment.com服务器想要向您的浏览器发送内容时,它都会在K下对其进行加密.

此流程可以通过下图表示: