HTTPS पर SSH

मूल लेख ↗ Hacker News चर्चा ↗

HTTPS पर SSH, उन नेटवर्कों को बायपास करने का एक व्यावहारिक तरीका बन रहा है जो अधिकांश outbound ports और protocols को ब्लॉक करते हैं लेकिन web traffic को 80/443 पर अनुमति देते हैं। टिप्पणियों में SSH को सीधे पोर्ट 443 पर रखने, HTTP CONNECT, WebSockets, या HTTPS जैसा दिखने वाले VPNs के जरिए tunneling करने, और sslh, chisel, या Cloudflare Tunnel जैसे tools का उपयोग करने जैसे approaches की तुलना की गई है, जहाँ setup की आसानी और deep packet inspection के प्रतिरोध के बीच संतुलन देखा जाता है। thread व्यापक protocol ossification की चिंताओं को भी छूता है, जहाँ increasingly aggressive middleboxes सब कुछ HTTPS के ऊपर ले जाने को मजबूर करते हैं, और client TLS certificates तथा passkeys जैसे alternative authentication methods की usability और privacy trade-offs पर भी चर्चा करता है.

HTTPS पर SSH बनाम सिर्फ़ पोर्ट बदलना

  • कई टिप्पणियाँ बताती हैं कि SSH को बस पोर्ट 80/443 पर चलाने से अक्सर बुनियादी फ़ायरवॉल्स को बायपास किया जा सकता है, और बहुत से लोग इसे व्यवहार में करते हैं।
  • अन्य लोग ज़ोर देते हैं कि आधुनिक नेटवर्क डीप पैकेट इन्स्पेक्शन (DPI) का उपयोग करते हैं, इसलिए 80/443 पर SSH को SSH बैनर से बहुत आसानी से पहचाना और ब्लॉक किया जा सकता है।
  • SSH-over-HTTPS का आकर्षण DPI-प्रतिरोध और सामान्य वेब ट्रैफ़िक के साथ पोर्ट 443 साझा करना है, न कि SSH के लिए अलग IP/पोर्ट समर्पित करना।

फ़ायरवॉल नीतियाँ और “सुरक्षा”

  • कई नेटवर्क सभी outbound पोर्ट्स को 80/443 को छोड़कर ब्लॉक करते हैं, और कभी-कभी कस्टम CAs के साथ HTTPS का MITM भी करते हैं।
  • इसके लिए दिए गए कारण सामान्य “security best practices” होते हैं, अक्सर किसी स्पष्ट threat model के बिना।
  • इससे उपयोगकर्ता पूरी Internet functionality वापस पाने के लिए सब कुछ HTTPS के ऊपर tunnel करते हैं (SSH, VPNs, अन्य protocols)।

Client identity और HTTPS client certificates

  • कुछ लोग ब्राउज़रों में मूल रूप से “HTTP over SSH”-style identity (public-key-based) चाहते हैं।
  • Passkeys को application-layer का हिस्सा माना जाता है और उन्हें समकक्ष नहीं समझा जाता।
  • HTTPS client certificates को एक उम्मीदवार के रूप में उठाया गया है, लेकिन उनमें समस्याएँ हैं:
    • खराब UX: बार-बार popups, awkward account switching, और अस्पष्ट TLS-layer errors।
    • Fingerprinting का जोखिम: सिर्फ certificates का मौजूद होना tracking के लिए दुरुपयोग किया जा सकता है।
    • Platform quirks: macOS keychain constraints, system-wide CA install, 1‑year cert limits.

Tools और tunneling variants

  • कई existing tools और patterns का उल्लेख है:
    • एक ही पोर्ट पर SSH/HTTPS को demux करना: sslh, httpssh, SNI/ALPN या heuristic inspection के साथ HAProxy।
    • HTTP CONNECT / HTTP tunnel tools: corkscrew, httptunnel; custom socat patches या websocat के जरिए WebSockets पर SSH।
    • HTTPS/TLS पर VPN जैसे solutions: SSL VPNs (जैसे AnyConnect/OpenConnect), SSTP, “allowed” ports पर WireGuard, Cloudflare Tunnel, Tailscale, chisel, Ligolo-ng।
    • Browser-based shells: उन environments के लिए shellinabox जहाँ SSH clients उपलब्ध नहीं हैं।

सार्वभौमिक substrate के रूप में HTTPS

  • कई टिप्पणियों में यह रुझान देखा जाता है कि middlebox discrimination के कारण arbitrary protocols को HTTPS (और QUIC/HTTP3) के ऊपर चलाया जा रहा है।
  • gRPC और similar RPC-over-HTTP2 को “HTTP as the new TCP” के उदाहरण के रूप में उद्धृत किया गया है।
  • protocol और provider centralization (सब कुछ 443 पर, अक्सर बड़े CDNs के पीछे) को लेकर चिंताएँ उठती हैं, लेकिन अन्य लोग नोट करते हैं कि इससे विशिष्ट content को ब्लॉक करना कठिन हो जाता है।