Apache：验证SSL信任链以防止MITM攻击吗？

11

我刚刚意识到SSL中间人攻击比我想象的要普遍得多，尤其是在公司环境中。我听说过一些企业，这些企业安装了透明的SSL代理服务器。所有客户端都配置为信任此代理的证书。基本上，这意味着从理论上讲，雇主甚至可以拦截SSL加密的流量，而不会在浏览器中弹出任何警告。如上所述，客户端附带证书是受信任的。这只能通过手动验证正在使用的证书来揭示。

在我看来，雇主似乎在利用自己的优势监视员工的SSL流量。对我来说，这使SSL的整个概念变得不可信。我自己使用mitmproxy成功地测试了类似的设置，并且能够读取客户端与我的电子银行服务器之间的通信。这是不应该透露给任何人的信息。

因此，我的问题很简单：如何验证服务器端的信任链？我想确保客户端使用我的服务器的证书并且只有一个信任链。我想知道这是否可以通过Apache的SSL配置来实现？这将很方便，因为它可以轻松地应用于许多应用程序。如果这不可能，那么有人知道用PHP做到这一点的方法吗？或者您还有其他建议吗？

— 副翼79
source

1

雇主可以看到员工的交通情况。您正在使用雇主的资源（个人计算机，网络连接等），这些资源不是您的。而且，如果您担心emplyer会看到传输到银行帐户的数据，请在家中而不是在工作中进行。违反公司安全政策的企图可能会成为法院针对您的主题。

— Crypt32

2

在许多欧洲公司中，对办公设备的私人使用受雇佣合同的约束。在我工作的公司里，我可以私下冲浪，这不是问题。有色情，文件共享等例外。同时，有法律禁止公司监视其雇员。因此，对我-以及其他许多人-雇主拦截员工流量并不是一件好事，因为在许多公司中允许私人冲浪的同时，这显然是被禁止的。

— Aileron79年

2

根据我的经验，大多数美国政府拥有的工作站在每次登录时都会包含以下两个通知：“使用此IS进行的通信或存储的数据不是私有的，受到例行监视，拦截和搜索，并且可能被披露或使用。用于任何USG授权目的。此IS包括用于保护USG利益的安全措施（例如，身份验证和访问控制），而不是为了您的个人利益或隐私。” 这些系统的使用通常在规定该系统的已签署协议中涵盖。关键细节是系统的所有者正在保护自己免受您的侵害。

— Randall

那是美国与欧洲之间众多差异之一。上面引用的@Randall术语在大多数欧洲国家都是非法的。

— Aileron79年

我引用的术语不完整，其他术语列出了明确不受监控的活动。我找不到任何参考资料指出欧洲雇主不能将这样的前提条件作为使用其计算机的条件（我为在欧洲经营的公司工作，建立了这样的监控流程，尽管我为一家在欧洲没有业务的部门工作欧洲），但可以找到暗示此类术语不违法的引用，只要它们是明确且透明的即可。

— Randall

9

我认为这个问题更适用于security.stackexchange.com，其中在许多问题中都讨论了MITM的主题。但不管怎么说：

服务器证书的验证仅在客户端进行，不能以任何方式移到服务器，因为在客户端验证证书的关键是客户端需要确保它正在与正确的服务器通信并且不能信任服务器。（不受信任的）服务器为客户端做出此决定。

对于SSL拦截，从服务器的角度来看，TLS客户端是SSL拦截防火墙/ AV。因此，服务器端的问题是检测它是否正在与预期的客户端（浏览器）进行通信（防火墙/ AV）。最安全的方法是使用客户端证书对客户端进行身份验证-实际上，如果使用客户端身份验证，则SSL侦听将不起作用，即TLS握手将失败，因为MITM无法提供预期的客户端证书。

只有很少使用客户端证书。同样，失败的TLS握手并不意味着客户端可以在没有SSL拦截的情况下与服务器通信，而是客户端根本无法与服务器通信。一种替代方法是使用一些启发式方法，基于TLS握手的指纹来检测TLS客户端的类型，即密码的类型和顺序，使用特定扩展名……而SSL拦截代理理论上可以模仿原始客户端ClientHello完全不是。又见检测人在这方面的中间人在服务器端对HTTPS或者部分III TLS实施启发式在HTTPS拦截安全的影响。

— 斯蒂芬·乌尔里希（Steffen Ullrich）
source

14

在我看来，雇主似乎在利用自己的优势监视员工的SSL流量。对我来说，这使SSL的整个概念变得不可信

问题不在于SSL的概念，也不在于技术的实现，而在于其他人可以完全控制连接的一个端点，即您的工作站。
这是实际安全风险的根源...

