Meta mở dịch vụ thời gian NTS miễn phí tại nts.meta.com

Meta vừa công bố dịch vụ thời gian công khai của hãng đã hỗ trợ NTS (Network Time Security, RFC 8915) tại địa chỉ nts.meta.com. Điểm khác biệt cốt lõi: các gói tin thời gian nay được xác thực, nên thiết bị có thể kiểm tra rằng thời gian thực sự đến từ Meta và không bị chỉnh sửa trên đường truyền.

Minh họa dịch vụ NTS của Meta

Theo Oleg Obleukhov, các máy chủ NTS của Meta không lưu trạng thái cho từng client: khóa dùng để niêm phong cookie được dẫn xuất thay vì lưu trữ hay sao chép sang các máy chủ khác. Toàn bộ mã nguồn — giao thức, máy chủ và client — đã được mở trên GitHub trong thư viện Time của Meta. Meta cũng kêu gọi cộng đồng, đặc biệt là những người duy trì client NTP trên Android hoặc iOS, cùng bật hỗ trợ NTS.

Vì sao NTP "trần" không còn đủ

NTP (Network Time Protocol) đã không có xác thực từ năm 1985, giống nhiều giao thức nền tảng khác của internet. Client gửi 48 byte, phía kia trả về 48 byte, và client tin ngay — không chữ ký, không danh tính. Vấn đề nằm ở chỗ thời gian không phải một giao thức cần bảo mật bình thường: nó là đầu vào mà mọi quyết định bảo mật khác dựa vào để đo đạc.

Thời gian nay đã trở thành yếu tố chịu lực trong nhiều cơ chế:

• Kiểm tra chứng chỉ: notBefore và notAfter được so sánh với đồng hồ cục bộ. Sai đồng hồ là sai kết quả.
• Hạn của token và thông tin xác thực: câu "có hiệu lực 15 phút" thực chất là một phát biểu về đồng hồ.
• Cửa sổ chống replay: loại bỏ yêu cầu cũ hơn N giây đòi hỏi phải biết chính xác thời điểm hiện tại.
• Tương quan log: hai máy chủ lệch giờ tạo ra một dòng thời gian chưa từng tồn tại.

Bản thân phép kiểm tra cũng vòng tròn: không thể xác thực notBefore/notAfter của X.509 nếu không biết thời gian hiện tại. Hai cách lách phổ biến đều có hại — bỏ qua kiểm tra cho đến khi đồng hồ được đặt đúng sẽ khiến thiết bị không được bảo vệ đúng lúc dễ bị tấn công nhất; hoặc nới rộng cửa sổ dung sai ở cả hai phía, khiến bên phát hành và bên xác thực cùng phải đoán mức sai của nhau.

Điều này từng chấp nhận được khi chứng chỉ có thời hạn 398 ngày. Nhưng ballot SC-081v3 của CA/Browser Forum đã thay đổi cuộc chơi: giới hạn chứng chỉ TLS công khai mới giảm còn 200 ngày từ tháng 3/2026, xuống 100 ngày từ tháng 3/2027, và chỉ còn 47 ngày từ tháng 3/2029 — thời gian tái sử dụng xác thực tên miền cũng giảm còn 10 ngày vào cùng mốc. Ở mức 47 ngày, quản lý chứng chỉ thủ công không còn khả thi ở mọi quy mô; việc gia hạn chuyển sang tự động, thường qua ACME. Một vòng gia hạn tự động trên máy chủ lệch giờ sẽ không tạo ticket — nó cấp lại, hoặc thất bại, theo lịch mà không ai theo dõi.

NTS hoạt động thế nào

NTS chia làm hai pha, và chính sự tách bạch này giúp nó triển khai được.

Pha 1 — Thiết lập khóa (NTS-KE): TLS 1.3 trên TCP/4460, thương lượng bằng ALPN ntske/1. Client và máy chủ thống nhất thuật toán AEAD, rồi dẫn xuất hai khóa phiên theo hướng (C2S và S2C) trực tiếp từ phiên TLS qua exporter RFC 5705. Máy chủ phát 8 cookie, chỉ định máy chủ NTP thực sự cần dùng qua bản ghi server negotiation, rồi đóng kết nối. Bước này chỉ diễn ra một lần, không phải cho từng gói tin.

