Xác thực HTTPS Basic và IPsec: mỗi loại bảo vệ điều gì

Mở công cụ dành cho nhà phát triển, tải ứng dụng nội bộ và quan sát cách một yêu cầu đi qua bốn trạm kiểm soát trước khi trang được hiển thị. Đầu tiên tên được phân giải, sau đó một kết nối TCP được mở, tiếp theo quá trình bắt tay TLS xác lập ai là máy chủ, và chỉ sau đó ứng dụng mới hỏi bạn là ai. Hãy coi đây là những sự kiện riêng biệt, vì mỗi sự kiện thất bại với bằng chứng khác nhau và mỗi sự kiện thuộc về một nhóm khác nhau. Phần lớn sự nhầm lẫn trong các sự cố đến từ việc đọc 401 như một vấn đề đường hầm, hoặc đọc vấn đề đường hầm như một mật khẩu sai.

Trạm kiểm soát thứ nhất: đây có phải máy chủ bạn định nói chuyện

Quá trình bắt tay TLS trả lời câu hỏi đó trước khi bất kỳ thông tin xác thực nào được gửi đi. Máy khách của bạn kiểm tra chuỗi chứng chỉ dựa trên kho tin cậy và xác nhận rằng tên trong chứng chỉ khớp với máy chủ bạn đã nhập. Nếu bước đó thất bại, trình duyệt hiển thị lỗi chứng chỉ và không bao giờ gửi tiêu đề Authorization. Vì vậy lời nhắc mật khẩu không phải bằng chứng rằng máy chủ là thật; đó là bằng chứng rằng ứng dụng đã trả lời.

Đây là nơi ranh giới đầu tiên xuất hiện. TLS bảo vệ kết nối cho đến điểm kết thúc của nó. Nếu một bộ cân bằng tải kết thúc TLS và chuyển tiếp HTTP thuần đến ứng dụng, đoạn được mã hóa kết thúc tại bộ cân bằng, và thông tin xác thực chỉ được bảo vệ ở chặng đầu tiên đó.

Trạm kiểm soát thứ hai: điều gì thực sự được truyền trong một lần trao đổi 401

Xác thực HTTP Basic gửi định danh người dùng và mật khẩu trong một tiêu đề, được mã hóa bằng Base64 như mô tả trong RFC 7617. Authorization: Basic dXNlcjpwYXNz là hình dạng của nó; bất kỳ ai đọc được yêu cầu đều có thể đảo ngược mã hóa, nên toàn bộ tính bí mật đến từ lớp truyền tải bên dưới. curl -v hiển thị cả thử thách WWW-Authenticate: Basic và tiêu đề bạn gửi lại.

Tiêu đề đó cho ứng dụng biết ai đang hỏi. Nó không cho mạng biết ai được kết nối, và bản thân nó không mã hóa bất cứ thứ gì. Ứng dụng vẫn phải kiểm tra thông tin xác thực với một kho lưu trữ và quyết định tài khoản đó được làm gì, đó là phân quyền và diễn ra sau khi xác thực.

Đường hầm IPsec nằm ở đâu trên đường đi đó

Bây giờ hãy đi ra ngoài từ trình duyệt. Một đường hầm IPsec giữa hai cổng bảo mật bảo vệ lưu lượng được chọn giữa hai cổng, không phải giữa máy tính xách tay của bạn và tiến trình ứng dụng. ESP ở chế độ đường hầm bọc gói tin gốc, các cổng mã hóa và xác thực nó, và các địa chỉ bên trong được giữ nguyên để phía xa có thể định tuyến yêu cầu đến ứng dụng.

Việc chọn lựa là phần khiến người ta vấp. Các đường hầm dựa trên chính sách dùng bộ chọn lưu lượng, thường được viết dưới dạng danh sách kiểm soát truy cập, để quyết định gói nào đi vào đường hầm. Các đường hầm dựa trên tuyến dùng giao diện ảo và bảng định tuyến thay thế. Trên Linux, ip xfrm policy hiển thị các bộ chọn và ip xfrm state hiển thị các liên kết bảo mật đã thiết lập; trên một thiết bị tường lửa, tương đương là bảng SA của đường hầm cộng với một bộ theo dõi gói.

Hệ quả đáng nói thẳng. Một gói tin có thể nằm trong một đường hầm hoàn toàn khỏe mạnh mà vẫn mang một yêu cầu HTTPS mà ứng dụng từ chối, và thông tin xác thực hợp lệ có thể đến qua một đường không có đường hầm nào nếu định tuyến cho phép.

Hãy đọc lỗi ở lớp đã báo cáo nó

401 nghĩa là ứng dụng không chấp nhận thông tin xác thực. 403 nghĩa là ứng dụng đã chấp nhận danh tính và từ chối thao tác. Lỗi TLS nghĩa là máy khách không chấp nhận máy chủ. Không có tuyến hoặc chính sách không khớp nghĩa là gói tin không bao giờ đến được cổng phía xa. Bốn kiểu thất bại khác nhau, bốn chủ sở hữu khác nhau, và không kiểu nào được chẩn đoán bằng cách nhìn chằm chằm vào biểu mẫu đăng nhập.

Hãy dùng bằng chứng mà mỗi lớp tạo ra: bảng mạng của trình duyệt cho trạng thái và tiêu đề, openssl s_client -connect host:443 cho chuỗi chứng chỉ, bộ đếm SA và nhật ký của cổng cho lưu lượng đường hầm, và nhật ký ứng dụng cho quyết định về tài khoản. Khi hai lớp cùng báo lỗi một lúc, hãy sửa lớp thấp hơn trước, vì một đường hầm đã chết có thể dễ dàng che khuất một lỗi xác thực và ngược lại.

Lập bản đồ một dịch vụ từ đầu đến cuối

Viết năm dòng cho dịch vụ bạn đang khắc phục: đường hầm nối những phía nào, các bộ chọn cho phép những mạng con và cổng nào, TLS kết thúc ở đâu và chứng chỉ khẳng định danh tính nào, dùng tài khoản và vai trò ứng dụng nào, và mỗi lớp ghi nhật ký ở đâu. Hãy giữ chúng trên một trang, vì mục đích của bản đồ là chỉ ra nơi trách nhiệm của một lớp kết thúc và lớp tiếp theo bắt đầu.

Sau đó hãy thử một trường hợp phủ định cho mỗi lớp. Dùng một mật khẩu sai và xác nhận bạn nhận 401 chứ không phải hết thời gian chờ. Kết nối từ một mạng con nằm ngoài các bộ chọn và xác nhận gói tin không đi qua đường hầm. Trình bày một chứng chỉ cho tên sai và xác nhận máy khách từ chối trước khi gửi thông tin xác thực. Ba kết quả đó cho bạn biết nhiều về thiết kế hơn bất kỳ sơ đồ ô vuông nào.

Cuối cùng, hãy chủ động quyết định mỗi mối quan hệ cần sự bảo vệ nào. Xác thực Basic trên TLS là lựa chọn hợp lý cho một công cụ nội bộ nhỏ nằm sau cổng; nó không thay thế phân quyền theo từng người dùng hay việc bảo vệ lưu lượng vượt ra ngoài điểm cuối TLS. Đường hầm bảo vệ đường đi, chứng chỉ bảo vệ chặng, và 401 bảo vệ tài khoản, và chỉ cái cuối cùng trong số đó biết bạn là ai.