Cân nhắc của Tiêu đề nội dung HTTP-MD5


12

Chúng tôi đang tranh luận về việc có nên sử dụng tiêu đề Content-MD5 hay không.

Ưu điểm:

  • CMS cho phép chúng tôi dễ dàng bao gồm nó với chi phí tối thiểu (phản hồi được lưu trong bộ nhớ cache trong 80% + các trường hợp).
  • Nó sẽ thêm một lớp bảo vệ chống lại các vấn đề.

Nhược điểm:

  • Tiêu đề Độ dài Nội dung luôn có mặt (ngay cả trên các trang được tạo động), do đó, máy khách không cần một hình thức xác thực khác.
  • Cho đến nay chúng tôi không biết về bất kỳ vấn đề gây ra bởi tham nhũng.
  • MD5 kiểm tra thêm độ trễ cho thời gian tải trang web.

Điểm:

  • Có một số loại phương tiện truyền thông bao gồm hình thức tiêu hóa riêng của họ làm cho điều này không cần thiết?
  • Nếu TCP đã cung cấp điều này thì tại sao nó lại được bao gồm trong tiêu chuẩn HTTP?
  • Sử dụng thực tế hiện có là gì?
  • Kiểm tra MD5 không đáng kể?

Không có vấn đề thực sự nào về việc này được thêm vào các bài kiểm tra đơn vị và được thực hiện, khoảng một giờ làm việc; tuy nhiên nếu nó gây bất lợi thì chúng tôi muốn nó được thêm vào các bài kiểm tra đánh hơi ở cấp độ cao hơn được sử dụng trong trang web "kiểm tra sức khỏe".

Câu trả lời:


10

TCP đã sửa lỗi, nhưng điều này chỉ giúp bạn trên lớp TCP. Một proxy HTTP trung gian hoặc bộ cân bằng tải có thể làm hỏng dữ liệu trên lớp HTTP và sau đó truyền lại nó. Một MD5 HTTP cho phép phát hiện tham nhũng này. Lý do tại sao không ai thực sự nói về nhu cầu này là vấn đề thực sự rất hiếm; hầu hết các proxy HTTP, vv "chỉ hoạt động".

Các RFC ám chỉ bảo mật. IMHO yếu đến mức không nên bỏ qua - nếu bạn cần bất kỳ loại bảo mật và bảo mật thực sự nào, thì bạn cần HTTPS.

Có một số loại phương tiện truyền thông bao gồm hình thức tiêu hóa riêng của họ làm cho điều này không cần thiết?

Không phải bất cứ điều gì thực sự tốt. Nhưng một vài lỗi trong ảnh, phát video trực tuyến, v.v ... thường sẽ không thể chấp nhận được đối với con người.

Tôi muốn nói rằng nó phụ thuộc vào trường hợp sử dụng:

  • Đối với các dịch vụ web dựa trên REST, một bản tóm tắt sẽ thêm một lớp hữu ích để sửa lỗi bổ sung. Xem thất bại AWS này là một ví dụ .
  • Đối với các ứng dụng xử lý dữ liệu quan trọng trên HTTP đơn giản, nó đáng để thực hiện. Content-MD5 cung cấp cho khách hàng tùy chọn để xác minh tính toàn vẹn truyền từ đầu đến cuối.
  • Đối với các trang web 'bình thường' phục vụ văn bản và phương tiện có giá trị 'bình thường', tiêu đề Content-MD5 không phục vụ mục đích. Và tôi thực sự thậm chí không biết có bao nhiêu trình duyệt chính (PC, đặc biệt là di động) thực sự hỗ trợ nó.

1
Đó là trường hợp thất bại AWS thực sự ngấm ngầm. Nó mới vài tuổi, nhưng thực sự là một ví dụ hấp dẫn về chế độ thất bại mà tôi sẽ không bao giờ nghĩ tới. Một điều rất thú vị cần chú ý khi sử dụng lưu trữ dữ liệu từ xa. Tôi tự hỏi về một số giải pháp NoQuery và cách chúng xử lý các vấn đề như vậy.
artlung

Điều này làm cho nó khá dễ dàng để đưa ra quyết định cho khách hàng. Một tùy chọn như thế này bây giờ có thể được cung cấp dưới dạng "tốt để có" nhưng không phải là một tiêu chí thiết yếu. Nếu Amazon có thể triển khai một bộ cân bằng tải và gây ra các lỗi này, thì cuối cùng có khả năng nó sẽ mọc lên ở đâu đó và không có gì tệ hơn một trang web rắc rối không nhất quán.
Metalshark

Điều đó thực sự phụ thuộc vào nơi bit lật. Nếu đó là bit có ý nghĩa nhỏ nhất, thì nó sẽ không thể nhận ra được. Nhưng có một sự khác biệt rất lớn giữa màu sắc rgb(255, 0, 0)rgb(127, 0, 0). Với video thô, lỗi pixel đơn lẻ sẽ ít được nhận biết hơn vì nó xuất hiện trên màn hình trong một thời gian ngắn, nhưng vì hầu hết video trực tuyến sử dụng thuật toán nén hiệu quả cao, một bit bị lật có thể khiến một nửa hình ảnh bị hỏng hoặc bị dịch chuyển màn.
Lèse majesté

Ngoài ra, như bạn đã nói, các ngân hàng chỉ nên sử dụng HTTPS, vì vậy không có lý do gì để họ sử dụng Content-MD5cả, vì SSL / TLS đã cung cấp thông báo thông báo ở lớp ứng dụng?
Lèse majesté

1
@ Lèse majesté: Liên quan đến lỗi bit, tôi đồng ý trong trường hợp trừu tượng. Nhưng hãy nhớ rằng hầu hết video phát trực tuyến fx sử dụng truyền tải dành riêng cho ứng dụng qua UDP hoặc TCP để đưa ra sự đánh đổi 'đúng' giữa sửa lỗi và tốc độ - và do đó truyền phát video sẽ không phải là trường hợp sử dụng cho Content-MD5. Về các ngân hàng nên sử dụng HTTPS, tôi đồng ý và tôi đang chia sẻ lại để làm cho nó rõ ràng hơn.
Jesper M

1

MD5 kiểm tra thêm độ trễ cho thời gian tải trang web.

Nếu đúng (và độ trễ không hoàn toàn tầm thường) thì tôi sẽ nói nó không đáng.

Nói chung, tôi tin rằng, tiêu đề sửa đổi cuối cùng được sử dụng phổ biến nhất để xác định xem một trang có thay đổi hay không. Giả sử bạn cung cấp giá trị có ý nghĩa ở đó, tôi thấy không cần tiêu đề nội dung-md5.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.