Meta thương lượng ba AEAD: AES-SIV-CMAC-256 (ID 15) — thuật toán bắt buộc theo RFC 8915; AES-SIV-CMAC-512 (17); và AES-128-GCM-SIV (30). Ưu tiên của client thắng.

Pha 2 — NTP có xác thực: NTPv4 tiêu chuẩn trên UDP/123 gửi tới máy chủ được chỉ định, kèm các trường mở rộng NTS. Request mang một định danh duy nhất, một cookie và một authenticator; authenticator bao phủ mọi thứ đứng trước nhưng không mã hóa gì. Máy chủ mở cookie để lấy lại khóa phiên, xác minh authenticator và trả lời bằng định danh được dội lại cùng authenticator của chính nó — lần này có mang dữ liệu: cookie mới, được mã hóa bên trong.

Gói tin giả mạo sẽ không qua được bước xác minh và bị loại bỏ. Meta không gửi NTS NAK, nên một thất bại không phân biệt được với mất gói và không thể bị lợi dụng để ép client khởi tạo lại quá trình trao đổi khóa. Response bị replay mang định danh sai và không khớp với yêu cầu nào đang chờ. Do cookie thay thế nằm trong authenticator của response chứ không lộ ra ngoài, kẻ quan sát chỉ thấy một khối mờ khác nhau mỗi lần trao đổi và không thể lần theo client giữa các mạng.

Cookie không cần trạng thái

Cookie là một mẩu trạng thái máy chủ được giao cho client giữ hộ, chứa khóa phiên được niêm phong bằng AES-SIV. Cách làm hiển nhiên là một chùm khóa (key ring) sao chép sang mọi máy chủ — biến dịch vụ thời gian thành bài toán trạng thái phân tán. Meta không làm vậy. Mỗi máy chủ dẫn xuất khóa niêm phong từ một master secret dùng chung và ngày hiện tại:

key = HKDF-SHA256(master, salt = BE32(day), info = "fbnts-cookie-seal-v1")

day được tính bằng số chu kỳ 24 giờ trọn vẹn kể từ Unix epoch, không theo ngày lịch — nên không có múi giờ, không có DST, và mọi máy chủ đều tính ra cùng một số nguyên cho cùng một thời điểm. Số nguyên đó là key ID của cookie và được truyền công khai. Một máy chủ nhận cookie chưa từng thấy, do một máy chủ chưa từng liên lạc niêm phong, vẫn dẫn xuất lại khóa và mở được. Hệ thống chấp nhận lùi 2 ngày và tiến 1 ngày để bù lệch quanh ranh giới luân chuyển khóa.

Kết quả: không chùm khóa, không sao chép, không bảng phiên, không trạng thái chung để lệch nhau, và không có gì cho kẻ tấn công làm cạn kiệt. Đây cũng là lý do cách tách pha ở trên vận hành được — máy chủ KE và các máy chủ NTP mà nó chuyển giao là những máy khác nhau ở những nơi khác nhau, và chúng không bao giờ trao đổi gì với nhau. Thêm một máy chủ chỉ đơn giản là thêm một máy chủ.

Đường NTP thường vẫn nguyên vẹn: bộ phản hồi chỉ phân tích trường mở rộng khi chúng xuất hiện, nên client không xác thực đi đúng đoạn mã cũ với cùng chi phí.

Dùng NTS thế nào

Chỉ một dòng cấu hình chrony:

pool nts.meta.com nts iburst maxsources 5

nts.meta.com chỉ kết thúc phần trao đổi khóa. Trong bắt tay, nó quảng bá một bộ phản hồi NTP qua bản ghi server negotiation, nên client được chuyển hướng sang time.meta.com để gửi NTP xác thực. Máy chủ bạn cấu hình không phải máy chủ bạn thực sự nói chuyện cùng.

Chính sự gián tiếp đó là lý do phải dùng pool thay vì server: một dòng server chỉ cho một liên kết và một bộ phản hồi — điểm lỗi đơn, trong khi NTP cần nhiều nguồn để có thể "bỏ phiếu" loại nguồn sai. Lệnh chronyc authdata sẽ hiện các dòng như time1.meta.com đến time5.meta.com, tất cả ở chế độ NTS. Năm dòng nghĩa là năm nguồn xác thực độc lập chỉ từ một dòng cấu hình và một điểm cuối KE.

