Koneksi SSH melalui HTTPS

 (trofi.github.io)
3 poin oleh GN⁺ 2023-12-25 | 1 komentar | Bagikan ke WhatsApp
  • Pada jaringan terbatas, meskipun port SSH diblokir, jalur akses jarak jauh dapat dibuat dengan port HTTPS 443 dan metode CONNECT
  • Server membuka CONNECT dengan mod_proxy_connect milik apache2, tetapi hanya mengizinkan target ssh-server:22 untuk mempersempit cakupan proxy
  • Klien menghubungkan ProxyCommand OpenSSH dengan socat, dan pada HTTPS skrip mengirim header CONNECT secara langsung
  • Beberapa firewall atau httpd dapat menutup koneksi yang menganggur, sehingga ServerAliveInterval 30 membantu menjaga sesi tetap hidup
  • Cara ini mengenkapsulasi SSH di dalam TLS sehingga lebih mudah menghindari pemblokiran, tetapi masih menyisakan beban enkripsi ganda dan konfigurasi klien

Membuat jalur koneksi SSH di jaringan terbatas

  • Di lingkungan Wi-Fi rumah sakit, sebagian besar jenis koneksi diblokir, dan umumnya hanya TCP 80 untuk HTTP serta TCP 443 untuk HTTPS yang diizinkan
  • UDP 53 untuk DNS dan TCP 853 untuk DoT tampaknya berfungsi untuk penyedia DNS yang dikenal luas
  • SSH sepenuhnya diblokir pada TCP 22 dan sebagian besar port kustom
  • Karena ada koneksi alternatif GSM yang dapat dipakai untuk mengonfigurasi ulang server jarak jauh, berbagai metode bypass bisa diuji

Berbagi satu port dan enkapsulasi protokol

  • Ada cara untuk menerima SSH dan HTTPS bersama-sama pada satu port lalu membaginya secara transparan
    • sslh project memperkirakan protokol dengan heuristik lalu mengarahkan ulang ke backend sebenarnya seperti SSH, HTTPS, atau protokol yang didukung
    • Keuntungannya, klien ssh tidak memerlukan konfigurasi khusus dan cukup menentukan port non-default
    • Kekurangannya, perlu menyiapkan layanan tambahan, HTTPS juga harus melewati sslh, dan alamat asal koneksi tersamarkan di backend sehingga pencatatan log bisa merepotkan
  • Pilihan lain adalah sepenuhnya mengenkapsulasi satu protokol di dalam protokol lain
    • ProxyCommand OpenSSH memungkinkan pengguna menentukan sarana transport yang akan digunakan protokol ssh
    • Karena SSH dibungkus di dalam stream lain tanpa heuristik, perangkat lunak DPI mungkin lebih sulit memblokirnya
    • HTTPS itu sendiri tidak dialihkan atau terdampak
    • Namun, kinerja dapat menurun karena enkripsi ganda, dan konfigurasi klien diperlukan

Konfigurasi SSH over HTTP

  • Pertama, dicoba metode melewatkan SSH melalui HTTP
  • Konfigurasi apache2 di sisi server memuat mod_proxy_connect dan mengizinkan CONNECT ke port 22 dengan AllowCONNECT 22
  • <Proxy *> pada dasarnya menolak semuanya, dan hanya <Proxy ssh-server> yang diizinkan untuk membatasi target ke ssh-server:22
  • .ssh/config di sisi klien menggunakan PROXY:http-server:%h:%p,proxyport=80 milik socat pada ProxyCommand
  • Dengan konfigurasi ini, menjalankan $ ssh ssh-via-http memungkinkan koneksi ke SSH melalui port 80
  • ServerAliveInterval 30 mengirim probe secara berkala untuk menghindari koneksi HTTP yang menganggur ditutup diam-diam di jalur perantara
  • httpd bawaan menggunakan TimeOut 60, yang menutup tunnel jika tidak ada input/output selama 60 detik

