Squid có thể được sử dụng làm proxy chấm dứt TLS của Nether để mã hóa các kết nối TCP bằng chứng chỉ ứng dụng khách không?

trừu tượng

Tôi cần một kết nối TCP được mã hóa từ nhiều máy khách đến một cổng duy nhất qua internet. Điều này có thể được nhận ra với Mực không?

Tình hình cụ thể

Chúng tôi sử dụng giải pháp quản lý khách hàng và giám sát trong công ty của chúng tôi có thể truy cập qua mạng LAN và VPN. Hiện tại có thể truy cập được từ các máy tính xách tay bên ngoài không sử dụng VPN của công ty . Thông tin liên lạc phải được mã hóa (TLS). Xác thực khách hàng phải sử dụng chứng chỉ ứng dụng khách. Giao tiếp được bắt đầu bởi các máy khách và sử dụng một cổng TCP duy nhất.

Kết quả điều tra của tôi

NGINX Plus dường như cung cấp tính năng này nhưng quản trị viên của chúng tôi thích mực hoặc apache. Tại wiki mực tôi thấy rằng: Tính năng: HTTPS (HTTP Secure hoặc HTTP qua SSL / TLS) trong đó mã hóa TCP được đề cập. Nhưng tôi cũng tìm thấy cảnh báo này:

Điều quan trọng cần lưu ý là các giao thức được truyền qua CONNECT không bị giới hạn ở các giao thức mà Squid thường xử lý. Theo nghĩa đen, mọi thứ sử dụng kết nối TCP hai chiều đều có thể được chuyển qua đường hầm CONNECT. Đây là lý do tại sao các ACL mặc định của Squid bắt đầu bằng cách từ chối CONNECT! SSL_Ports và tại sao bạn phải có lý do rất chính đáng để đặt bất kỳ loại quy tắc cho phép nào lên trên chúng.

Câu hỏi tương tự

Câu hỏi này Mã hóa kết nối máy khách với proxy chuyển tiếp mực bằng SSL là simlar, nhưng không xử lý proxy ngược / proxy chấm dứt TLS.

Những gì tôi cần biết

Tôi chỉ có kiến ​​thức cơ bản về các công nghệ đó và quản trị viên của chúng tôi đã hỏi tôi về tính khả thi chung.

• Squid có thể được sử dụng để lưu mã hóa các kết nối TCP không?
• Điều này có thể được thực hiện bằng cách sử dụng xác thực với chứng chỉ ứng dụng khách?
• Hoặc chỉ nên sử dụng cho các kết nối HTTPS?

Có thể quản trị viên của bạn không thích NGINX Plusvì đó không phải là nguồn mở và sẽ chấp nhận một sản phẩm nguồn mở được duy trì tốt khác. Sau đó yêu cầu anh ta nhìn vào stunnel . Nó được thiết kế cho chính xác nhu cầu của bạn.

Trích dẫn một ví dụ stunnel tại wikipedia (đối với SMTP, nhưng điều này sẽ phù hợp với nhu cầu của bạn):

Ví dụ: người ta có thể sử dụng stunnel để cung cấp kết nối SSL an toàn cho máy chủ thư SMTP không nhận biết SSL hiện có. Giả sử máy chủ SMTP mong đợi các kết nối TCP trên cổng 25. Người ta sẽ định cấu hình stunnel để ánh xạ cổng SSL 465 sang cổng không SSL 25. Một ứng dụng thư kết nối qua SSL đến cổng 465. Lưu lượng truy cập mạng từ máy khách ban đầu chuyển qua SSL đến stunnel ứng dụng, mã hóa / giải mã lưu lượng trong suốt và chuyển tiếp lưu lượng không bảo mật đến cổng 25 cục bộ. Máy chủ thư thấy một ứng dụng thư không phải SSL.

Quá trình stunnel có thể chạy trên cùng hoặc một máy chủ khác với ứng dụng thư không bảo mật; tuy nhiên, cả hai máy thường sẽ đứng sau tường lửa trên mạng nội bộ an toàn (để kẻ xâm nhập không thể tự thực hiện kết nối không bảo mật của mình trực tiếp đến cổng 25).

CONNECT chỉ được các máy khách HTTP sử dụng cho proxy HTTP để thiết lập đường hầm thông qua proxy. Không có sơ đồ nào trong HTTP để kết nối được mã hóa với proxy HTTP.

Tôi nghi ngờ proxy HTTP không phải là thứ bạn đang tìm kiếm ở đây.

Tôi không biết Squid có hỗ trợ các phích cắm TCP với TLS và chứng chỉ ứng dụng khách hay không nhưng WinGate thì có. Nó cũng có khả năng xác minh UserPrincipalName trong chứng chỉ cho Active Directory.

Tuyên bố miễn trừ trách nhiệm: Tôi làm việc cho Qbik, tác giả của WinGate.