Chuyển hướng TẤT CẢ lưu lượng truy cập web thông qua TLS mà không cần VPN

Giả định:

Người phục vụ:

• Tôi có máy chủ Debian Squeeze, có thể định tuyến trên Internet công cộng, với địa chỉ IPv4 tĩnh.
• Tôi có quyền truy cập không hạn chế để sửa đổi phần mềm trên máy chủ.
• Máy chủ có thể lắng nghe trên các cổng tùy ý, cấu hình lại các quy tắc tường lửa, về cơ bản không có hạn chế nào về những gì máy chủ có thể được thực hiện.

Khách hàng:

• Tôi có thể chạy Firefox, chương trình Java, chương trình .NET và một số tệp thực thi gốc không yêu cầu quyền truy cập của quản trị viên trên hệ thống cục bộ của tôi (máy tính để bàn Windows bị khóa không có quyền quản trị).
• Tôi có thể cài đặt Addons vào Firefox.
• Tôi có thể nghe trên bất kỳ cổng nào trên localhostgiao diện loopback ( ). Vì vậy, các chương trình nói trên có thể liên kết với một cổng cục bộ và thực hiện I / O mạng tùy ý mà không cần thông qua proxy.
• Tất cả các truy cập Internet công cộng được định tuyến thông qua proxy HTTP hạn chế chặn nhiều trang web và kiểm tra trạng thái cẩn thận. Trên cổng 80, nó cho phép độc quyền HTTP (không có TLS / SSL). Trên cổng 443, nó cho phép CONNECTSSL / TLS dựa trên các máy chủ từ xa không bị chặn bởi tên miền / địa chỉ IP.
• Proxy HTTP hạn chế không thực hiện kiểm tra gói sâu các kết nối TLS được phép thông qua proxy và nó không thực hiện các cuộc tấn công Man in the Middle vào các kết nối đó.
• Máy chủ được đề cập ở trên mà tôi có quyền truy cập, không bị chặn bởi proxy.

Mục tiêu:

Tôi muốn định tuyến tất cả các yêu cầu HTTP và HTTPS do Firefox phát ra, thông qua máy chủ ở trên, qua SSL / TLS.

Các ghi chú khác về "Mục tiêu":

