Je tam malej rozdíl, je potřeba do toho streamu přihodit na začátek to CONNECT kam:port HTTP/1.1\r\n\r\n a v opačným směru tomu sežrat 200 CONNECTED\r\n\r\n, a jde tím protáhnout cokoli tcp.
Dá se to udělat třeba injectnutou librarkou, která se pověsí na connect() pro existující binárku, proti tomu (na localhost) bindnutému ssh tunelu je to maličko složitější, tam stačí se connectit na ten přesměrovanej localhost.
Když použijete tunel skrze SSH, funguje to tak, že se nejprve ustaví šifrované SSH spojení s tunelem, a pak se tím tunelem protáhne spojení jiného protokolu, třeba RDP. Dá se to dělat dvěma různými způsoby – buď si to SSH spojení umí vytvořit přímo aplikace, kterou používáte pro RDP (případně skrze vloženou knihovnu); nebo to SSH spojení s tunelem vytvoříte někde mimo, a aplikace vytvářející SSH tunel vytvoří někde naslouchající port, a veškerý provoz, který je směrován na ten naslouchající port, pošle skrze ten SSH tunel na druhou stranu. Tohle umí třeba OpenSSH klient. RDP klient pak nemusí umět nic speciálního – prostě se připojí na ten naslouchající port, tj. lokální konec toho tunelu. Jako kdyby tam byl RDP server. Jenže tam není RDP server, ale ústí toho tunelu, který na druhém konci směřuje na nějaký RDP server.
No a úplně stejně to funguje s tím HTTP CONNECT. Nejprve ustavíte HTTP (dnes spíš HTTPS) spojení, v něm se zavolá ten CONNECT – a pak všechna data posílaná do tohoto spojení projdou tím tunelem. Takže opět existují stejné dvě možnosti – buď si RDP klient umí ten HTTP/S CONNECT tunel vytvořit sám, nebo ho vytvoříte někde vedle a RDP klienta nasměrujete na lokální ústí (nebo spíš vstup) do toho tunelu.