Lỗi chứng chỉ SSL trong Cổng thông tin

10

Tình huống: Khách của khách sạn cố gắng truy cập internet thông qua cổng bị giam cầm của chúng tôi. Vấn đề: Google, Yahoo và hiện tại ngày càng có nhiều trang web chuyển hướng tất cả các trang chủ sang HTTPS để khách gặp lỗi Chứng chỉ khi chúng tôi chuyển hướng chúng đến trang đăng nhập của chúng tôi. Mục đích đánh giá cao của SSL là thực hiện chính xác điều này nhưng tự hỏi liệu có cách nào khác để quản lý nhật ký khách trong quá trình xác nhận để xác nhận danh tính của họ hay không, trước khi cho phép truy cập qua tường lửa. Đó là những vị khách kỳ dị không hiểu. Về cơ bản cần một kiến trúc khác nhau cho một quá trình xác thực / cổng thông tin bị giam cầm và tự hỏi suy nghĩ của bất kỳ ai có. Cảm ơn.

ssl redirect

Giải pháp có thể: WPA2-Enterprise với máy chủ xác thực Radius.

— Ajedi32

Đây không phải là một giải pháp, nhưng đối với các máy chủ thời điểm như một cách giải quyết. Cho phép người dùng truy cập https một cách tự do và trong lần truy cập http đầu tiên, họ sẽ được chuyển hướng khi Công nghiệp di chuyển ngày càng nhiều sang https, điều này sẽ bị lỗi thời.

— cusco

6

Toàn bộ định nghĩa của "cổng thông tin bị giam cầm" xoay quanh việc "chuyển hướng người dùng mà không có kiến thức của anh ấy", đó chính xác là một trong những điều mà SSL được tạo ra để tránh.

Nếu URL đầu tiên mà trình duyệt cố gắng mở là một HTTPS, thì không có cách nào chuyển hướng lưu lượng mà không tạo ra lỗi chứng chỉ.

— Massimo
nguồn

4

Vâng, tôi nghĩ rằng OP hiểu điều đó. Câu hỏi là: cái gì thay thế? (Ví dụ: Nếu mọi trang web tồn tại đều sử dụng HTTPS, làm thế nào bạn có thể "quản lý nhật ký khách trên quy trình xác nhận" mà không cần cổng bị khóa?)

— Ajedi32 17/2/2015

5

Dự án Chromium có một trang tốt mô tả cách logic của chúng hoạt động để phát hiện các cổng bị giam cầm:

Cố gắng kết nối (HTTP đơn giản) với máy chủ nổi tiếng + URI
Chờ đợi HTTP 204 No Content
Nếu nhận được phản hồi khác, giả sử đó là cổng bị khóa.

Có một số chi tiết khác trong liên kết được cung cấp liên quan đến cách họ xử lý các lỗi DNS khi cố gắng giải quyết máy chủ nổi tiếng, v.v. Đây chỉ là một ví dụ, nhưng (theo kinh nghiệm cá nhân của tôi) các thiết kế HĐH hiện đại đang sử dụng các quy trình tương tự như thế này để phát hiện và nhắc nhở người dùng thậm chí, trong một số trường hợp, trước khi người dùng mở trình duyệt. (Xem xét: một người nào đó chỉ muốn sử dụng ứng dụng khách IMAP hoặc dịch vụ không phải HTTP khác.) Trong trường hợp đó, việc phát hiện xảy ra không qua SSL / TLS để tránh sự lo lắng của bạn.

RFC 6585 Mục 6 đề xuất mã trạng thái HTTP mới 511 Network Authentication Requiredkhông giúp ích cho trường hợp SSL / TLS của bạn nhưng là một tiêu chuẩn khác mà bạn có thể xem xét nếu bạn chưa sử dụng nó.

— William Giá
nguồn

Android cũng có hỗ trợ phát hiện các cổng bị giam cầm. Khi phát hiện một cổng bị khóa, nó sẽ hiển thị một thông báo trên thanh trạng thái. Từ ngữ giống như "Đăng nhập vào mạng không dây". Điều đó xảy ra ngay cả khi chưa có ứng dụng nào cố gắng sử dụng kết nối. Tại một số thời điểm, tôi cũng nhận thấy một cổng bị khóa gửi chuyển hướng 30x với tiêu đề HTTP bổ sung, cho biết đây là cổng bị khóa và phần thân chứa một số dữ liệu XML. Tôi không biết nếu đó là một số hành vi tiêu chuẩn.

— kasperd

0

Trong mọi trường hợp, nếu người dùng nhận được lỗi chứng chỉ là do Chứng chỉ không khớp với tên máy chủ của Trang web .

Trong trường hợp của bạn, điều này có nghĩa là bạn đang chuyển hướng người dùng đến cổng thông tin của mình mà không thay đổi URL. Người dùng thấy " http://www.google.com " trong thanh địa chỉ của họ nhưng cổng thông tin của bạn trong màn hình. Những cái này không khớp, rõ ràng, và chứng chỉ cũng không.

Bạn cần chuyển hướng chúng trong HTTP (trước khi nhảy HTTPS) đến địa chỉ cổng thông tin của bạn (hoặc tên máy chủ), để chúng đăng nhập vào đó và sau đó chuyển hướng chúng một lần nữa đến đích dự định, sẽ khớp chính xác.

Xem https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx để biết cách thực hiện với mã HTTP 3xx, đặc biệt là 303.

— Ghen tị
nguồn

Hầu hết người dùng có thể không gõ https:// , nhưng mọi dấu trang được lưu trữ hoặc các cơ chế ghim khác có thể dẫn đến yêu cầu đầu tiên đến dịch vụ dựa trên HTTPS và do đó thất bại vì bắt tay TLS không thành công trước khi chuyển sang lớp giao thức HTTP để chuyển hướng. Khác với dấu trang, các ví dụ về "ghim" như vậy bao gồm thanh tìm kiếm của trình duyệt có kiến thức trước rằng nhà cung cấp dịch vụ tìm kiếm thích truy vấn thông qua HTTPS; hoặc một ứng dụng di động kết nối với các dịch vụ mạng an toàn.

— William Giá

-1

Giải pháp tạm thời là hướng dẫn người dùng bắt đầu URL bắt đầu bằng "http" chỉ sau khi tín hiệu wifi được kết nối.

nhưng thật không may, người dùng không thích nó. họ nói "bạn đã có dịch vụ wifi phức tạp như thế nào"

— ngược lại
nguồn