【问题标题】:Is the integrity of file uploads/downloads guaranteed by TCP/HTTPS?TCP/HTTPS 是否保证文件上传/下载的完整性?
【发布时间】:2021-04-28 17:25:58
【问题描述】:

假设我想将文件上传到网络服务器。甚至可能是一个相当大的文件(例如 30 MB)。它是通过典型的文件上传表单完成的(参见下面的最小示例)。

现在网络并不完美。我看到这些类型的错误是可能的:

  1. 可能发生位翻转
  2. 包裹可能会丢失
  3. 包裹到达的顺序可能不是发送的顺序
  4. 一个包裹可能会收到两次

看了TCP wiki article,我明白了

在协议栈的较低级别,由于网络拥塞、流量负载平衡或不可预测的网络行为,IP 数据包可能会丢失、重复或无序传送。 TCP 检测到这些问题,请求重新传输丢失的数据重新排列乱序数据,甚至有助于最大限度地减少网络拥塞以减少其他问题的发生。如果数据仍未交付,则将通知源此失败。一旦 TCP 接收器重新组合了最初传输的八位字节序列,它就会将它们传递给接收应用程序。因此,TCP 从底层网络细节中抽象出应用程序的通信。

读到这里,我明白下载文件可能损坏的唯一原因是 (1) 下载后出现问题或 (2) 连接中断。

我错过了什么吗?为什么提供 Linux 映像的站点通常也提供 MD5 哈希?通过 HTTPS(因此也通过 TCP)上传/下载文件的完整性是否得到保证?

最小文件上传示例

HTML:

<!DOCTYPE html>
<html>
<head><title>Upload a file</title></head>
<body>
<form method="post" enctype="multipart/form-data">
    <input name="file" type="file" />
    <input type="submit"/>
</form>
</body>
</html>

Python/Flask:

"""
Prerequesites:

  $ pip install flask
  $ mkdir uploads
"""

import os
from flask import Flask, flash, request, redirect, url_for
from werkzeug.utils import secure_filename


app = Flask(__name__)
app.config["UPLOAD_FOLDER"] = "uploads"


@app.route("/", methods=["GET", "POST"])
def upload_file():
    if request.method == "POST":
        # check if the post request has the file part
        if "file" not in request.files:
            flash("No file part")
            return redirect(request.url)
        file = request.files["file"]
        # if user does not select file, browser also
        # submit an empty part without filename
        if file.filename == "":
            flash("No selected file")
            return redirect(request.url)
        filename = secure_filename(file.filename)
        file.save(os.path.join(app.config["UPLOAD_FOLDER"], filename))
        return redirect(url_for("upload_file", filename=filename))
    else:
        return """<!DOCTYPE html>
<html>
<head><title>Upload a file</title></head>
<body>
<form method="post" enctype="multipart/form-data">
    <input name="file" type="file" />
    <input type="submit"/>
</form>
</body>
</html>"""
    return "upload handled"


if __name__ == "__main__":
    app.run()

【问题讨论】:

    标签: tcp protocols integrity


    【解决方案1】:

    TCP/HTTPS是否保证文件上传/下载的完整性?

    简而言之:不。但使用 HTTPS 比使用普通 TCP 更好。

    TCP 只有非常弱的错误检测,因此它可能会检测到简单的位翻转并丢弃(并重新发送)损坏的数据包 - 但它不会检测到更复杂的错误。虽然 HTTPS(通过 TLS 层)具有非常可靠的完整性保护,但传输过程中未检测到的数据损坏基本上是不可能的。

    TCP 还具有强大的检测和防止重复和重新排序功能。 TLS(在 HTTPS 中)对此类数据损坏的检测更加可靠。

    但是当 TCP 连接简单地提前关闭时,例如服务器崩溃时,它会变得模糊不清。 TCP 本身没有消息指示,因此连接关闭通常用作消息结束指示符。例如,这对于 FTP 数据连接是正确的,但对于 HTTP(因此是 HTTPS)也可能是正确的。虽然 HTTP 通常有一个长度指示符(Content-length 标头或带有Transfer-Encoding: chunked 的显式块大小),但它还将 TCP 连接的结束定义为消息的结束。如果在声明的消息结束之前到达连接结束,客户端的行为会有所不同:一些将数据视为损坏,另一些将假定服务器损坏(即错误的长度声明)并将连接关闭视为有效的消息结束。

    理论上,TLS(在 HTTPS 中)有一个明确的 TLS 结束消息(TLS 关闭),这可能有助于检测早期连接关闭。在实践中,虽然实现可能只是简单地关闭底层套接字而没有这种显式的 TLS 关闭,因此不幸的是不能完全依赖它。

    为什么提供 Linux 映像的网站通常也提供 MD5 哈希?

    还有另一个失败点:下载可能在下载之前就已损坏。下载站点通常有多个镜像,当将文件发送到下载镜像时,甚至将文件发送到下载主机时,可能会发生损坏。与下载并行有一些强校验和有助于检测此类错误,只要校验和是在下载源处创建的,因此是在数据损坏之前创建的。

    【讨论】:

    • 谢谢!作为一个允许上传文件的开发者,我能做些什么来改善非技术用户的情况,“保证”上传文件的完整性?
    • 如果您能指出这些陈述的来源,那将是非常惊人的。特别是:TCP / HTTPS(嗯.. TLS,我猜?)如何检查完整性?我猜 TCP 可能是简单的 XOR 和 TLS 可能是像 sha256 这样的加密哈希?
    • @MartinThoma:TCP 是一个简单的 16 位校验和。有关更多信息,请参阅Can a TCP checksum fail to detect an error? If yes, how is this dealt with?。至于 TLS,请参阅标准,但它使用 HMAC 和类似方法(取决于使用的实际密码)具有非常强大的完整性保护。
    • @MartinThoma:“作为允许上传文件的开发者” - 确保上传文件与之前声明的大小(即Content-length)匹配以检测损坏(短) 上传 - 也许框架已经为你做了这个,也许不是。使用 TLS 进行完整性保护。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多