Phiên bản đầu tiên không được khuyến nghị - tại f8bet

/imgposts/xoi9h04k.jpg

Do không tìm thấy logic của HTTP Digest Auth Middleware trong phần mã nguồn server TR-069 của TeamsACS, tôi bắt đầu nghi ngờ rằng mình có thể hiểu sai phần xác thực của giao thức TR-069. Vì vậy, tôi đã tra cứu tài liệu chính thức của giao thức này.

  • Phiên bản đầu tiên không được khuyến nghị.
  • Đề xuất xem phiên bản thứ năm, phần mô tả ở đây khác biệt so với phiên bản đầu tiên. Tài liệu này thực sự dài và phức tạp, nên tôi đã lưu nó vào điện thoại và Kindle để đọc dần khi rảnh.

Trong tài liệu có hai mục nhỏ nói về việc xác thực:

  • 3.4.4 Xác thực (Authentication)
  • 3.4.5 Xác thực dạng tiêu hóa (Digest Authentication)

Tôi sẽ dịch từng đoạn và cố gắng hiểu rõ hơn:

Nếu thiết bị CPE không được xác thực bằng TLS, thì hệ thống ACS phải xác thực CPE qua HTTP. Nếu TLS được sử dụng cho mã hóa, thì ACS nên sử dụng xác thực cơ bản (basic authentication). Nếu TLS không được sử dụng, thì ACS phải sử dụng xác thực dạng tiêu hóa (digest authentication).

  • Nếu CPE không được xác thực thông qua TLS, thì hệ thống ACS cần phải thực hiện xác thực qua HTTP. TLS cũng có thể dùng cho việc xác thực sao? Tôi cứ nghĩ TLS chỉ dùng để mã hóa thôi.
  • Nếu TLS được dùng cho mã hóa, thì hệ thống ACS nên sử dụng basic auth. (Đây là phiên bản thứ năm của TR-069, nhưng trong phiên bản đầu tiên lại viết là có thể dùng basic auth hoặc http digest auth.)
  • Nếu không sử dụng TLS, thì hệ thống ACS phải dùng digest auth.

Hai điều sau soi keo hom nay dễ hiểu hơn, nhưng điều đầu tiên cần tiếp tục nghiên cứu nguyên lý xác thực TLS. Có lẽ vì TeamsACS đã kích hoạt xác thực TLS nên hệ thống ACS không sử dụng HTTP Digest Authentication mà chỉ dùng một phiên bản giới hạn của Basic Auth.

Thiết bị CPE PHẢI hỗ trợ cả xác thực HTTP cơ bản và dạng tiêu hóa. Hệ thống ACS chọn phương pháp xác thực bằng cách gửi thách thức xác thực cơ bản hoặc dạng tiêu hóa. Nếu TLS được sử dụng cho mã hóa, thì CPE NÊN chủ động gửi thông tin đăng nhập cơ bản theo như được định nghĩa trong Phần 2 của tài liệu số 7.

  • CPE phải hỗ trợ cả HTTP basic auth và digest auth. Phương pháp cụ thể phụ thuộc vào việc hệ thống ACS chỉ định loại nào (thông qua việc gửi thách thức xác thực - challenge).
  • Nếu TLS được sử dụng để mã hóa, CPE nên sử dụng basic auth.

Như vậy, việc mô phỏng CPE không hỗ trợ digest auth dường như cũng không phải vấn đề lớn.

Lưu ý - Việc sử dụng thách thức xác thực yêu cầu tin nhắn ban đầu (thường là yêu cầu RPC kiểu Inform) phải được gửi đi; việc sử dụng xác thực cơ bản chủ động cùng với TLS là an toàn và tránh được nhu cầu thêm yêu cầu.

  • Khi hệ thống ACS gửi thách thức xác thực đến CPE (dạng cơ bản hoặc tiêu hóa), cần có một tin nhắn khởi tạo từ CPE gửi đến ACS (thường là tin nhắn kiểu Inform).
  • Nếu CPE chủ động gửi trước thông tin đăng nhập cơ bản cùng với TLS, thì không cần thêm yêu cầu nào khác.

Nếu CPE nhận được thách thức xác thực từ hệ thống ACS (bất kể là dạng cơ bản hay tiêu hóa), thì CPE NÊN gửi header Authorization trong tất cả các yêu cầu HTTP tiếp theo trong suốt thời gian kết nối TCP. Dù CPE có làm như vậy hay không, hệ thống ACS CÓ THỂ gửi thách thức xác thực bổ sung ở bất kỳ giai đoạn nào của phiên làm việc, dù trong một hoặc nhiều kết nối TCP.

  • Nếu CPE nhận được thách thức xác thực từ ACS (có thể là basic auth hoặc digest auth), thì trong các yêu cầu HTTP tiếp theo, CPE cần thêm thông tin Authentication vào header. Tuy nhiên, dù CPE có làm thế hay không, hệ thống ACS vẫn có thể phát ra thách thức xác thực tại bất kỳ thời điểm nào trong quá trình phiên làm việc.

Tên người dùng này cần phải duy nhất. Cụ thể, có hai định dạng được khuyến nghị:

Định dạng 1: <OUI> "-" <ProductClass> "-" <SerialNumber>
Định dạng 2: <OUI> "-" <SerialNumber>

OUI là viết tắt của "Organizationally Unique Identifier" (Biểu识 duy nhất tổ chức).

Tuy nhiên, các định dạng này không bắt buộc. Tôi thấy rằng một số hệ thống trong nước sử dụng chuỗi ngẫu nhiên làm tên người dùng. Mật khẩu phải khác nhau đối với mỗi thiết bị CPE.