In che modo il tunneling SSH tramite Proxytunnel / HTTPS è diverso dal farlo tramite SSL con Stunnel?

TL; DR - Penso che il tuo problema non sia affatto collegato a SSL, ma stai provando a utilizzare un server proxy senza le intestazioni proxy.

So, if I use stunnel to create an SSL tunnel, and then pass HTTP traffic through it, would it be the same as using HTTPS normally?

Sì. Usiamo http su stunnel al lavoro per parlare con un https-server. Questa è una soluzione alternativa per un bug nel client https Java che non è in grado di parlare con un https-server ISS in alcune situazioni.

Then, if a proxy/firewall sees only an SSL/TLS connection with encrypted traffic, how could it know the traffic isn't HTTP?

Un normale proxy / firewall non è in grado di dire cosa c'è dentro.

Esistono decodifica di https-proxy . Per farli funzionare, devono ingannare il cliente ad accettare la propria chiave pubblica invece della chiave pubblica del server reale. In https la chiave pubblica fa parte di un certificato che contiene informazioni sul nome del server. I certificati sono solitamente firmati dalle CA, che i browser conoscono come affidabili.

Il server proxy deve falsificare il certificato del server per consentire al client di utilizzare la propria chiave pubblica. Un client normale visualizzerà un avviso sul certificato non valido. Ma il proxy può firmare i certificati falsi con la propria CA. E il amministratore può installare il CA come attendibile sui client .

In theory, I think that if the proxy/firewall can't notice the difference, one should be able to tunnel SSH traffic through an SSL/TLS connection (created with stunnel) instead of HTTP.

Il metodo comune per eseguire il tunneling di SSH funziona anche senza il layer SSL su https-proxy non decrittografati.

However, in practice, I have seen this not work - the proxy/firewall appears able to detect that it is not HTTPS traffic.

O stai facendo qualcosa di sbagliato, o sei dietro un decriptatore https come spiegato sopra.

I think this is why Proxytunnel is used, but I don't understand what Proxytunnel does differently to avoid detection. Does it just create fake HTTP headers?

Devi distinguere tra un firewall e un proxy qui: Se c'è solo un firewall di rete puoi collegarti normalmente all'indirizzo IP di destinazione sulla porta 443. Ma se c'è un proxy, è necessario connettersi all'indirizzo IP e alla porta del proxy e quindi dirgli di connettersi al target usando il protocollo http. Il comando è: CONNECT target:port HTTP/1.1 <cr><lf>

Nella maggior parte dei casi i server https-proxy consentono la connessione a qualsiasi indirizzo IP ma solo alla porta 443. Dopo aver inviato la stringa di connessione, si ottiene un'intestazione di risposta http. Su un normale proxy https qualsiasi ulteriore informazione, viene inoltrata come è in qualsiasi direzione. Quindi puoi parlare qualsiasi protocollo tu voglia. Usando ssh nativamente da qui in poi funziona.

In teoria un firewall o un proxy stupido può impedire questo tunneling nativo rilevando traffico non SSL. Ma questo è molto raro. Solo un proxy di decrittografia https sarà in grado di prevenire efficacemente questo tipo di tunnel.

Se si esegue HTTP alla porta del server di un'istanza stunnel:

client <--- TCP ---> stunnel <--- TCP ---> server
                             <--- TLS --->
       <------------- HTTP -------------->

sarà quasi esattamente come utilizzare HTTPS, ma non completamente perché il client vede ancora se stesso come se utilizzasse HTTP su TCP. Ad esempio, un browser non visualizzerà "Sicuro" nella barra degli indirizzi e il codice Javascript in esecuzione nel browser potrebbe rifiutarsi di fare le cose se la connessione non è HTTPS.

Per il resto della tua domanda, devi capire esattamente cosa sta succedendo con il "firewall" o il "proxy" che stai usando; ci sono un certo numero di tecniche diverse che può essere utilizzato per gestire la connessione che consentirà o impedirà determinate tecniche quando lo si utilizza.

1. Connessione TCP diretta

Se stai effettuando una connessione TCP che termina sull'host remoto (diagramma sopra), anche se è stato modificato in qualche modo (ad esempio, gli indirizzi modificati tramite NAT) e hai impostato una connessione TLS su quella connessione TCP, i router intermedi non saranno in grado di vedere nessuno del traffico oltre la quantità di esso, gli indirizzi IP e le porte TCP e il fatto che sia TLS. Un firewall a livello IP può essere configurato per disabilitare le connessioni a porte diverse da 443 o eliminare connessioni a 443 se vede che non sono TLS. Potrebbe anche connettersi prima alla porta stessa per vedere se il server sembra eseguire HTTP / TLS su quella porta.

2. Proxy HTTP CONNECT

Se stai utilizzando un proxy HTTP utilizzando il verbo CONNECT , come Proxytunnel , ci sono due connessioni TCP coinvolte ma si fa una connessione TLS su di loro:

client <---- TCP 1 ----> proxy <---- TCP 2 ----> server
                        CONNECT
      <------------------ TLS ---------------->

Stai ancora negoziando TLS con il server reale dall'altra parte e la situazione è praticamente la stessa del numero 1 sopra. Non è necessario eseguire TLS tramite le connessioni TCP, in realtà; potresti semplicemente CONNECT server.mydom.com:22 e iniziare a parlare di SSH su quella connessione se il proxy non rifiuta quella richiesta. Alcune persone hanno server SSH in ascolto sulla porta 443 esattamente per questo scopo. Se il proxy è abbastanza sofisticato da controllare il protocollo in uso, potrebbe disconnetterti se vede che non hai eseguito una configurazione TLS standard, anche se una volta che TLS è attivo non può vedere esattamente cosa sta succedendo in quella connessione .

3. MITM

Alcune organizzazioni effettuano attacchi man-in-the-middle sulle connessioni HTTPS (a volte più educatamente chiamate "intercettazione SSL"). Quando tenti di connetterti al server remoto, tramite una connessione TCP diretta o un proxy come in uno dei casi precedenti, un dispositivo di rete fa finta che sia il server remoto.

client <---- TCP 1 ----> MITM <---- TCP 2 ----> server
       <---- TLS 1 ---->      <---- TLS 2 ---->
       <---------------- HTTP ---------------->

Il tuo browser web tenta di eseguire l'installazione TLS, controllando il certificato e lo convaliderà non perché è il vero certificato, ma perché il dispositivo ha generato un certificato con firma di una CA privata (autorità di certificazione) e il reparto IT ha anche modificato elenco di certificati nel browser o nel sistema operativo per considerare attendibile tale CA. (Si può spesso dire che questo sta accadendo provando la stessa connessione con un altro programma che usa una lista di certificati diversa senza quel certificato, come Firefox se lo si scarica in modo indipendente.) Si dispone di una connessione sicura al dispositivo MITM, ma sta decodificando tutto e ricodificandolo per un'altra connessione sicura separata al server quando inoltra i dati.

In questo caso, anche se pensi di parlare con il server remoto, in realtà stai parlando in modo sicuro solo con il proxy che ha accesso completo a tutti i dati sulla connessione e può vederlo e modificarlo a suo piacimento.