应用层校验和,因为TCP校验和可能太弱?

4
这篇论文(当 CRC 和 TCP 校验和不一致时)指出,由于 TCP 校验算法相对较弱,使用 TCP 传输的每 1600 万到 100 亿个数据包中会发生一个未被检测到的错误。
是否有应用程序开发人员通过在应用程序层添加校验和来保护数据免受此类错误的影响?
在进行 EJB 远程方法调用(Java EE 5)时,是否有可用的模式来防止此类错误?或者 Java 是否已经自动为序列化对象添加校验和(除了底层网络协议之外)?
企业软件不仅可以在计算机上运行内存 ECC,还可以在 CPU 中的寄存器等位置进行错误检查(SPARC 和其他处理器)。使用 Solaris ZFS 可以防止存储系统(硬盘、电缆等)中的位错误。
因为 TCP 的存在,我从来没有担心过网络位错误,直到看到那篇文章。
对于一些非常少量的客户端-服务器远程接口,实现应用程序级别的校验和可能并不需要太多工作。但是对于在单个数据中心中运行在许多计算机上的分布式企业软件来说,可能会有大量的远程接口。
每个企业软件供应商,例如 SAP、Oracle 等等,都会忽略这种问题吗?银行呢?证券交易软件呢?
跟进:非常感谢您所有的回答!所以似乎检测未检测到的网络数据损坏相当不常见 - 但它们似乎确实存在。
我是否可以通过配置 Java EE 应用程序服务器(或 EJB 部署描述符)使用 TLS 上的 RMI,并将 TLS 配置为使用 MD5 或 SHA1,并配置 Java SE 客户端执行相同操作来解决此问题?这是否是一种获得可靠透明校验和的方法(虽然过度),以便我不必在应用程序级别上实现此功能?或者我对网络堆栈完全困惑了?

一些关于该问题的评论:http://criticalindirection.com/2016/02/22/tcp-checksum-the-fault-in-the-stars/ - user31986
3个回答

2

我曾经为IBs工作过交易系统,并且可以向您保证,没有额外的校验和检查 - 大多数应用程序使用裸套接字。考虑到当前金融行业的问题,我认为糟糕的TCP/IP校验和应该是您最不用担心的问题。


@altCognito请不要编辑我的答案以改变它们的意思。谢谢。 - anon
这是一个过早优化的案例 http://c2.com/cgi/wiki?PrematureOptimization(旧答案已删除,我感到害怕) - cgp

2
我相信每个关心数据完整性的应用程序都应该使用安全哈希。然而,大多数人并不这样做。人们只是忽略了这个问题。
虽然多年来我经常看到数据损坏 - 即使是通过校验和检查也会出现 - 但最令人难忘的实际上是一个股票交易系统。一台坏路由器正在破坏数据,以至于它通常可以通过TCP校验和。它在开关同一位。当然,对于那些实际上未通过TCP校验和的数据包,没有人会受到警报。该应用程序没有额外的数据完整性检查。
这些消息是股票订单和交易之类的东西。破坏数据的后果就像听起来那样严重。
幸运的是,数据的损坏导致消息无效,结果导致交易系统完全崩溃。失去一些业务的后果远不及执行虚假交易的潜在后果严重。
我们依靠运气识别了这个问题 - 两个涉及的服务器之间的某个人的SSH会话失败并出现了奇怪的错误消息。显然SSH必须确保数据完整性。
在这件事情发生后,公司没有采取任何措施来减轻在传输或存储中的数据损坏的风险。同样的代码仍在生产中,并且实际上还有其他代码进入了生产环境,假定其周围的环境永远不会破坏数据。
对于所有涉及的个人来说,这实际上是正确的决定。防止由系统的其他部分(例如,坏内存、坏硬盘控制器、坏路由器)引起的问题的开发人员不太可能获得任何好处。额外的代码会增加添加错误或被归咎于与实际上无关的错误的风险。如果以后出现问题,那将是别人的错。
对于管理层来说,这就像花时间处理安全性问题。事故发生的几率很低,但“浪费”的工作是可见的。例如,注意到端到端数据完整性检查已经与过早的优化进行了比较。
至今自那篇论文以来发生了什么变化 - 所有的变化都是我们拥有更高的数据速率、更复杂的系统和更快的CPU,使得加密哈希的成本更低。更多的损坏机会,更少的预防成本。
真正的问题是,在您的环境中,检测/预防问题是否更好,还是忽略它们。请记住,通过检测问题,它可能成为您的责任。如果您花时间预防管理层不认为是问题的问题,那么就会让您看起来像在浪费时间。

1

好的,那篇论文是2000年的了,所以它来自很久以前(天哪,我老了),而且是在一组相当有限的痕迹上。 所以要对他们的数字保持怀疑态度。 也就是说,看看现在是否仍然是这种情况会很有趣。 然而,我认为情况已经改变了,尽管某些类型的错误可能仍然存在,例如硬件故障。

如果您真的需要额外的应用程序级别保证,与其使用校验和不如使用数据的SHA-N哈希值或MD5等更为实用。


2
这份文档虽然是2000年的,但TCP协议及其校验和更古老 - 来自上个世纪七十年代 - 而错误仍然存在。因此,我不认为它会因变得太“古老”而消失。 - Andrey

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接