- jabber.ru và xmpp.ru đã bị tấn công MitM do kết hợp giữa việc chặn bắt lưu lượng trên tuyến của nhà cung cấp hosting và việc cấp trái phép chứng chỉ Domain Validation, qua đó phơi bày khoảng trống phòng vệ của các dịch vụ TLS không phải web
- Giám sát nhật ký Certificate Transparency và thăm dò khóa công khai TLS có thể giúp phát hiện dấu hiệu bất thường, nhưng rất khó phát hiện đầy đủ khi đối mặt với chứng chỉ không được ghi vào CT và các cuộc MitM có chọn lọc
- Triển khai ACME-CAA (RFC 8657) cùng với DNSSEC có thể cho phép chỉ một tài khoản cụ thể của một CA cụ thể được cấp chứng chỉ, khiến kẻ tấn công không thể chỉ dùng cùng CA là đủ
- Không giống trình duyệt web, nhiều client không phải web không bắt buộc bằng chứng CT (SCT), và CA/Browser Forum Baseline Requirements cũng không yêu cầu ghi CT với mọi chứng chỉ
- Nhà vận hành nên cân nhắc ACME-CAA, DNSSEC, giám sát CT, Tor onion service và phân tán theo thẩm quyền tài phán; người dùng nên xem mã hóa đầu cuối và xác minh dấu vân tay là tuyến phòng thủ cơ bản
Cấu trúc cốt lõi của sự cố
- Nhà vận hành jabber.ru và xmpp.ru cho biết dịch vụ đã bị tấn công man-in-the-middle
- Cuộc tấn công là sự kết hợp của hai yếu tố
- Hetzner và Linode chặn bắt lưu lượng đi tới máy dịch vụ
- Kẻ tấn công đã được cấp trái phép chứng chỉ Domain Validation cho dịch vụ đó
- Đánh giá cho rằng nhiều khả năng có sự điều phối của nhà nước Đức, hoặc Đức phối hợp với một hay nhiều quốc gia khác
- Vẫn còn các khả năng khác
- Hetzner và Linode có thể đã tự nguyện đáp ứng yêu cầu nghe lén của một thế lực nước ngoài mà không bị cưỡng ép pháp lý
- Tuy nhiên, trường hợp này sẽ dẫn tới đánh giá rất tiêu cực đối với hai công ty và có thể là bất hợp pháp, nên được xem là ít khả năng hơn
Phương pháp phát hiện và giới hạn
- Cách thứ nhất là giám sát nhật ký Certificate Transparency (CT) để tìm các chứng chỉ được cấp mà nhà vận hành không yêu cầu
- Có một số dịch vụ thực hiện việc này thay người dùng
- Các công cụ có khả năng lọc tốt và chỉ cảnh báo về chứng chỉ không được yêu cầu vẫn còn nhiều dư địa để cải thiện
- Cách thứ hai là kết nối định kỳ tới dịch vụ để kiểm tra xem khóa công khai của máy chủ TLS có khớp với giá trị mong đợi hay không
-
Những gì giám sát CT có thể bỏ sót
- Ngay cả chứng chỉ do CA hợp pháp cấp cũng không nhất thiết phải được ghi vào nhật ký CT
- CA/Browser Forum Baseline Requirements hiện vẫn chưa coi việc ghi CT là yêu cầu bắt buộc với CA
- Trình duyệt web từ chối các chứng chỉ không có bằng chứng mật mã cho thấy đã được ghi vào CT, nên việc ghi CT trên thực tế bị ép buộc
- Phần lớn ứng dụng client không phải web không kiểm tra hoặc yêu cầu bằng chứng rằng chứng chỉ đã được ghi vào CT
- Về mặt lý thuyết, kẻ tấn công có thể lấy được chứng chỉ không ghi vào CT
-
Khả năng né tránh bằng MitM có chọn lọc
- Ngay cả khi cố phát hiện MitM bằng cách thăm dò dịch vụ, kẻ tấn công vẫn có thể nhận diện các kết nối thăm dò và không áp dụng MitM cho các kết nối đó
- Tối thiểu nên thực hiện probe qua Tor để tránh các tình huống dễ bị nhận diện
- Stack TLS có thể bị lấy dấu vân tay qua các tín hiệu như thứ tự liệt kê TLV, nên có khả năng phân biệt giữa client XMPP thực và tác nhân thăm dò
- Thay vì loại trừ các probe đã biết bằng blacklist, kẻ tấn công cũng có thể chỉ whitelist lưu lượng của một số người cụ thể cần theo dõi để áp dụng MitM
- Cả hai phương pháp phát hiện đều không mang lại độ tin cậy tuyệt đối
Rủi ro có thể giảm bằng ACME-CAA
- Chứng chỉ TLS được tạo ra để ngăn chặn tấn công MitM, nhưng chính mô hình Domain Validation mà CA dùng để xác minh quyền kiểm soát miền lại dễ bị MitM
- Nếu kẻ tấn công có thể chặn bắt toàn bộ lưu lượng, thay vì chỉ một phần, đi tới website nạn nhân thì rủi ro tăng lên
- ACME-CAA(RFC 8657) có thể giảm nhẹ vấn đề này trong một số tình huống nhất định
- Ý tưởng cốt lõi là dùng bản ghi DNS để chỉ định rằng chỉ một tài khoản cụ thể của một CA cụ thể mới được phép cấp chứng chỉ cho miền
- Chỉ dùng cùng một CA là chưa đủ
- Cần có quyền truy cập vào đúng tài khoản tại CA đó
- Với Let's Encrypt, điều này đòi hỏi quyền truy cập vào khóa riêng ACME dùng để yêu cầu chứng chỉ
- Dựa trên phương thức tấn công đã biết, bài viết đánh giá rằng nếu triển khai phần mở rộng này thì có thể đã ngăn được cuộc tấn công
-
Các điểm cần chú ý khi triển khai
- Để ACME-CAA hoạt động đúng, cần triển khai DNSSEC
- Nếu không có DNSSEC, truy vấn DNS của CA cũng có thể bị chặn bắt
- Người nắm được khóa ký DNSSEC có thể vượt qua rào cản này
- Một vùng DNS được bảo vệ bằng DNSSEC có thể được vận hành mà không phải giao khóa ký cho bên thứ ba
- Trong trường hợp đó, nhà cung cấp DNS hosting sẽ không có quyền làm tổn hại vùng DNS
- Cách này được đánh giá là chiến lược triển khai tốt nhất
- Kẻ tấn công có thể gây áp lực lên nhà đăng ký miền hoặc TLD registry để thay đổi khóa ký DNSSEC đã đăng ký cho miền
- Việc đó có khả năng bị chú ý
- Do đặc tính cache DNS, có thể khó ngăn việc các probe lặp lại không phát hiện ra thay đổi khóa
- Kẻ tấn công cũng có thể gây áp lực trực tiếp lên chính CA để buộc cấp sai chứng chỉ
- Nếu CA bên thứ ba vi phạm quy tắc hoặc mắc lỗi thì vẫn còn lỗ hổng
- CA/Browser Forum Baseline Requirements yêu cầu CA phải kiểm tra DNSSEC
- Tuy nhiên, CA bên thứ ba vẫn có thể cấp chứng chỉ dù không được cho phép trong bản ghi CAA
- Vì ghi CT không bắt buộc, các chứng chỉ đó có thể không bị phát hiện
Luồng tấn công mà đối thủ tinh vi hơn có thể chọn
- Kẻ tấn công trong sự cố lần này không phải hoàn hảo vì đã để chứng chỉ bất hợp pháp hết hạn
- Khi mã hóa giá rẻ và dễ triển khai trở nên phổ biến hơn, các cuộc tấn công ở cấp độ quốc gia được dự đoán sẽ tinh vi hơn và xảy ra thường xuyên hơn
- Một tác nhân cấp quốc gia thành thạo hơn có thể chọn luồng sau
- Lợi dụng việc CA không bị bắt buộc phải ghi vào CT để yêu cầu chứng chỉ không được ghi log
- Gây áp lực lên nhà cung cấp hosting để MitM toàn bộ lưu lượng đi tới máy nạn nhân
- Dùng dấu vân tay stack TLS và IP nguồn để phân biệt theo heuristic giữa lưu lượng quan tâm và lưu lượng dùng để phát hiện
- Dùng MitM để khiến CA tin rằng kẻ tấn công là bên kiểm soát hợp pháp miền của nạn nhân
- Nếu miền dùng ACME-CAA và DNSSEC, chúng có thể tìm cách gây áp lực lên nhà cung cấp DNS hosting, nhà đăng ký, TLD registry và CA
Những lỗ hổng trong hạ tầng TLS hiện nay
-
Thiếu bắt buộc CT ở client TLS không phải web
- Trình duyệt web yêu cầu chứng chỉ CA phải kèm bằng chứng mật mã cho thấy đã được ghi vào nhật ký CT
- Phần lớn các client TLS khác không bắt buộc bằng chứng CT, nên có thể chấp nhận các chứng chỉ không được ghi log
- Nhiều client XMPP có thể cũng thuộc nhóm này
- Xác minh CT không phải là tính năng tự động bật chỉ vì liên kết với OpenSSL, mà cần triển khai riêng
- Phần mềm dùng cho liên lạc nhạy cảm nên xem xét hỗ trợ bắt buộc CT
-
Không có nghĩa vụ ghi CT cho chứng chỉ
- CA/Browser Forum Baseline Requirements, tức bộ quy tắc công nghiệp mà CA phải tuân theo, không yêu cầu chứng chỉ phải được ghi vào nhật ký CT
- Theo bài viết, cần có hướng đi yêu cầu mọi chứng chỉ đều phải được ghi vào CT
- Khi việc ép buộc CT được triển khai rộng rãi, vấn đề này có thể trở nên không còn ý nghĩa về mặt kỹ thuật
-
Thiếu dịch vụ giám sát CT
- Cần có thêm nhiều dịch vụ giám sát CT
- Hiện tại, một dịch vụ cảnh báo CT nổi bật là SSLMate's Cert Spotter
- Mức giá có thể là gánh nặng đối với các dịch vụ vận hành dựa trên tình nguyện
- Giám sát CT nên được thiết kế để giảm false positive và chỉ cảnh báo về các chứng chỉ có vẻ bất thường hoặc không được phép
-
Thiếu tính minh bạch của DNSSEC
- Hiện chưa có hạ tầng mật mã được triển khai rộng để phát hiện thay đổi khóa DNSSEC đang được cấu hình cho một miền
- Nếu nhà đăng ký miền hoặc TLD registry bị gây áp lực hay bị xâm nhập để thay đổi khóa DNSSEC của miền, lớp bảo vệ ACME-CAA có thể suy yếu
- Một giải pháp minh bạch để công khai thay đổi khóa DNSSEC zone là điều đáng mong muốn
- Giải pháp này không cần ghi lại toàn bộ bản ghi của zone, mà chỉ cần ghi các thay đổi khóa zone như bản ghi DS
Khuyến nghị cho nhà vận hành dịch vụ
- Với các dịch vụ có thể là mục tiêu của tấn công cấp quốc gia, nên áp dụng các biện pháp phòng thủ theo thứ tự ưu tiên về hiệu quả trên chi phí
-
ACME-CAA và DNSSEC
- Triển khai ACME-CAA có thể khiến kẻ tấn công khó lừa CA cấp chứng chỉ cho miền hơn
- Có thể tham khảo hướng dẫn triển khai trong bài viết về ACME-CAA
- Security Considerations của RFC cũng chứa các lưu ý quan trọng
- Nếu triển khai ACME-CAA thì cũng phải triển khai DNSSEC
- Nếu có thể, nên chọn nhà cung cấp DNSSEC không yêu cầu giao khóa ký cho nhà cung cấp
-
Dịch vụ proxy và giám sát CT
- Bài viết đánh giá rằng dùng các dịch vụ như Cloudflare tương tự như tự đặt mình vào trạng thái đã bị MitM sẵn
- Nên đăng ký dịch vụ giám sát nhật ký CT hoặc tự kiểm tra log định kỳ
- SSLMate's Cert Spotter cung cấp giám sát tự động có phí
- Vì Cert Spotter là mã nguồn mở, cũng có thể tự host
- crt.sh cung cấp tìm kiếm thủ công trong nhật ký CT
-
Phân tán theo thẩm quyền tài phán và Tor onion service
- Có thể cân nhắc phân tán theo thẩm quyền tài phán bằng cách đặt nhà đăng ký miền, TLD registry, DNS hosting, CA và nhà cung cấp hosting ở các quốc gia khác nhau
- Có thể lựa chọn dựa trên các quốc gia hoặc khối địa chính trị ít có khả năng hợp tác với nhau
- Cung cấp Tor onion service giúp bỏ qua các hạ tầng tập trung như TLS và CA
- Trong Tor onion service, khóa công khai của dịch vụ chính là địa chỉ
- Người dùng phải nhận đúng địa chỉ onion qua một kênh đáng tin cậy
- Bên thứ ba có thể điều hướng người dùng tới địa chỉ onion giả
-
Tự động thăm dò qua Tor
- Tự động probing qua Tor không phải lời giải hoàn hảo, nhưng có thể bắt được các sai sót vụng về thường gặp trong thực tế
- Dùng Tor giúp giảm khả năng bị nhận diện dễ dàng là probe
- Để giảm khả năng bị lấy dấu vân tay TLS, tốt hơn nên dùng thư viện TLS phổ biến trong phần mềm client
- Nếu có thể, dùng chính client thực sẽ tốt hơn
- Với dịch vụ XMPP, có thể dùng client XMPP thực
- Dù thành công, cách này vẫn chỉ là phát hiện sau khi đã bị xâm nhập, và đến lúc đó người dùng có thể đã bị ảnh hưởng
-
Các vector tấn công khác và giả định tình huống xấu nhất
- Khi MitM trở nên khó hơn, kẻ tấn công sẽ có xu hướng dùng các con đường khác như xâm nhập chính máy, đánh cắp khóa riêng hoặc lấy cắp dữ liệu nhạy cảm
- Tác nhân cấp quốc gia có thể gây áp lực lên nhà cung cấp VM để thực hiện memory dump ở cấp hypervisor
- Ngay cả máy chủ chuyên dụng cũng có thể bị xâm nhập nếu đối thủ có tiếp cận vật lý
- Nhà vận hành nên khuyến khích người dùng dùng mã hóa đầu cuối, và phải giả định dịch vụ có thể đã bị xâm nhập dù đã nỗ lực tối đa
- Bài viết đánh giá rằng mã hóa “đầu cuối” được phân phối qua ứng dụng web không mang lại sự bảo vệ có ý nghĩa
Các hành động cần thiết với CA, nhà phát triển client và người dùng
-
CA/Browser Forum
- Cần yêu cầu mọi chứng chỉ đều được ghi vào nhật ký CT, hoặc đưa ra đề xuất theo hướng đó
-
Nhà phát triển ứng dụng client
- Cần thêm tính năng bắt buộc chứng chỉ TLS phải có Signed Certificate Timestamps (SCTs) và bật mặc định
- Cần để người dùng biết rằng họ đang được hưởng lớp bảo vệ này
- Việc bắt buộc bằng chứng CT có một số biến động, nên cũng cần cân nhắc các thảo luận liên quan
- Phần mềm nên được phát hành dưới dạng mã nguồn mở để có thể kiểm toán công khai
- Cũng cần cân nhắc rủi ro chuỗi cung ứng và khả năng chính nhà phát triển bị ép buộc pháp lý để làm suy yếu phần mềm
- Các kênh phân phối mà nhà phát triển không trực tiếp kiểm soát, như kho gói của bản phân phối Linux, có thể giúp giảm thiệt hại
-
Người dùng cuối
- Ngay cả khi nhà vận hành dịch vụ có thiện chí, vẫn phải giả định dịch vụ có thể bị xâm nhập dù đã nỗ lực tối đa
- Nếu tính mạng phụ thuộc vào việc dịch vụ không bị xâm nhập, thì không nên tin tưởng dịch vụ đó
- Trong XMPP, nên dùng các công nghệ mã hóa đầu cuối như OMEMO hoặc OTR
- Luôn phải xác minh dấu vân tay của đối tác liên lạc
- Không nên thực hiện mã hóa đầu cuối bằng phần mềm nền web, hoặc ít nhất phải giả định rằng nó đã bị xâm nhập
- Nếu nhà cung cấp dịch vụ có cung cấp Tor onion service thì nên cân nhắc sử dụng, nhưng địa chỉ onion phải lấy từ nguồn đáng tin cậy
-
CA và những người viết tiêu chuẩn
- Nếu CA chưa hỗ trợ ACME-CAA(RFC 8657), nên cân nhắc triển khai
- Ngay cả CA không dựa trên ACME cũng có thể triển khai ACME-CAA
- Dù quy tắc của CA/Browser Forum cho phép không ghi CT, CA vẫn có thể tự áp dụng chính sách ghi mọi chứng chỉ vào CT
- Những người viết tiêu chuẩn có thể xem xét lại khả năng minh bạch DNSSEC, ít nhất là với bản ghi DS
Đánh giá về confidential computing
- Nếu lo ngại tới mức cả việc nhà cung cấp hosting xâm nhập máy cũng là mối đe dọa, thì công nghệ confidential computing hiện nay không được xem là lời giải đủ tốt
- Việc triển khai có thể vẫn tốt hơn là không làm gì, nhưng không nên tin rằng như vậy là an toàn
- Bài viết cho rằng các công nghệ hiện tại, bao gồm của AMD và Intel, phụ thuộc vào các vendor golden key có thể dùng để cài cửa hậu hệ thống
- Tác nhân cấp quốc gia có thể gây áp lực lên nhà cung cấp để giao nộp khóa, và khi đó mô hình này sẽ sụp đổ
- Có thể tồn tại các phương thức confidential computing không phụ thuộc vào golden key, nhưng cách làm hiện tại chưa đạt tới tiêu chuẩn đó
Tài liệu liên quan
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: Khuyến nghị giảm thiểu dành riêng cho XMPP
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: Báo cáo sự cố gốc
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 bình luận
Ý kiến trên Hacker News
Phần tóm tắt cuộc tấn công tại https://notes.valdikss.org.ru/jabber.ru-mitm/ khá thú vị
Kẻ tấn công đã phát hành nhiều chứng chỉ SSL/TLS cho jabber.ru và xmpp.ru bằng Let’s Encrypt từ ngày 18/4/2023, và từ ngày 21/7 đến 19/10, đã xác nhận rằng ít nhất 100% lưu lượng client trên cổng XMPP STARTTLS 5222 bị áp dụng tấn công trung gian
Sau đó, khi không thể phát hành lại chứng chỉ, cổng 5222 của jabber.ru đã trả về chứng chỉ hết hạn; cuộc tấn công dừng lại ngay sau khi việc điều tra và liên hệ với Hetzner/Linode bắt đầu, nhưng trên một số máy chủ Linode vẫn còn nghe lén thụ động thông qua các hop định tuyến bổ sung
Có vẻ bản thân máy chủ không bị hack, mà mạng của Hetzner và Linode dường như đã bị cấu hình lại để nhắm vào IP dịch vụ XMPP
Cả trang đó lẫn các trang được liên kết tại đây đều không nhắc đến certificate pinning; không rõ có phải vì XMPP không hỗ trợ hay không, nhưng nếu hỗ trợ thì có lẽ đã có thể ngăn kiểu tấn công này
Đáng tiếc là jabber.ru đang dùng phần mềm máy chủ từ năm 2016, nên phiên bản cũ đó không hỗ trợ
Ngày nay certificate pinning gặp nhiều vấn đề vì chứng chỉ có thời hạn ngắn và được gia hạn thường xuyên. Nếu mỗi tháng đều hỏi người dùng có cho phép chứng chỉ mới không, họ cũng sẽ bấm “Accept” với chứng chỉ của kẻ tấn công mà không nghĩ nhiều
Channel binding hoạt động độc lập với chứng chỉ và đảm bảo luồng TLS được kết thúc tại đúng chủ thể mong đợi
Việc tập trung vào việc client XMPP thiếu hỗ trợ CT/SCT khá khó hiểu. Cuộc tấn công này dùng chứng chỉ hợp lệ do Let’s Encrypt phát hành và cũng đã được đưa lên CT log, nên CT/SCT sẽ không phát hiện được
Nếu có bản ghi CAA nghiêm ngặt thì trong tình huống lý thuyết chứng chỉ được phát hành bởi CA khác, việc kiểm tra SCT có thể bắt được; nhưng thực tế là không có CAA, còn channel binding thân thiện với quyền riêng tư hơn và ít phụ thuộc vào bên thứ ba hơn
Tức là họ có thể phản hồi giao thức ACME trên HTTP được host, hoặc có thể ghi bản ghi DNS TXT; điều này trông như nạn nhân đã mất quyền kiểm soát máy chủ xử lý hoặc nameserver rồi
Theo tôi hiểu, certificate pinning chỉ khả thi khi có thể kiểm soát client, bằng cách đưa trực tiếp chứng chỉ được phép vào client để vượt qua toàn bộ hạ tầng khóa công khai web
Trong tình huống các client phổ dụng kết nối vào, không có cách nào biết chứng chỉ nào nên được cho phép, và hạ tầng khóa công khai web được dùng chính cho mục đích đó
Tất nhiên, ngay cả khi cung cấp client riêng, vấn đề chỉ bị đẩy lên một tầng: nơi khách hàng tải client tùy chỉnh có thể bị xâm phạm và một client độc hại có thể được phân phối
Danh sách này thiếu biện pháp phòng vệ hiển nhiên nhất. Cần bật, và nếu có thể thì bắt buộc dùng SCRAM-xxxxx-PLUS làm phương thức xác thực
Ý tưởng của biến thể PLUS đơn giản nhưng hiệu quả. Thay vì chỉ xác minh bằng salt, nó gắn việc xác minh với một kết nối TLS cụ thể, nên xác thực chỉ có hiệu lực trong đúng một kết nối TLS
Điều này cũng được gọi là channel binding
Tôi tò mò người dùng cuối của xmpp.ru và jabber.ru là ai. Có phải họ đang cố bắt lưu lượng giữa quân nhân Nga hoặc gián điệp không? Tôi không thích giám sát hàng loạt, nhưng không hiểu vì sao lại nhắm đúng vào các tên miền Nga
Khả dĩ hơn là kịch bản nhằm bắt carder hoặc người vận hành botnet. Jabber/XMPP vẫn còn khá phổ biến trong giới đó ở phía Nga, và trong các bài như Krebs on Security cũng thường thấy ảnh chụp màn hình hoặc log có nhiều máy chủ như @exploit.in, @jabber.ru
Dù vậy, bất kể ý định là gì, giám sát hàng loạt nói chung vẫn là chuyện đáng ghê tởm
Tôi không biết chính xác tỷ lệ sử dụng phạm tội và không phạm tội trên hai máy chủ đó là bao nhiêu, nhưng cũng như Tor có lẫn cả nội dung rõ ràng bất hợp pháp và cách dùng hợp pháp, ở đây chắc cũng có khá nhiều cuộc trò chuyện hoàn toàn bình thường
Vì thế ngay từ đầu tôi không mấy ủng hộ việc xâm phạm quyền riêng tư để giám sát một tội phạm mạng tùy ý ở một quốc gia ngoài thẩm quyền, nơi việc dẫn độ cũng khó khăn
Tôi hiểu rằng Hetzner có lẽ buộc phải hợp tác nếu không muốn trở thành như Lavabit, nhưng với tư cách là người thường xuyên khuyến nghị họ, nếu Hetzner biết mà vẫn cho phép hoặc hỗ trợ tấn công trung gian thì sẽ khá thất vọng. Ngoài chuyện đó, tôi vẫn xem họ là một trong những công ty hosting tốt nhất
Họ minh bạch, có uptime, độ tin cậy và hỗ trợ tốt hơn phần lớn nhà cung cấp cloud, chi phí cũng không quá cao. Nỗ lực biến thiết kế thân thiện môi trường thành một lựa chọn khôn ngoan cả về kinh tế cũng đáng khen
Trong “giảm thiểu > tái sử dụng > tái chế”, phần giảm thiểu thể hiện ở thiết kế KISS. Ví dụ như mái cao và nghiêng giúp thoát nhiệt tự nhiên[2], chassis máy chủ gần với cấu trúc đỡ tối thiểu và tấm dẫn luồng khí hơn là chassis thực thụ, hay thiết kế mainboard tiêu chuẩn xoay socket 90 độ để làm mát VRM, CPU và bộ nhớ bằng một quạt[3]
“Tái sử dụng” thể hiện ở các phiên đấu giá máy chủ. Họ không vứt phần cứng cũ mà cho thuê theo kiểu đấu giá Hà Lan, tránh cả chi phí mua phần cứng mới lẫn chi phí môi trường do sản xuất mới qua từng thế hệ
Nếu họ có máy chủ chuyên dụng ngoài châu Âu thì tôi còn muốn dùng nhiều hơn
[1]: Bản thân “hợp pháp” cũng khó định nghĩa. Nhà báo của nước này là “đặc vụ nước ngoài” của nước khác, còn “chiến sĩ tự do” của nước này là “khủng bố” của nước khác
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
Bài viết nói “CT là tùy chọn”, nhưng rốt cuộc chẳng phải đây là vấn đề do client XMPP quyết định sao? Khi trình duyệt hiện nay trên thực tế yêu cầu CT, tôi tò mò điều gì ngăn client XMPP yêu cầu CT
Tôi cũng không hiểu họ đang phụ thuộc vào kho tin cậy nào phát hành chứng chỉ không hoạt động trong trình duyệt
Vấn đề là hành vi yêu cầu CT gần như không được bật mặc định trong bất kỳ thư viện TLS nào. Vì vậy lập trình viên client XMPP phải chủ động bật, và hiện tại tôi nghĩ hầu hết hoặc tất cả đều không làm vậy. Tất nhiên điều này có thể thay đổi
Bài này đề xuất dùng OTR trong XMPP, nhưng đáng tiếc là OTRv3 dùng mật mã đã cũ, còn OTRv4 thì chưa được chốt
https://dustri.org/b/time-to-sunset-otr.html
Với câu hỏi “một kẻ tấn công hoàn hảo sẽ làm gì?”, nếu có quyền truy cập vật lý vào máy tính thì có lẽ có cách rút dữ liệu khỏi thiết bị bằng một dạng chặn bắt bus nào đó
Điều đó hợp lý trong thời dial-up và băng rộng tốc độ thấp, độ trễ cao, nhưng hiện nay có nhiều nơi có cáp quang tốc độ cao và độ trễ thấp tới các điểm peering
Càng rời xa trung tâm dữ liệu và cloud, hạ tầng Internet càng nên vận hành theo cách vốn được thiết kế, và càng ít cần đi qua các điểm tập trung tổng hợp vừa là điểm lỗi nghiêm trọng vừa là rủi ro bảo mật lớn như hiện nay
Tôi đã tìm hiểu CAA, nhưng nhà cung cấp DNS hiện tại của tôi không hỗ trợ bản ghi đó. Có lý do gì mà nó phải là một kiểu mới thay vì bản ghi TXT phổ biến hơn không?
Nếu không được thì nên yêu cầu họ hỗ trợ. Bản ghi CAA là loại ngày càng được dùng nhiều, nên một dịch vụ ngày nay không hỗ trợ thì không hay lắm
Tôi không rành các thảo luận thiết kế CAA, nhưng nhiều khả năng nó đã được bàn trên mailing list IETF liên quan
Nhà cung cấp DNS cần hỗ trợ nhiều loại RR khác nhau, và chủ sở hữu tên miền nên bỏ phiếu bằng bản ghi NS
Danh sách các nhà cung cấp DNS hỗ trợ CAA có ở https://github.com/StackExchange/dnscontrol/blob/master/docu...
Đáng thử xem có thể dựng một máy chủ chính ẩn và chỉ dùng nhà cung cấp làm máy chủ phụ hay không. Tôi đã vượt qua hạn chế đó ở Linode theo cách này
Còn thiếu lựa chọn tự vận hành cơ quan chứng thực và chọn chứng chỉ gốc một cách cẩn trọng
Nhà cung cấp có thể truy cập vào host, nên họ có thể kiểm tra hoạt động từ bên ngoài mà người dùng không hề hay biết
Ví dụ, họ phải cài một kernel module có thể sống sót sau khi nâng cấp kernel và tự ẩn mình ở mức rất cao. Bài viết cũng đề cập đến việc phân tích raw memory dump
Đâu là giải pháp kỹ thuật căn bản trước những cuộc tấn công kiểu này từ nhà nước hoặc các tác nhân mạnh tương đương? Liệu có cách nào thỏa mãn giấc mơ hơi lập dị về một phần mềm có thể phân phối tự do, nhưng không ai ngoài tác giả có thể kiểm duyệt, can thiệp hay sửa đổi không?
Liệu một hệ thống P2P được xây dựng đúng cách trên hạ tầng Internet hiện tại đã là câu trả lời đủ tốt, hay chúng ta cần triển khai thêm một mạng mesh toàn cầu băng thông thấp hoạt động qua vô tuyến?
Hy vọng Freenet 2023 sẽ phát triển theo hướng mang lại trải nghiệm lập trình viên không ma sát cho các ứng dụng P2P