从安全的角度来看，是您的工作站受到了破坏，这破坏了信任链，在正常情况下，这种信任链会阻止MITM成功。

如何验证服务器端的信任链？

你不能那是在客户端完成的。

根据您的用例，您可以做的是RFC 7469 HTTP公钥固定，在其中您向客户端发送了一个附加标头，其中包含您的实际SSL证书或所用CA的列表（哈希值）。

— 鲁比恩
source

4

HPKP将无济于事，因为如果证书由显式添加的CA签名，浏览器将忽略它。专门这样做是为了允许受信任方（即公司防火墙或本地桌面AV）进行SSL拦截（许多SSL拦截到）。

— 斯蒂芬·乌尔里希

2

您绝对正确：RFC§2.6：“可以根据本地策略对某些主机禁用引脚验证。例如，UA可能会禁用对已验证证书链终止于此的固定主机的引脚验证。用户定义的信任锚，而不是内置到UA（或基础平台）的信任锚。”

— HBruijn

3

那是错误的方式。服务器不检查信任链。是客户。因此，公司采用这种方式的原因是为了保护公司环境并检查员工在工作时间内的工作。

— 相信
source

好吧，是的，我知道仅在服务器端可能无法避免这种情况。但是，某些客户端JS也可能被欺骗。顺便说一句，在大多数欧洲国家/地区监视雇员是非法的。作为网站运营商，我想防止客户被骗，因此，我想知道是否有任何方法可以安全地验证信任链。

— Aileron79年

也许是不允许的。但是大多数公司不监视员工，只希望保护那里的公司网络，并且大多数Web筛选器或扫描仪必须断开SSL连接才能进行检查。因此，这是中级攻击者

— 合法

我明白你的意思。但是，这个问题是关于如何确保HTTPS连接端到端加密的问题。我上面描述的设置在公司环境中非常普遍，但是嫉妒的男孩可能会使用相同类型的间谍来监视女友，或者房东可能会截取房客的交通。这些人仍然需要欺骗安装证书，但这是简单的部分。但是，这是非法的-我仍然想知道是否有任何方法可以确保HTTPS连接确实是加密的e2e。

— Aileron79年

3

那不可能在客户端上更改了根证书后，您将无法对其进行检查。服务器不进行检查，客户端进行检查。

— beli3ver

3

您COULD（样），但真正的问题是你是否SHOULD。

但是请注意，它远没有更改apache.conf中的标志那么简单。

另外，由于“攻击者”（例如雇主）控制客户端计算机，如果他们倾向于投入足够的精力，他们总是可以挫败您的尝试（从好的方面来说，除非您是大鱼，否则他们很可能不会倾斜，这样您就可以实现自己的目标，除非您的用户安全，否则您的用户将无法连接到您）

您可以在javascript中重新实现TLS，并在其中进行检查（如果客户端连接的证书是您网站的证书）。
如果幸运的话，用户可能正在使用浏览器，客户端Javascript可以在该浏览器上获取有关所使用的远程证书的信息（从而可以轻松地针对服务器证书的硬编码值对其进行验证）。
您可以使用JavaScript来运行自定义加密。因此，即使该公司的恶意TLS MiTM成功了，它仍然不会授予其访问您的数据的权限。当然，如果有足够的兴趣（并且由于他们控制客户端），他们可以用自己的动态替换您的安全javascript，该javascript还记录（或更改）传输中的所有信息。

此外，由于使用TLS MiTM代理的企业通常也完全控制客户端计算机，因此他们可以轻松地安装屏幕和按键记录器，以简单地记录用户看到的所有内容的视频，并记录用户键入的所有按键（和鼠标移动）。如您所见，当攻击者是客户端时，没有绝对安全的方法来欺骗他。实际上，这只是一个问题，它们将给您带来多大的麻烦……上面的一些解决方案可能对您来说已经足够了。

— 马蒂娅·纳里斯（Matija Nalis）
source

“ 您可以在javascript中重新实现TLS ”怎么办？哪里？

— curiousguy18年

@ curiousguy，qouted文本是一个链接-单击它，它会带您到另一个问题和答案，最后是digitalbazaar / Forge项目

— Matija Nalis

那么，什么时候可用？出于什么目的？

— curiousguy18年

@curiousguy等等，尤其是用于此Serverfault问题中要求的目的。当您在客户端上运行自己的JS TLS时，该客户端JS将确切知道客户端已连接到哪个TLS服务器（以及它的公钥）。然后，您可以将该公用密钥与授权服务器公用密钥（也在您的JS中进行硬编码）进行比较，是否可以知道它们是否相同。如果它们不相同，则说明您的连接已被MiTM劫持。

— Matija Nalis