Redirect SEMUA lalu lintas web melalui TLS tanpa VPN

Asumsi:

Server:

• Saya memiliki server Debian Squeeze, dapat dialihkan di Internet publik, dengan alamat IPv4 statis.
• Saya memiliki akses tidak terbatas untuk memodifikasi perangkat lunak di server.
• Server dapat mendengarkan pada port arbitrer, mengkonfigurasi ulang aturan firewall, pada dasarnya tidak ada batasan pada apa yang dapat dilakukan server.

Klien:

• Saya dapat menjalankan Firefox, program Java, .NET program, dan beberapa executable asli yang tidak memerlukan akses admin pada sistem lokal saya (desktop Windows yang terkunci tanpa hak admin).
• Saya dapat menginstal Addons ke Firefox.
• Saya dapat mendengarkan port apa saja di localhostantarmuka loopback ( ). Jadi, program - program tersebut dapat mengikat ke port lokal dan melakukan I / O jaringan sewenang-wenang, tanpa melalui proxy.
• Semua akses Internet publik disalurkan melalui proksi HTTP terbatas yang memblokir banyak situs, dan melakukan pemeriksaan stateful yang cermat. Pada port 80, ini memungkinkan HTTP eksklusif (tidak ada TLS / SSL). Pada port 443, ini memungkinkan CONNECTSSL / TLS berbasis ke host jarak jauh yang tidak diblokir oleh nama domain / alamat IP.
• Proxy HTTP restriktif tidak melakukan pemeriksaan paket mendalam terhadap koneksi TLS yang diizinkan melalui proxy, dan tidak melakukan serangan Man in the Middle pada koneksi tersebut.
• Saya memiliki akses ke server yang disebutkan di atas, tidak diblokir oleh proxy.

Tujuan:

Saya ingin merutekan semua permintaan HTTP dan HTTPS yang dipancarkan oleh Firefox, melalui server di atas, melalui SSL / TLS.

Catatan lain tentang "Sasaran":