• Ngay cả khi trang web điểm cuối (ví dụ http://superuser.com:) không sử dụng SSL / TLS cho máy chủ của tôi, tôi vẫn muốn sử dụng SSL / TLS từ máy khách của mình đến máy chủ của mình và để máy chủ của tôi thực hiện yêu cầu HTTP - dù được mã hóa hay không - - đến đích mong muốn của tôi.
• Tôi không quan tâm nếu máy chủ của tôi đang xem lưu lượng SSL "rõ ràng". Nói cách khác, tôi không yêu cầu mã hóa SSL đầu cuối đầy đủ từ máy khách cục bộ của mình, tất cả các cách đến máy chủ từ xa, nếu máy chủ từ xa đang được truy cập bởi vd https://google.com. Nói cách khác, tôi tin tưởng máy chủ sẽ giữ bí mật dữ liệu của tôi.
• Tôi sẵn sàng cài đặt bất kỳ phần mềm hoặc addon Firefox nào không yêu cầu quyền quản trị và có thể chạy trên Windows 7 32 bit.
• Phần mềm nguồn mở được ưu tiên hơn sở hữu độc quyền và phần mềm miễn phí được ưu tiên hơn phần mềm yêu cầu phí giấy phép.
• Phần mềm hiện có được ưu tiên hơn là phải mã hóa phần mềm mới, mặc dù tôi sẵn sàng viết mã nếu đó là cách duy nhất.

Tôi đang tìm kiếm một "giải pháp" được mô tả một cách lỏng lẻo mô tả:

• Phần mềm nào sẽ được yêu cầu trên máy khách? Nếu có một gói phần mềm cụ thể mà bạn biết, hãy đặt tên cho nó; mặt khác, mô tả những gì phần mềm máy khách sẽ phải làm .
• Phần mềm nào sẽ được yêu cầu trên máy chủ? Nếu có một gói phần mềm cụ thể mà bạn biết, hãy đặt tên cho nó; mặt khác, mô tả những gì phần mềm máy chủ sẽ phải làm .
• Nếu bạn đặt tên cho các gói phần mềm cụ thể ở trên, hãy mô tả các tham số cấu hình nào sẽ cần thiết để thiết lập nó để đáp ứng mục tiêu của tôi.
• Nếu vì lý do nào đó bạn tin rằng điều này là không thể , hãy mô tả lý do tại sao .

Những điều tôi đã thử mà không làm việc

• Cài đặt squidtrên máy chủ của mình, tôi đã cố gắng thiết lập proxy HTTP tiêu chuẩn của riêng mình trên máy chủ của mình. Điều này không thành công, bởi vì khi tôi yêu cầu các trang web trong Firefox qua HTTP thông thường, Firefox cũng cố gắng truy cập máy chủ của tôi qua HTTP thông thường! Điều này không được chấp nhận, vì tất nhiên proxy trên mạng cục bộ của tôi có thể quan sát và / hoặc chặn lưu lượng HTTP thông thường giữa máy khách của tôi và máy chủ.
• VPN không hoạt động , thậm chí không OpenVPN qua TLS nghe trên cổng 443, vì tôi không có quyền trên máy tính cục bộ để cài đặt tunbộ điều hợp mạng có thể thực hiện định tuyến lớp 3, tôi cũng không thể thực hiện bất kỳ loại định tuyến lớp 2 nào (ví dụ tap). Tóm lại: Tôi cần quyền quản trị để cài đặt OpenVPN và ngay cả khi tôi có các quyền quản trị đó tạm thời, công ty sẽ không hài lòng nếu họ thấy nó được cài đặt. Một chương trình Java hoặc .NET ít được chú ý hơn, đặc biệt là khi nó không được cài đặt trong Thêm / Xóa Chương trình và không có thành phần trình điều khiển hạt nhân như OpenVPN.

Tôi đã hiểu rồi. : D Giải pháp này đáp ứng tất cả các yêu cầu của tôi và đáp ứng hoàn hảo tất cả các mục tiêu của tôi. Hiệu suất cũng không quá tệ, xem xét mức độ gián tiếp cần thiết để đạt được điều này.

Cách tiếp cận chung là như vậy:

1. Thiết lập Tổ chức phát hành chứng chỉ cục bộ (CA) và tạo "khóa máy chủ" và "khóa máy khách" (Tôi đã sử dụng mã hóa 256 bit). Đối với điều này, tôi đã sử dụng Easy-RSA phiên bản 3.0.0-rc2.

2. Chạy bất kỳ proxy HTTP tiêu chuẩn không có thật nào trên "Hộp Debian" (máy chủ trên Internet công cộng), đảm bảo chỉ nghe trên localhost (không nên tiếp xúc với Internet công cộng). Đối với mục đích của tôi, tôi đã sử dụng Privoxy, nhưng Squidcũng sẽ làm việc như vậy. Vì nó chỉ nghe trên localhost, nên không cần xác thực (trừ khi có các quy trình đang chạy trên hộp của bạn mà bạn không tin tưởng; trong trường hợp đó, yike ...)

3. Tải stunnel và cài đặt nó trên cả máy khách và máy chủ. Quá trình để làm điều này sẽ được cụ thể hệ điều hành; trong trường hợp của tôi, tôi đã chọn biên dịch stunnel từ nguồn (hoang tưởng ...) cho Windows, đây là một quá trình khá liên quan mà tôi sẽ không nêu chi tiết ở đây. Về phía máy chủ, nó đã có sẵn trong trình quản lý gói :)