Trong bảng đó, Type 30 là AEAD được thương lượng (AES-128-GCM-SIV), KLen 128 là độ dài khóa phiên, CLen 68 là cookie (36 byte vỏ bọc quanh hai khóa 16 byte bên trong), Cook 8 là số cookie đang giữ và NAK 0 nghĩa là chưa có cookie nào bị từ chối. Điều thú vị hơn không nằm trong bảng: khóa phiên của mỗi dòng đến từ bắt tay TLS riêng và chỉ dùng cho liên kết đó, còn khóa niêm phong chúng vào cookie là khóa dùng chung — số ngày epoch, giống hệt trên mọi bộ phản hồi, đóng dấu bên trong cookie và client không bao giờ thấy. Chính sự phân tách này cho phép một lần trao đổi khóa giao cho client năm bộ phản hồi khác nhau chưa từng nói chuyện với nhau.

Khi một thành viên pool hoàn tất trao đổi khóa và chuyển sang bộ phản hồi được thương lượng, địa chỉ KE được giải phóng sẽ giao cho thành viên chưa giải quyết tiếp theo, lặp lại cho đến khi đủ maxsources bộ phản hồi trả lời. Năm nguồn thường lên trong khoảng 20 phút vì mỗi thành viên thực hiện trao đổi khóa của riêng mình lần lượt.

NTS chặn được gì và không chặn được gì

Khác với NTP, NTS ngăn được tấn công man-in-the-middle (MITM) làm giả câu trả lời. Một cuộc tấn công MITM cổ điển không cần phá mã hóa — nó chỉ cần trả lời client trước máy chủ thật. Nếu kẻ tấn công kéo đồng hồ lùi lại, chứng chỉ đã hết hạn có thể được xác thực lại, token đã thu hồi có thể dùng lại. Nếu đẩy đồng hồ tới, mọi thứ hết hạn cùng lúc.

Ví dụ: một thiết bị bị thuyết phục rằng đang ở năm 2037. NTP đếm giây trong trường 32 bit tràn vào tháng 2/2036, và một client bị kẹt bên kia ranh giới sẽ tính độ hiệu chỉnh sang sai kỷ nguyên — cơ chế sinh ra để sửa đồng hồ sai lại đẩy nó xa hơn. Mọi chứng chỉ trên thiết bị đều hết hạn, TLS thất bại, thiết bị không tới được bất cứ thứ gì có thể giúp, kể cả dịch vụ cập nhật của chính nó. Bản vá cần thiết không thể giao được, vì giao nó cần đúng cái đồng hồ đang hỏng. Thiết bị không hề bị hư, mọi bộ phận vẫn hoạt động đúng thiết kế — nó chỉ đang giữ một con số đưa nó ra ngoài tầm với của mạng. Phải khôi phục cài đặt gốc hoặc mang ra trung tâm bảo hành; nhân lên cho cả một đội thiết bị, chi phí của một số nguyên sai trở thành bài toán hậu cần.

Tương tự, một cuộc tấn công đẩy đồng hồ tới trên máy chủ phát hành thông tin xác thực khiến nó ký ra những thông tin tồn tại lâu hơn cửa sổ bạn thiết kế — vì đặc tính "hết hạn nhanh" hoàn toàn phụ thuộc vào đồng hồ của máy chủ phát hành.

Tuy vậy, NTS không sửa được mọi thứ. RFC 8915 nói rõ: kẻ tấn công giữ gói tin của bạn có thể dịch đồng hồ tới nửa độ trễ gây ra, và không phép mã hóa nào trong giao thức phát hiện được điều đó, vì mọi byte đều là thật. Xác thực cho biết ai viết gói tin, không cho biết gói tin bay mất bao lâu. Các biện pháp giảm thiểu vẫn là những cách quen thuộc: nhiều nguồn độc lập, giới hạn hợp lý, bước nhảy có giới hạn.

Các điểm khác nằm ngoài phạm vi bảo vệ:

• Khởi động lần đầu (bootstrapping): NTS-KE chạy trên TLS, mà TLS cần đồng hồ hoạt động — lại đúng bài toán vòng tròn ở trên. Thiết bị có RTC hỏng vẫn phải đạt được thời gian gần đúng trước lần bắt tay đầu tiên.
• Máy chủ sai: NTS xác thực đường truyền, không xác thực câu trả lời. Một máy chủ cấu hình đúng, xác thực đúng nhưng đơn giản là sai sẽ giao thời gian sai kèm chữ ký hoàn hảo. Vẫn cần quorum, kiểm tra hợp lý và giám sát.
• Tính đơn điệu: thời gian xác thực vẫn là thời gian đồng hồ treo tường, và đồng hồ treo tường có thể lùi — khi có giây nhuận hoặc khi một hiệu chỉnh được áp dụng. Cloudflare từng gặp chuyện này với DNS có thẩm quyền cuối năm 2016: một vòng khứ hồi của resolver đo qua giây nhuận ra số âm, lan vào bước chọn upstream và làm panic hàm rand.Int63n() của Go. Không có gì bị giả mạo, không có gì bị giao sai. Nếu mã của bạn đo thời gian trôi qua, hãy dùng đồng hồ đơn điệu.

Khoảng trống lớn nhất: thiết bị di động

RFC 8915 được công bố trên IETF Standards Track dưới dạng Proposed Standard vào tháng 9/2020. Cloudflare đã ra mắt time.cloudflare.com với NTS sớm hơn 15 tháng, vào tháng 6/2019, dựa trên bản nháp khi đó, và chứng minh nó hoạt động ở quy mô lớn.

Về phía máy chủ, danh sách NTS công khai hiện có vài chục mục, chủ yếu là các viện đo lường quốc gia và nhà vận hành hạ tầng internet như PTB, Netnod và time.nl. Meta đang thêm một mục nữa.

Khoảng trống lớn hơn nằm ở client. NTS có mặt ở nơi người ta kỳ vọng trong thế giới máy chủ — chrony và ntpsec đã hỗ trợ. Nhưng nó vắng bóng hoàn toàn trong client thời gian mặc định của các nền tảng chiếm phần lớn thiết bị đầu cuối trên internet. Đồng bộ giờ hệ thống của Android là SNTP thường trên UDP/123 — gói 48 byte cố định, không xử lý trường mở rộng, bên cạnh NITZ và GNSS — nên không có đường NTS. Thiết bị Apple đồng bộ qua timed với time.apple.com, và theo Meta, ở đó cũng chưa có hỗ trợ NTS.

Hai nền tảng đó đặt đồng hồ cho hàng tỷ điện thoại, đồng hồ thông minh và tai nghe, và mỗi thiết bị đều đang tin một gói UDP không xác thực. Nhà sản xuất thiết bị có thể đóng gói một client hỗ trợ NTS riêng ngay hôm nay — chrony chạy tốt trên Android — nhưng đó chỉ là giải pháp tạm cho việc mà nền tảng nên tự làm.

Góc nhìn

Với các kỹ sư và doanh nghiệp Việt Nam, bài học thực dụng nhất nằm ở lộ trình thời hạn chứng chỉ TLS đang rút ngắn dần đến 47 ngày vào tháng 3/2029. Khi gia hạn trở thành một vòng lặp tự động không người trông, đồng hồ lệch trên máy chủ không còn là phiền toái vận hành mà là nguyên nhân trực tiếp khiến chứng chỉ tự cấp lại thất bại hoặc bị từ chối. Bất kỳ hệ thống nào chạy ACME, xác thực token ngắn hạn hay phụ thuộc vào log tập trung đều nên rà lại nguồn thời gian của mình.

Cụ thể, có thể chuyển client NTP phía máy chủ sang chrony hoặc ntpsec và bật NTS trỏ tới một dịch vụ công khai như nts.meta.com, dùng cấu hình pool với nhiều nguồn thay vì một server duy nhất để tránh điểm lỗi đơn. Với mã nguồn đo thời gian trôi qua, cần dùng đồng hồ đơn điệu thay vì giờ treo tường. Còn với thiết bị di động và thiết bị IoT, vì các nền tảng phổ biến vẫn chưa hỗ trợ NTS sẵn, việc cân nhắc nhúng một client NTS riêng là hướng đáng tính nếu tính toàn vẹn thời gian là yêu cầu bảo mật thực sự.