• Bahkan jika situs titik akhir (misalnya, http://superuser.com) tidak menggunakan SSL / TLS ke server saya, saya masih ingin menggunakan SSL / TLS dari klien saya ke server saya , dan meminta server saya melakukan permintaan HTTP - apakah dienkripsi atau tidak - - ke tujuan yang saya inginkan.
• Saya tidak peduli jika server saya melihat lalu lintas SSL "di tempat kosong". Dengan kata lain, saya tidak memerlukan enkripsi SSL end-to-end penuh dari klien lokal saya, sampai ke server jarak jauh, jika server jarak jauh diakses oleh mis https://google.com. Dengan kata lain, saya percaya server menjaga kerahasiaan data saya.
• Saya bersedia menginstal perangkat lunak apa pun atau add-on Firefox yang tidak memerlukan hak admin dan dapat berjalan di Windows 7 32-bit.
• Perangkat lunak open source lebih disukai daripada hak milik, dan freeware lebih disukai daripada perangkat lunak yang membutuhkan biaya lisensi.
• Perangkat lunak yang ada lebih disukai daripada harus membuat kode perangkat lunak baru, meskipun saya bersedia untuk menulis kode jika itu satu-satunya cara.

Saya mencari "solusi" yang dijelaskan secara longgar yang menjelaskan:

• Perangkat lunak apa yang diperlukan pada klien? Jika ada paket perangkat lunak spesifik yang Anda ketahui, beri nama; jika tidak, jelaskan apa yang harus dilakukan oleh perangkat lunak klien .
• Perangkat lunak apa yang diperlukan di server? Jika ada paket perangkat lunak spesifik yang Anda ketahui, beri nama; jika tidak, jelaskan apa yang harus dilakukan oleh perangkat lunak server .
• Jika Anda memberi nama paket perangkat lunak tertentu di atas, jelaskan parameter konfigurasi apa yang diperlukan untuk mengaturnya agar memenuhi tujuan saya.
• Jika karena alasan tertentu Anda yakin ini tidak mungkin , jelaskan alasannya .

Hal-hal yang Saya Sudah Mencoba Itu Tidak Bekerja

• Menginstal squiddi server saya, saya mencoba mengatur proxy HTTP standar sendiri di server saya. Ini tidak berhasil, karena ketika saya meminta situs web di Firefox melalui HTTP biasa, Firefox juga mencoba mengakses server saya melalui HTTP biasa! Ini tidak dapat diterima, karena proxy di jaringan lokal saya tentu saja dapat mengamati dan / atau memblokir lalu lintas HTTP reguler antara klien saya dan server.
• VPN tidak berfungsi , bahkan OpenVPN over TLS tidak mendengarkan pada port 443, karena saya tidak memiliki izin pada komputer lokal untuk menginstal tunadapter jaringan yang dapat melakukan routing layer 3, saya juga tidak bisa melakukan routing layer 2 (misalnya tap). Singkatnya: Saya memerlukan hak admin untuk menginstal OpenVPN, dan bahkan jika saya memiliki hak admin sementara, perusahaan tidak akan terlalu senang jika mereka menemukan itu diinstal. Program Java atau .NET jauh kurang terlihat, terutama ketika tidak diinstal pada Tambah / Hapus Program dan tidak memiliki komponen driver kernel seperti OpenVPN.

Saya menemukan jawabannya. : D Solusi ini memenuhi semua persyaratan saya dan memenuhi semua tujuan saya, dengan sempurna. Kinerja juga tidak terlalu buruk, mengingat tingkat tipuan yang diperlukan untuk mencapai ini.

Jadi, pendekatan umum adalah:

1. Menyiapkan Otoritas Sertifikat (CA) lokal, dan menghasilkan "kunci server" RSA dan "kunci klien" (Saya menggunakan enkripsi 256-bit). Untuk ini, saya menggunakan Easy-RSA versi 3.0.0-rc2.

2. Jalankan sembarang proxy HTTP standar rawa di "Kotak Debian" (server di Internet publik), pastikan untuk mendengarkannya di localhost saja (itu TIDAK boleh diekspos ke Internet publik). Untuk tujuan saya, saya menggunakan Privoxy, tetapi Squidakan bekerja dengan baik. Karena itu hanya mendengarkan di localhost, otentikasi tidak diperlukan (kecuali ada proses yang berjalan pada kotak Anda bahwa Anda tidak percaya, dalam hal ini, Astaga ...)

3. Unduh stunnel dan instal di klien dan server. Proses untuk melakukan ini akan menjadi OS-spesifik; dalam kasus saya, saya memilih untuk mengkompilasi stunnel dari sumber (paranoia ...) untuk Windows, yang merupakan proses yang agak terlibat saya tidak akan detail di sini. Di sisi server, itu tersedia di manajer paket :)

4. Konfigurasi Stunnel pada awalnya cukup menakutkan, tetapi lebih sederhana daripada yang terlihat! Pada dasarnya, di server, Anda memerlukan sesuatu seperti "server's stunnel.conf" di bawah ini. Pada klien, Anda memerlukan sesuatu seperti "klien stunnel.conf" di bawah ini.

5. Mulai Privoksi; mulai stunnel di server, arahkan ke file konfigurasi; mulai stunnel pada klien, arahkan ke file konfigurasi. Benar-benar tidak ada yang istimewa tentang konfigurasi Privoxy; standarnya baik untuk saya.

6. Di Firefox, browser pilihan Anda di sisi klien, atur HTTP dan HTTPS proxy menjadi sama dengan port yang sedang didengarkan stunnel klien Anda - mungkin sesuatu seperti localhost: 8080.

Saya mungkin harus mencatat bahwa jika proxy jaringan lokal Anda menuntut semacam otentikasi, Anda harus meminta stunnel untuk mengautentikasi untuk Anda, atau menggunakan proxy penyadapan lokal lain dan menyatukannya - seperti Firefox -> stunnel -> local otentikasi proxy -> LAN proxy / gateway -> internet -> stunnel server Anda -> privoxy.

Itu banyak menyalin, tetapi berhasil!

;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

Setelah semuanya dikonfigurasi, hasil akhirnya akan terlihat seperti ini:

1. Browser web Anda terhubung ke localhost:9020(stunnel) dan memperlakukannya seperti proxy yang dapat menerima koneksi HTTP dan / atau HTTPS.
2. Setelah stunnel mendapatkan koneksi dari browser Anda, ia menjangkau, melalui proxy / gateway firewall Anda, untuk membuat sesi TLS dengan server jauh Anda. Pada titik ini, klien Anda memverifikasi sertifikat PKI server Anda, dan sebaliknya.
3. Setelah sesi TLS dibuat dengan server jarak jauh Anda, stunnel meneruskan data yang berasal dari browser Anda, misalnya permintaan HTTP atau permintaan terowongan SSL, melalui proxy lokal dan langsung ke server Anda. Saluran ini dienkripsi, sehingga jaringan lokal Anda tidak dapat mengetahui apa yang berisi data, mereka hanya bisa menebak dengan melakukan analisis lalu lintas.
4. Setelah stunnelinstance berjalan di server Anda mulai menerima data, itu membuka koneksi ke misalnya localhost:8118, yang akan menjadi tempat server proxy HTTP (S) Anda, dalam kasus saya Privoxy, mendengarkan.
5. Privoxy kemudian bertindak seperti server proxy HTTP penerusan normal, dan meneruskan permintaan Anda ke Internet publik melalui ISP server.

Jumlah soket dan buffer yang terlibat membuat metode ini sangat mahal, terutama jika Anda membuat koneksi SSL melalui proxy, tetapi memiliki keuntungan bahwa jaringan lokal Anda tidak memiliki cara untuk mengetahui situs mana yang Anda kunjungi melalui SSL. Maksud saya, ia tahu Anda mengunjungi server Anda, tetapi selain itu, ia tidak tahu apakah Anda mengunjungi Gmail atau SuperUser atau apa pun. Dan gateway lokal Anda tidak memiliki cara untuk memfilter atau memblokir Anda.

Saya telah mencoba pengaturan ini di mesin lokal saya, dan saya dapat memastikan bahwa "proxy restriktif" akan mendapatkan CONNECT DEBIAN_IP:443 HTTP/1.1, tetapi tidak akan melihat sertifikat apa pun, jadi saya tidak yakin apakah ini akan berhasil.

Mari kita asumsikan: Debian Anda memiliki Apacheatau Squiduntuk melakukan proxy dan server SSH. Pada PC klien Anda, Anda perlu putty, yang merupakan program yang tidak memerlukan hak admin untuk dijalankan, tidak perlu untuk instalasi dan bisa dijalankan dari pendrive.

Pertama Debian Anda:

Membuat SSH Anda mendengarkan pada port 443, hanya menambahkan (atau mengganti port Anda saat ini) yang Port 443pada /etc/ssh/sshd_configdan juga memungkinkan TCP forwarding (tambahkan AllowTcpForwarding yespada file itu)

Konfigurasikan Squid atau Apache Anda untuk melakukan proxy. Karena ini akan digunakan melalui terowongan SSH, itu hanya perlu mendengarkan pada antarmuka loopback. Jika Anda menggunakan Apache:

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

Server selesai, mari atur PC klien Anda:

Pada dempul, konfigurasikan IP publik Debian Anda sebagai Hostdan 443sebagai port. Pastikan SSHmasih dipilih. Ubah ke Connection -> Proxypengaturan, pilih HTTPdan isi pengaturan "proxy restriktif" Anda. Ubah ke Connectionpengaturan dan buat keepalive dari 30- 60. Ubah ke Connection -> SSH -> Tunnels. Pada source portstablish 8080, dan pada Destination, localhost:8080. Biarkan yang Localdipilih dan tekan Add. Anda harus melihat di ruang di atas sesuatu seperti L8080 locahost:8080. Ubah kembali ke Sessionpengaturan, tulis nama pada baris pertama Saved sessionsdan simpan semua pengaturan yang membosankan ini untuk membantu membangun kembali koneksi pada hari-hari berikutnya.

Sekarang Anda dapat mencoba Openkoneksi ke Debian Anda. Jika Anda melihat permintaan pengguna, kami hanya selangkah dari penyelesaian dengan ini. Jika tidak ... kita harus mencari cara lain.

Sekarang, di Firefox, atur localhostdi port 8080sebagai proxy Anda.

Anda berada di tengah jalan dengan menyiapkan proxy di server Anda. Setengah lainnya adalah SSL di server, dan proksi lokal di klien menggunakan dempul untuk terhubung ke proksi HTTP yang mendukung SSL Anda, dan mengatur Firefox untuk proksi semuanya menjadi 127.0.0.1.

Saya baru saja melakukan google cepat untuk pengaturan dempul dan menemukan ini: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/