4. Cấu hình của Stunnel ban đầu khá khó xử, nhưng nó đơn giản hơn vẻ ngoài của nó! Về cơ bản, trên máy chủ, bạn cần một cái gì đó như "stunnel.conf" bên dưới. Trên máy khách, bạn cần một cái gì đó như "stunnel.conf" bên dưới.

5. Bắt đầu đặc quyền; bắt đầu stunnel trên máy chủ, trỏ nó vào tập tin cấu hình; bắt đầu stunnel trên máy khách, trỏ nó vào tập tin cấu hình. Thực sự không có gì đặc biệt về cấu hình của Privoxy; mặc định là tốt cho tôi

6. Trong Firefox, trình duyệt bạn chọn ở phía máy khách, đặt proxy HTTP và HTTPS giống như cổng stunnel của máy khách của bạn đang lắng nghe - có thể giống như localhost: 8080.

Tôi có lẽ nên lưu ý rằng nếu proxy mạng cục bộ của bạn yêu cầu một số loại xác thực, bạn sẽ phải lấy stunnel để xác thực cho bạn hoặc sử dụng proxy chặn chặn cục bộ khác và xâu chuỗi chúng lại với nhau - một cái gì đó như Firefox -> stunnel -> cục bộ xác thực proxy -> LAN proxy / gateway -> internet -> stunnel của máy chủ của bạn -> privateoxy.

Đó là rất nhiều bản sao, nhưng nó hoạt động!

;This is the *client's* stunnel.conf.
[https]
accept = localhost:9020
connect = your.lan.proxy:80
client = yes
protocol = connect
;protocolHost should be the same as the "accept" for the server
protocolHost = 1.2.3.4:443
;Same CAfile, different cert and key pair
CAfile = ca.crt
cert = client.crt
key = client.key
;VERY IMPORTANT!!! Make sure it's really your server and not a MITM attempt by your local network by making sure that the certificate authority "ca.crt" really signed the server's cert
verify = 2
;More performance tweaks...
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

.

;This is the *server's* stunnel.conf.
[https]
;1.2.3.4 is a publicly-routable, static IP address that can be connected to by your box that's under the firewall
accept = 1.2.3.4:443
;localhost:8118 is an example of where your local forwarding HTTP(S) proxy might reside.
connect = localhost:8118
CAfile = ca.crt
cert = server.crt
key = server.key
;VERY IMPORTANT!!! Without this, anyone in the world can use your public stunnel port as an open proxy!
verify = 2
;Set some timeouts higher for performance reasons
sessionCacheTimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

Khi mọi thứ được cấu hình, kết quả cuối cùng sẽ trông giống như thế này:

1. Trình duyệt web của bạn kết nối với localhost:9020(stunnel) và coi nó như một proxy có thể chấp nhận kết nối HTTP và / hoặc HTTPS.
2. Khi stunnel nhận được kết nối từ trình duyệt của bạn, nó sẽ tiếp cận, thông qua proxy / gateway của tường lửa, để thiết lập phiên TLS với máy chủ từ xa của bạn. Tại thời điểm này, khách hàng của bạn xác minh chứng chỉ PKI của máy chủ của bạn và ngược lại.
3. Khi phiên TLS được thiết lập với máy chủ từ xa của bạn, stunnel sẽ truyền dữ liệu đến từ trình duyệt của bạn, ví dụ: yêu cầu HTTP hoặc yêu cầu đường hầm SSL, thông qua proxy cục bộ và trực tiếp đến máy chủ của bạn. Kênh này được mã hóa, vì vậy mạng cục bộ của bạn không thể biết dữ liệu chứa gì, họ chỉ có thể đoán bằng cách phân tích lưu lượng.
4. Khi stunnelphiên bản đang chạy trên máy chủ của bạn bắt đầu nhận dữ liệu, nó sẽ mở một kết nối tới localhost:8118, ví dụ , đó sẽ là nơi máy chủ proxy HTTP (S) của bạn, trong trường hợp của tôi là Privoxy, đang lắng nghe.
5. Sau đó, Privoxy hoạt động như một máy chủ proxy HTTP chuyển tiếp thông thường và chuyển tiếp các yêu cầu của bạn tới Internet công cộng thông qua ISP của máy chủ.

