打扰一下,如果这个问题真的很天真,但我尽可能多地搜索,但没有找到相关的答案。
我花了最后三天试图了解https的工作原理。 在这些日子之前,我所知道的是对称和非对称密码术的工作原理。 现在是时候了解这两个如何应用于ssl-https并实现所谓的数据加密和服务器身份验证。
关于数据加密和防止中间人攻击的一切都很清楚
虽然我似乎并不完全了解服务器身份验证的工作原理,但我们将非常感谢您的帮助。
到目前为止,我的理解如下:
当客户端通过https连接到服务器时,服务器会发送CA证书签名。 此服务器证书是一个文本文件,包含有关服务器的信息(名称,所有者电子邮件,公钥等..),以及数字签名。
此签名是服务器信息内容的哈希值,由CA私钥加密。
客户端通过再次生成服务器信息的哈希值并使用CA的公钥解密签名来检查签名的有效性。如果解密的签名值与生成的哈希值相同,则签名和证书随后有效。
请注意,公共 - 私有加密方案具有双重性质。消息可以由公钥加密并由私钥解密。可以使用私钥加密相同的消息,也可以通过公钥解密。
我们需要牢记的是,证书是一个静态且不可更改的文件。对文件的任何更改都将导致签名不匹配。
我现在将描述一种欺骗https的方法:
让我们说一个网址为https://wwww.TheBank.com/ebanking的ebanking网站(公共IP = 195.134.0.1) 我连接到此URL,我的浏览器获取服务器证书。 (theBank.cer)
与此同时,我是网吧的老板。我的网吧有自己的路由器,DNS和DCHP服务器,我有知识可以控制。它也有一个Web服务器。
我将Web服务器配置为拥有ip 195.134.0.1,与银行相同 我创建了一个到我的路由器的路由,它将195.134.0.1的连接请求发送到我的Web服务器 我配置我的DNS以将上面的银行URL指向195.134.0.1(我的网络服务器) 我在我的网络服务器上放置了一个欺诈性的银行网站。对于此站点上的任何连接,我指示Web服务器将之前下载的证书发送给客户端。(theBank.cer)
用户来到我的咖啡馆,连接到我的网络并尝试连接到该银行。我的服务器向他发送银行证书。他的浏览器将确认证书的有效性,因为它确实是有效证书,并允许连接到我的虚假网站,因为它的URL,IP和主机名与真实网站相同。
所以我的欺诈行为是成功的。
对于科西嘉来说,这个安全漏洞太明显了。意思是我在服务器身份验证过程中没有理解。有人可以向我解释一下我在这里缺少什么吗?
答案 0 :(得分:3)
用户来到我的咖啡馆,连接到我的网络并尝试连接到该银行。我的服务器向他发送银行证书。他的浏览器将确认证书的有效性,因为它确实是有效证书,并允许连接到我的虚假网站,因为它的URL,IP和主机名与真实网站相同。
一旦他的浏览器确认了有效性,它就知道银行的真实公钥,因为它在证书中。由于您的服务器无法使用与该公钥对应的私钥进行任何签名,也无法解密使用该公钥加密的任何内容,因此您根本无法模拟该银行。您所能做的就是让用户相信银行的真实身份,您无法冒充身份。
我认为您遗漏的关键是证书的主要目的是让受信任的机构将现实世界的身份绑定到公钥,这样只有该真实世界身份的所有者知道相应的私钥。
答案 1 :(得分:0)
theBank.cer
是公开键
你不能用它来解密或签署任何东西。
答案 2 :(得分:0)
此签名是服务器信息内容的哈希值, 由CA私钥加密。
客户端再次生成-on来检查签名的有效性 他自己 - 服务器信息的哈希并使用解密签名 CA的公钥。如果解密的签名值与之相同 随后生成的哈希,签名和证书 有效的。
这或多或少与RSA有关,但与DSA不同,后者仅为签名(无加密)。
通常,您不应该谈论使用私钥“加密”。它没有任何意义,因为任何人都可以用公钥解密(因为它是公开的)。加密是关于隐藏信息。
使用私钥可以执行的操作是签名和解密/解密。使用公钥可以执行的操作是加密并验证签名。
如果在需要加密和需要签名时混淆(尽管算法与RSA非常相似),您最终可能会设计不提供任何安全性的系统。
更一般地说,公钥证书(X.509证书,甚至PGP证书)的目的是将身份(例如服务器主机名)绑定到公钥。 (见this question on Security.SE。)
我的网络服务器将收到的数据将由公众加密 银行的关键
请注意,SSL / TLS流量未使用证书的私钥加密,而是在SSL / TLS握手期间协商的共享密钥。
在SSL / TLS握手期间,该公钥用于加密预主密钥或签署其他参数(取决于密码套件),最终向客户端证明它正在与服务器通信拥有此公钥的私钥。
由于证书还将服务器名称绑定到公钥,因此客户端知道它正在与正确的服务器进行通信。
这就是为什么重要的是验证(a)证书是否可信,以及(b)它是否发布到客户端想要连接的服务器名称。