Konfigurasi SSH over HTTPS

  • socat ternyata tidak mendukung proxy HTTPS melalui metode CONNECT dan hanya mendukung HTTP
  • Sebagai gantinya, digunakan fitur enkapsulasi TLS milik socat, sementara permintaan berbasis CONNECT diimplementasikan langsung dalam skrip
  • ~/.ssh/https-tunnel.bash bekerja dengan alur berikut
    • Terlebih dahulu mencetak header CONNECT ssh-server:22 HTTP/1.1 dan Host: ssh-server
    • Setelah itu, menyambungkan input standar apa adanya
    • Seluruh stream diteruskan ke socat - "SSL:$3:$4" untuk membuat koneksi TLS
  • Di .ssh/config, ProxyCommand ~/.ssh/https-tunnel.bash ditetapkan untuk Host ssh-via-https
  • Saat $ ssh ssh-via-https dijalankan, koneksi ke ssh-server berhasil melalui tunnel HTTPS seperti yang diharapkan

Hal yang perlu diperhatikan saat operasi

  • Di lingkungan tempat HTTPS diizinkan secara luas, data dapat dikirim melewati perangkat perantara yang sangat membatasi
  • Metode CONNECT mungkin terlihat seperti jejak lama, tetapi berguna untuk membungkus stream payload TCP arbitrer di dalam stream host TLS
  • ServerAliveInterval membantu mempertahankan koneksi OpenSSH ketika lapisan transport di bawahnya tidak ramah terhadap koneksi menganggur
  • Variasi konfigurasi nginx tersedia di CONNECT passthrough on nginx

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-25
Komentar Hacker News

  • Bagian tulisan yang mengatakan, “HTTPS ada di mana-mana sehingga bahkan perangkat perantara yang sangat membatasi pun dapat meloloskan data” pada dasarnya menjelaskan alasan mengapa hampir semua protokol VPN proprietari, yang disebut “SSL VPN”, mengimplementasikan mode membuka terowongan lewat HTTPS
    Walaupun bukan perilaku default, setidaknya mode ini disediakan sebagai jalur alternatif, dengan tujuan memastikan ada mode yang bisa berfungsi di hampir koneksi internet mana pun di seluruh dunia
    Saya adalah salah satu pengembang utama https://gitlab.com/openconnect/openconnect, yang mengimplementasikan berbagai protokol VPN berbasis TLS, dan juga membuat https://github.com/dlenski/what-vpn yang mendeteksi dan mengidentifikasi lebih banyak jenis server VPN berbasis TLS

    • Sangat disayangkan bahwa upaya untuk membatasi kegunaan koneksi secara kasar membuat fungsi asli port jadi sulit dipakai sebagaimana mestinya

  • Dulu penyedia internet Belanda XS4ALL menyediakan fitur persis seperti ini
    Mereka membuka akses SSH di port 80, dan ini beberapa kali sangat membantu saat sedang bepergian ketika WiFi hotel memblokir semua port selain 80

  • Sering kali ada pilihan ketiga: menjalankan SSH di port 80 atau 443 pada host lain, lalu menggunakan ProxyJump dari sana ke tujuan akhir
    Atau Anda juga bisa membuka SOCKS melalui host itu untuk mendapatkan koneksi internet yang secara umum lebih sedikit difilter
    Saya memakai SOCKS, dan juga meneruskan DNS berbasis TLS melalui port forwarding pada koneksi SSH
    Beberapa tahun lalu saat pertama kali menyiapkan proxy SOCKS dan cukup sering memakai WiFi, saya belum pernah melihat tempat yang memeriksa lebih dari sekadar port, tetapi perangkat seperti itu memang ada dan mungkin sekarang lebih umum

    • Saat kelas 1 SMA saya baru mulai self-hosting, dan sekolah memblokir situs web tetapi sama sekali tidak melakukan pemblokiran port
      Jadi saya cukup SSH ke server saya dan memakainya seperti biasa
      Belakangan saya membuat arsip file Windows .iso, mengunduhnya ke laptop lalu mengunggahnya ke server dengan scp; tampaknya penggunaan puluhan GB gabungan upload dan download di port non-80/443 cukup untuk memicu pemeriksaan lalu lintas, sehingga sekitar jam makan siang tim IT memblokir port 22
      Tetapi mereka tidak memblokir port lain, jadi saya memindahkan SSH pada port forwarding ke 443 dan terus memakainya
      Setelah itu tim IT sekolah menyadari saya memakai SSH di 443 dan menambahkan analisis lalu lintas dasar untuk memblokir SSH di 80/443, tetapi semua port lain tetap terbuka
      Pada akhirnya mereka memblokir server saya di tingkat IP, tetapi semua IP lain tetap terbuka
      Saya bisa melewatinya dengan VPS dan ProxyJump, tetapi karena ini program SMA early college, setelah kelas 2 saya hampir tidak pernah lagi berada di sekolah jadi rasanya tidak terlalu layak diupayakan
      Saat berikutnya saya ke sana, saya ingin mencoba hanya untuk membuktikan bahwa itu bisa dilakukan, dan kalau mereka memblokir SSH di semua port, saya bisa menjalankan SSH di atas HTTPS pada VPS
      Setelah lulus, saya juga ingin melihat lagi sejauh mana ini masih memungkinkan di WiFi tamu

  • Ini memang sedikit promosi terang-terangan, tetapi di Adaptive [1] kami membangun infrastruktur keamanan data
    Salah satu produk kami meneruskan SSH dan berbagai protokol lain di atas HTTP/3 sehingga pengguna dapat terhubung ke database, server, dan sumber daya lain melalui satu port outbound
    Mirip keluarga Ngrok, tetapi bisa di-self-host, dan dapat mendukung akses tanpa kata sandi atau diberi kredensial sementara serta perlindungan maker-checker
    [1] https://adaptive.live/

  • Dalam praktiknya, hanya dengan membuat openssh mendengarkan di port 443 saja sudah cukup untuk melewati sebagian besar firewall

  • Bagus. Anehnya, saya belum pernah memikirkan metode CONNECT sebagai sesuatu seperti reverse proxy, bukan forward proxy
    Namun dalam kasus saya, CONNECT saja tidak cukup, jadi saya memakai SSH di atas WebSocket untuk menembus proxy kantor
    Proxy itu memeriksa koneksi HTTPS dengan CA kustom milik perusahaan
    Saya memodifikasi socat agar server SSH saya bisa disajikan sebagai WebSocket melalui Apache, lalu di sisi klien saya memakainya bersama ProxyCommand milik OpenSSH
    Saya terus berpikir untuk mengunggah patch itu, tetapi ada juga pilihan lain seperti websocat

    • Mungkin itu sebabnya banyak proxy atau firewall perusahaan memblokir WebSocket secara default
    • Kedengarannya seperti tanpa sengaja membuat ulang huproxy

  • Hampir 20 tahun lalu saya memakai corkscrew[0], alat yang melakukan persis hal ini, untuk menjebol firewall kantor
    Implementasi mandirinya dan artikelnya rapi
    0: https://github.com/bryanpkc/corkscrew

    • Sejauh pemahaman saya, corkscrew hanya bekerja dalam kondisi tertentu: Anda harus berada di belakang proxy HTTP, dan proxy HTTP itu harus mendukung metode CONNECT
      Saat saya mengerjakan kontrak singkat sekitar 20 tahun lalu, syarat pertama terpenuhi tetapi syarat kedua tidak
      Untungnya ada alat yang bisa dipakai bahkan dalam kasus seperti ini, meski tentu perlu konfigurasi di sisi server
      https://github.com/larsbrinkhoff/httptunnel

  • Secara umum, tunneling melalui HTTP/2 tampaknya merupakan pilihan yang baik
    Ada gRPC[1], protokol remote procedure call yang dibangun di atas HTTP/2
    HTTP/2 unggul untuk multipleksing karena memanfaatkan satu koneksi TCP untuk mengirim dan menerima banyak struktur data secara bersamaan
    Namun, karena QUIC sendiri sudah menyediakan multipleksing, mungkin tidak ada alasan untuk memakai HTTP/3
    Ke depannya, karena para pembuat perangkat perantara tidak akan berhenti melakukan diskriminasi, sepertinya sebagian besar komunikasi akan berjalan di atas HTTP/2 terenkripsi dan QUIC
    Untuk mengurangi active probing[2], mungkin kita perlu menyajikan konten HTTP/2·HTTP/3 yang acak, mungkin bahkan dihasilkan AI
    [1] <https://grpc.io>
    [2] <https://blog.torproject.org/learning-more-about-gfws-active-...>

    • Saya kurang paham mengapa perlu menambahkan lagi protokol remote procedure call di atas HTTP
      HTTP sendiri sudah merupakan protokol request/response, dan pada dasarnya bisa dipakai untuk remote procedure call
      Entah HTTP 1, 2, atau 3, tampaknya tidak banyak bedanya
      Evolusi protokol itu sendiri juga agak meragukan, dan ada sisi bahwa ia dirancang untuk memanfaatkan hal-hal yang tidak diperlukan dalam lingkungan remote procedure call
      Pada dasarnya, ia lebih dekat dengan sesuatu yang dirancang untuk internet publik daripada untuk layanan lokal
    • Untuk SSH, hanya ada satu koneksi, dan sebenarnya SSH sudah mengimplementasikan multipleksing sendiri, jadi keunggulan HTTP/2 tidak terlalu terlihat
    • HTTP/2 tetap TCP, jadi masih mengalami TCP head-of-line blocking
      HTTP/3 berjalan di atas QUIC

  • Sebaliknya, saya lebih suka HTTP di atas SSH
    Setengah bercanda, tetapi akan bagus kalau browser punya manajemen identitas setara SSH bawaan
    Saat pertama kali membaca hobo, usulan autentikasi HTTP dengan kunci publik, saya sempat antusias, lalu sadar tidak ada implementasi server maupun implementasi klien browser
    Ada implementasi JavaScript, tetapi bukan dalam bentuk yang saya inginkan

    • ssh -D “*:8080” host
      Perintah ini menjalankan proxy SOCKS di port 8080
      Saya selalu memakainya di Firefox, dan kerjanya seperti VPN jadul
      Praktis untuk hal-hal yang meragukan, tetapi juga saya pakai untuk mengakses dasbor rmq di jaringan privat AWS
    • Bagaimana dengan sertifikat klien HTTPS?
      https://techcommunity.microsoft.com/t5/iis-support-blog/clie...
      Saya tidak cukup paham detailnya untuk tahu apakah ini memenuhi kebutuhan, tetapi pernah memakainya untuk autentikasi server saat kuliah
    • Bukankah yang Anda maksud itu passkey?
    • Andai browser bisa melakukan ssh://google.com
    • Kalau terlewat minggu lalu, ada artikel dengan arah serupa: SSH3, SSHv2 yang menggunakan HTTP/3 dan QUIC
      https://news.ycombinator.com/item?id=38664729

  • Kenapa sslh tidak lebih disukai?
    Ia dapat mendeteksi HTTP, TLS/SSL (termasuk SNI dan ALPN), SSH, OpenVPN, tinc, XMPP, SOCKS5, dan bahkan bisa mengenali protokol lain yang dapat diperiksa dengan regex
    Kegunaan tipikalnya adalah menyajikan beberapa layanan sekaligus di port 443
    Misalnya, Anda bisa tetap terhubung ke SSH dari dalam firewall kantor sambil terus menyajikan HTTPS di port yang sama
    https://www.rutschle.net/tech/sslh/README.html

    • Setengah bagian awal artikel membahas soal memilih sslh atau enkapsulasi penuh
      Alasan memilih enkapsulasi penuh tampaknya karena ada satu layanan yang tidak perlu dikonfigurasi, server HTTP yang menangani koneksi membuat alamat jarak jauh di log menjadi akurat, dan mungkin juga karena semangat hacker lebih menyukai solusi baru daripada solusi yang sudah ada