Đồng bộ NTP có xác thực vẫn có thể sai giờ vì sao?

Một máy chủ có thể trả lời đúng bằng danh tính đã được xác thực nhưng vẫn cung cấp giờ sai. Ngay cả khi gói tin đồng bộ không bị sửa, độ trễ khác nhau giữa hai chiều truyền cũng có thể làm máy khách ước lượng lệch thời gian.

Vì thế, triển khai Network Time Security (NTS) không kết thúc việc kiểm tra chất lượng đồng bộ Network Time Protocol (NTP). Cần tách ba câu hỏi: ai gửi thông tin, thông tin đó có đáng tin không, và đường truyền ảnh hưởng phép đo ra sao. Đây là bài kiến thức về thiết kế hệ thống, không phải thông báo một lỗ hổng mới.

Stratum mô tả vị trí trong chuỗi đồng bộ

RFC 5905, đặc tả NTPv4 công bố tháng 6/2010, phân máy chủ sơ cấp ở stratum 1 và các tầng thứ cấp ở stratum 2–15. Mỗi tầng tiếp nhận thời gian từ nguồn phía trên. Giá trị 16 biểu thị trạng thái không đồng bộ trong bảng định nghĩa trường stratum.

Con số tầng không thay cho kết quả đo độ chính xác. Đồng hồ, đường mạng và trạng thái đồng bộ vẫn ảnh hưởng tới sai số. Một bảng giám sát chỉ hiển thị “stratum thấp” chưa trả lời đầy đủ máy đang lệch bao nhiêu và nguồn có ổn định không.

Sơ đồ tầng NTP thường đặt đồng hồ tham chiếu ở trên cùng. Cần phân biệt cách gọi đồng hồ tham chiếu với giá trị 0 trong trường stratum của gói tin: theo đặc tả, giá trị gói tin này mang nghĩa chưa xác định hoặc không hợp lệ, không phải một chứng nhận chất lượng cao hơn stratum 1.

NTS bảo vệ cuộc trao đổi như thế nào?

RFC 8915, công bố tháng 9/2020, đưa ra cơ chế mật mã cho chế độ máy khách–máy chủ của NTP. NTS-KE thực hiện xác thực ban đầu và thiết lập khóa qua TLS. Các trường mở rộng trong trao đổi NTP sau đó dùng cơ chế xác thực mật mã để bảo vệ thông tin.

Lợi ích nằm ở khả năng phát hiện những can thiệp vào trao đổi mà giao thức không được bảo vệ có thể không nhận ra. Tuy vậy, một thông điệp nguyên vẹn chỉ chứng minh nó không bị thay đổi theo cách kiểm tra phát hiện được; nó không tự chứng minh đồng hồ của bên gửi đang đúng.

Đó là hai lớp bảo đảm khác nhau. Có thể hình dung một phong bì được niêm phong chắc chắn: dấu niêm phong giúp kiểm tra nguồn gửi và việc mở thư, nhưng nội dung bên trong vẫn cần được đối chiếu. Phép so sánh này chỉ mô tả ranh giới bảo vệ, không phải toàn bộ hoạt động của NTS.

Gói tin còn nguyên nhưng đến không đúng lúc

Mục 8.6 của RFC 8915 mô tả tấn công trì hoãn bất đối xứng. Kẻ nằm trên đường truyền có thể giữ gói ở một chiều lâu hơn chiều còn lại. Do phép ước lượng độ lệch NTP dựa trên giả định độ trễ hai chiều gần đối xứng, kết quả có thể bị dịch đi dù dữ liệu trao đổi không bị sửa.

Mật mã không tự loại bỏ được cơ chế gây sai số này. Bài toán nằm ở thời điểm tới, không chỉ ở nội dung gói. Đây cũng là lý do chất lượng đường truyền cần được xem cùng kết quả xác thực, thay vì coi biểu tượng kết nối an toàn là bằng chứng thời gian chính xác.

Không nên từ đó kết luận NTS vô ích. Nó giải quyết một lớp rủi ro cụ thể. Sai lầm là giao cho một lớp bảo vệ trách nhiệm chứng minh cả những điều nằm ngoài phạm vi của nó.

Bốn nguồn phải thực sự độc lập

RFC 8633, tài liệu thực hành tốt tháng 7/2019, khuyến nghị người vận hành quan tâm đến độ chính xác dùng ít nhất bốn nguồn giờ độc lập, đa dạng. Hai nguồn bất đồng không cung cấp đủ thông tin để tự xác định bên nào đúng; thêm nguồn giúp duy trì khả năng đối chiếu khi một nguồn gặp vấn đề.

Khuyến nghị này đi kèm giả định phần lớn máy chủ trung thực. Bốn tên miền không tự chứng minh có bốn nguồn tham chiếu hoặc bốn đường đi độc lập. Lỗi hệ thống chung vẫn có thể làm nhiều nguồn cùng sai hoặc cùng bất đồng.

Tài liệu cũng cảnh báo việc trộn nguồn áp dụng leap smear với nguồn không áp dụng có thể tạo khác biệt có hệ thống quanh giây nhuận. Đa dạng nguồn vì vậy phải đi cùng hiểu chính sách thời gian của từng nguồn và theo dõi chúng, thay vì chỉ tăng số dòng cấu hình.

Xác thực cần đi cùng kiểm tra chéo

RFC 9523, công bố tháng 2/2024, mô tả Khronos như một cơ chế giám sát đi kèm NTP để giảm rủi ro dịch chuyển thời gian. Nó xử lý lựa chọn và kiểm tra nguồn ở phía máy khách, không yêu cầu thay đổi giao thức gói NTP trên đường truyền.

Đây là tài liệu mang tính thông tin, không phải khẳng định mọi phần mềm NTP đã tích hợp Khronos. Tên một RFC cũng chưa chứng minh bản cài đặt đang dùng có đầy đủ tính năng, được bật đúng hoặc phù hợp với hệ thống cụ thể.

Khi đánh giá hạ tầng đồng bộ, cần nhìn riêng kết quả xác thực, độ lệch quan sát và mức độ độc lập của nguồn. Một hệ thống đáng tin phải giải thích được cả ba. Đồng hồ “đã đồng bộ” là trạng thái vận hành cần được theo dõi, không phải lời bảo đảm vĩnh viễn rằng thời gian luôn đúng.

Nguồn và ảnh

Nguồn: RFC 5905: NTPv4; RFC 8915: NTS; RFC 8633: thực hành NTP; RFC 9523: Khronos.

Ảnh: Benjamin D. Esham / Wikimedia Commons, tác giả hiến tặng phạm vi công cộng, dùng nguyên bản. Sơ đồ minh họa phân tầng NTP, không mô tả riêng luồng NTS hay xếp hạng độ chính xác.