Khai thác tính năng nhúng video của Slack để tạo liên lạc mã hóa đầu cuối (E2EE)

15 tháng 6, 2026·4 phút đọc

Một nhà phát triển đã sáng tạo biến khối video (video block) của Slack thành môi trường thực thi mã hóa, cho phép người dùng gửi tin nhắn E2EE ngay trên nền tảng này mà máy chủ không bao giờ nắm giữ khóa giải mã.

Khai thác tính năng nhúng video của Slack để tạo liên lạc mã hóa đầu cuối (E2EE)

Khai thác tính năng nhúng video của Slack để tạo liên lạc mã hóa đầu cuối (E2EE)

Trong quá trình nghiên cứu tài liệu Block Kit của Slack, một nhà phát triển đã phát hiện ra một điểm thú vị: khối video (video block). Khi nhận thấy rằng khối này chấp nhận một video_url, câu hỏi đầu tiên xuất hiện trong đầu ông là: Slack phân biệt nội dung như thế nào và liệu có yêu cầu hay giới hạn đặc biệt nào đối với việc nhúng không?

Câu trả lời là không. Không có kiểm tra thời gian chạy (runtime check) nào ngoài việc đảm bảo URL cung cấp phản hồi mã 2xx hoặc 3xx. Sau các bước kiểm tra đó, khối video này thực chất không gì khác hơn một iframe đơn giản.

Quy trình gửi tin nhắn mã hóa trên SlackQuy trình gửi tin nhắn mã hóa trên Slack

Ý tưởng cốt lõi của dự án này là tạo ra một ứng dụng cho phép mã hóa tin nhắn bằng cặp khóa và gửi chúng qua Slack. Về mặt lý thuyết, ứng dụng sẽ hoạt động như sau: Trong máy khách của bạn, sử dụng API mã hóa của trình duyệt, bạn tạo một cặp khóa, mã hóa khóa riêng tư và gửi nó lên máy chủ. Khi cần thực hiện thao tác (ký, mã hóa, giải mã), máy chủ sẽ gửi lại khóa cho bạn. Bên trong khối video, bạn sẽ giải mã khóa của mình và thực hiện thao tác đó.

Cách tiếp cận này đảm bảo máy chủ không bao giờ nhận được khóa đã giải mã, nhưng thông qua các cặp khóa, bạn vẫn có thể mã hóa tin nhắn cho bất kỳ ai.

Chi tiết triển khai

Để phát triển ứng dụng này, tác giả đã chọn TypeScript vì sự quen thuộc và khả năng lặp lại nhanh chóng. Trong quá trình xây dựng ứng dụng Slack, một khó khăn bất ngờ phát sinh là các khối video không thể được đưa vào các tin nhắn tạm thời (ephemeral messages) — một hành vi không được ghi nhận trong tài liệu chính thức của Slack.

Về phần mã hóa, ban đầu tác giả cố gắng viết toàn bộ logic mã hóa thủ công bằng cách sử dụng SubtleCrypto API của trình duyệt (hoàn toàn khả dụng trong khối video của Slack). Tuy nhiên, độ phức tạp của các kỹ thuật mã hóa nhanh chóng khiến ông thay đổi quyết định.

May mắn thay, tác giả đã tìm thấy openpgp.js, một thư viện tuyệt vời được duy trì bởi Proton (nhà cung cấp dịch vụ email bảo mật nổi tiếng), giúp xử lý tất cả các thao tác mật mã học cần thiết.

Mục tiêu là để máy chủ lưu trữ càng ít dữ liệu càng tốt, ưu tiên lưu trữ trong các trường metadata của Slack. Tuy nhiên, do độ dài của các tin nhắn mã hóa, tính năng này không thể sử dụng được. Thay vào đó, một hệ thống slug đã được sử dụng. Trong mỗi cuộc gọi cần tương tác từ máy khách, một slug duy nhất chứa dữ liệu cần thiết sẽ được lưu trữ trong cơ sở dữ liệu KV.

Khi khối video được tải, thông tin này được nhúng cùng với mã máy khách để tất cả các thao tác mật mã có thể được thực hiện cục bộ.

Quy trình mã hóa tin nhắn

Quy trình để mã hóa một tin nhắn diễn ra khá đơn giản:

Đầu tiên, người dùng thực hiện lệnh /e2ee send. Một modal của Slack sẽ mở ra, yêu cầu người dùng chọn người nhận.

Sau khi modal được gửi đi, một slug sẽ được tạo ra, chứa: khóa riêng tư của tác giả và khóa công khai của người nhận.

Khi nhấp vào khối video bên trong Slack, máy khách cục bộ sẽ được tải cùng với thông tin trên.

Tác giả giải mã khóa riêng tư của mình thông qua cụm mật khẩu (thực hiện cục bộ).

Tác giả viết tin nhắn, mã hóa nó cho người nhận và ký bằng khóa của mình (thực hiện cục bộ).

Tác giả chỉ gửi tin nhắn đã mã hóa. Máy chủ sẽ gửi các "bao thư" (envelopes) đến từng người nhận của tin nhắn.

Kết luận và suy ngẫm

Bạn có thể xem xét dự án này ngay bây giờ, mã nguồn có sẵn tại GitHub và có thể tự triển khai cho không gian làm việc Slack của bạn trong khoảng 5 phút.

Dự án này về cơ bản là một "hack" sáng tạo vì nó không tuân thủ hoàn toàn các ràng buộc thiết kế của Slack. Tuy nhiên, nó đặt ra một câu hỏi thú vị: Với tất cả sự linh hoạt mà công nghệ web mang lại, liệu các dịch vụ lớn có nên hỗ trợ các ứng dụng đầy đủ tính năng ngay trong máy khách của họ không?

Discord đã làm điều gì đó tương tự với "Activities", hay Telegram với "Mini Apps". Sẽ rất thú vị nếu thấy nhiều dịch vụ chính thống hơn áp dụng cách tiếp cận này trong tương lai.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