是什么阻止黑客在非对称加密中伪装成具有公钥的服务器/客户端？

作者: Minions
发布时间: 2024-08-18 05:38:03 (15天前)
转自：

5 条回复

0#
回复此人
雪浴冰灵 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 黑客设法捕获亚马逊的公钥 </p> </BLOCKQUOTE> <P> 亚马逊的公钥是公开的。每个人都知道。 2018年5月3日发布的那个开始“A9 F4 4A 9B 29 84 20 A7 53 FF BA 01 B5 1E 0C 2A A7 53”。公钥/私钥密码学的全部意义在于公钥不是秘密。因此捕获公钥并不重要。 </p> <P> 你的问题不是关于伪装成亚马逊（即与亚马逊的钥匙有关）。这是关于伪装成亚马逊的。这是一个完全不同的情况。您没有使用证书（称为“客户端证书”）向Amazon标识自己，因此证书和公钥/私钥加密与此无关。是;任何人都可以使用他们的公钥向亚马逊发送消息加密，但这不是你如何证明你是谁。 </p> <P> 相反，您使用凭据（通常是用户名和密码）向Amazon表明自己的身份。当您这样做时，亚马逊会向您发送一个会话令牌，这只是一个在数据库表中映射到您的大随机数（或者有时会话令牌是有关会话的加密信息，因此不需要数据库）。经过身份验证后，您不断将会话令牌传递回亚马逊，说“您已经知道并信任我是谁”。 </p> <P> 那么如果有人捕获会话令牌呢？那将是一件大事。这绝对允许你所描述的内容。会话令牌必须受到保护，只要它有效。当我们使用TLS将其传递给亚马逊时，我们会保护它“防止嗅探器知道消息的内容”，因此攻击者希望无法发现会话ID。 </p> <P> 窃取会话ID有很多攻击，大致称为“会话劫持”。其中一个比较有名的是 <a href="https://en.wikipedia.org/wiki/Firesheep" rel="nofollow noreferrer"> Firesheep </A> ，它依赖于不安全（HTTP）会话。但是，有更多针对HTTPS的高级攻击，例如 <a href="https://en.wikipedia.org/wiki/CRIME" rel="nofollow noreferrer"> 犯罪 </A> 和 <a href="https://en.wikipedia.org/wiki/BREACH" rel="nofollow noreferrer"> 违反 </A> 。 TLS的改进减轻了各种已知的攻击，但总有可能出现新的攻击。 </p> </DIV>

编辑
1#
回复此人
烏鴉喝酒 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 请查看TLS握手协议，该协议清楚地说明了TLS中发生的情况： <a href="https://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol" rel="nofollow noreferrer"> https://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol </A> </p> <OL> <LI> <P> 连接到amazon时没有私钥或公钥，因为您没有使用客户端证书进行身份验证。 </p> </LI> <LI> <P> 如果黑客窃取了您的公钥，这不是问题，因为您的公钥只能用于发送加密邮件的<strong> 您 </强> 。只要的<strong> 您 </强> 可以解密这些消息，因为只有的<strong> 您 </强> 拥有匹配的私钥。这就是非对称加密的全部意义所在！ </p> </LI> </醇> </DIV>

编辑
2#
回复此人
Hey ou | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 假设我在亚马逊上购物，当亚马逊与我交换时，黑客设法捕获亚马逊的公钥。 </p> </BLOCKQUOTE> <P> 使用亚马逊的公钥加密的数据只能使用亚马逊的私钥解密。 </p> </DIV>

编辑
3#
回复此人
你咖喱人biss嗷 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 什么阻止黑客使用公钥来加密消息并伪装成他不是的人？假设我在亚马逊上购物，当亚马逊与我交换时，黑客设法捕获亚马逊的公钥。难道这个黑客不能通过简单地修改他的数据包的标题看起来像是来自我的电脑而假装成我吗？ </p> </BLOCKQUOTE> <P> 非常好的问题。 TLS通过在握手协议期间在客户端和服务器之间创建会话密钥来防止这种情况。有两种类型的密钥：一种用于加密（通常是AES），另一种用于 <a href="https://en.wikipedia.org/wiki/Message_authentication_code" rel="nofollow noreferrer"> 消息完整性/消息认证 </A> （MAC）（通常是HMAC）。会话期间的所有通信都使用对称加密密钥加密，并使用MAC密钥进行MAC加密。服务器不接受未使用MAC密钥正确签名的任何数据。因此，只有拥有这些密钥的人才能与该服务器进行通信。 </p> <P> 因此，问题可以简化为攻击者如何确定在初始TLS握手期间设置的加密和MAC密钥。请注意，在握手期间，服务器通过证书将其公钥提供给客户端，客户端验证证书是否有效 - 包括它属于证书中声明的域。这允许客户端验证它正在与正确的服务器通信，假设没有人可以绕过PKI（即证书颁发机构正在做正确的事情，没有人可以破解公钥加密）。现在，不同的客户端可以与服务器建立不同的会话，但它们都是使用每个客户端生成的私钥完成的，并且每个客户端都是唯一已知的。因此，每个客户端使用只有他们知道的密钥以及其他任何人都不知道的密钥以独特的方式设置其会话。 </p> <P> 如果你想深入挖掘整个设计还有更多，包括如何使用序列号来防止重放攻击。但我希望你能得到一般的想法。 </p> </DIV>

编辑

登录后才能参与评论