Số lượng ổ cắm và bộ đệm liên quan khiến phương pháp này có chi phí rất cao, đặc biệt nếu bạn lồng kết nối SSL qua proxy, nhưng có một lợi thế là mạng cục bộ của bạn không có cách nào biết được trang web nào bạn đang truy cập qua SSL. Ý tôi là, nó biết bạn đang truy cập máy chủ của bạn, nhưng ngoài ra, nó không biết bạn đang truy cập Gmail hay SuperUser hay bất cứ điều gì. Và cổng cục bộ của bạn không có cách nào để lọc hoặc chặn bạn.

Tôi đã thử thiết lập này trên máy cục bộ của mình và tôi có thể đảm bảo rằng "proxy hạn chế" sẽ nhận được CONNECT DEBIAN_IP:443 HTTP/1.1, nhưng nó sẽ không thấy bất kỳ chứng chỉ nào, vì vậy tôi không chắc liệu nó có hoạt động không.

Giả sử: Debian của bạn có Apachehoặc Squidthực hiện ủy quyền và máy chủ SSH. Trên PC khách của bạn, bạn cần putty, đây là chương trình không cần quyền quản trị để chạy, không cần cài đặt và có thể chạy từ một ổ đĩa.

Đầu tiên là Debian của bạn:

Hãy SSH của bạn lắng nghe trên cổng 443, chỉ cần thêm (hoặc thay thế cảng hiện tại của bạn) một Port 443ngày /etc/ssh/sshd_configvà cũng cho phép TCP chuyển tiếp (thêm AllowTcpForwarding yesvào tập tin đó)

Định cấu hình Squid hoặc Apache của bạn để thực hiện ủy quyền. Vì điều này sẽ được sử dụng thông qua một đường hầm SSH, nên nó chỉ cần lắng nghe trên giao diện loopback. Trong trường hợp bạn sử dụng Apache:

Listen 127.0.0.1:8080
ProxyRequests On
<Proxy *>
  Order deny,allow
</Proxy>

Máy chủ đã hoàn tất, hãy cấu hình PC khách của bạn:

Trên putty, cấu hình IP công cộng của Debian của bạn như Hostvà 443như cảng. Hãy chắc chắn rằng SSHvẫn được chọn. Thay đổi Connection -> Proxycài đặt, chọn HTTPvà điền vào cài đặt "proxy hạn chế" của bạn. Thay đổi Connectioncài đặt và thiết lập mức giữ 30- 60. Thay đổi thành Connection -> SSH -> Tunnels. Trên source portstablish 8080, và trên Destination, localhost:8080. Để lại Localchọn và nhấn Add. Bạn sẽ thấy trong không gian phía trên một cái gì đó như thế nào L8080 locahost:8080. Thay đổi lại Sessioncài đặt, ghi tên vào hàng đầu tiên Saved sessionsvà lưu tất cả các cài đặt tẻ nhạt này để giúp thiết lập lại kết nối vào những ngày tiếp theo.

Bây giờ bạn có thể thử Openkết nối với Debian của bạn. Nếu bạn thấy lời nhắc của người dùng, chúng tôi chỉ là một bước để hoàn thành việc này. Nếu không ... chúng ta sẽ phải tìm kiếm một cách khác.

Bây giờ, trên Firefox, đặt localhosttại cổng 8080làm proxy của bạn.

Bạn đang ở giữa chừng với việc thiết lập proxy trên máy chủ của mình. Nửa còn lại là SSL trên máy chủ và proxy cục bộ trên máy khách sử dụng putty để kết nối với proxy HTTP hỗ trợ SSL của bạn và đặt Firefox thành proxy mọi thứ thành 127.0.0.1.

Tôi vừa thực hiện một google nhanh chóng cho một thiết lập putty và tìm thấy cái này: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-USE-apache-170/