Solo IP su HTTP GET

Do you think that's possible or are aware of software that's capable of doing this? Or maybe another way to accomplish unrestricted internet access under these cirumstances?

Se hai il controllo di un server raggiungibile dal servizio che hai menzionato, potresti creare il tuo tunnel, perché

• puoi inviare dati attraverso il tunnel al server (tramite l'URL della richiesta)
• e puoi ricevere i dati attraverso il tunnel dal server (tramite la risposta)

Questo significa che tutto ciò che devi fare è scrivere te stesso ai gestori locali e remoti appropriati per tradurre tra il tuo protocollo tunnel e la richiesta / risposta HTTP.

Non sono a conoscenza di alcun software esistente che funzioni con le tue restrizioni specifiche (il link è probabilmente al di fuori delle tue restrizioni ), ma è possibile scrivere qualcosa di simile e per aiutarti a eludere le politiche di sicurezza specifiche sarebbe comunque al di fuori dello scopo di questo forum.

E ricorda sempre che le politiche di sicurezza sono spesso lì per proteggere qualcosa e che potresti metterti nei guai quando cerchi di eludere queste politiche, come perdere il lavoro o addirittura essere accusato di tentativi di hacking. E tali tunnel possono essere rilevati perché mostrano un comportamento di utilizzo anormale.

Il problema principale con l'IP tunneling nelle richieste HTTP GET è che HTTP è un protocollo client-driven: il client parla sempre per primo, e il server non può inviare nulla al client come risposta a una richiesta. In puro TCP / IP, entrambe le parti devono essere in grado di parlare in qualsiasi momento che desiderano.

I due metodi principali per risolvere questo problema sono:

1. Polling . Il client invia richieste ad intervalli molto regolari, diciamo almeno una volta o due al secondo. Il server risponde con una porzione di dati o un messaggio che dice "nulla da restituire a quel punto".

2. stallo . Il client invia una richiesta, ma il server non risponde finché non ha effettivamente alcuni dati da inviare al client, o è trascorso un certo periodo di tempo. In entrambi i casi, quando ha ricevuto una risposta, il client invia immediatamente una nuova richiesta, per il prossimo blocco di dati.

Il meccanismo di stallo è più discreto e richiede meno risorse; tuttavia, è più complesso da configurare e utilizzare, in particolare perché il client richiede quindi due canali, per l'invio e la ricezione di pacchetti incapsulati. I prodotti Anyterm del terminale sul Web utilizzano il meccanismo di stallo; tuttavia, lo fa con XmlHttpRequest, che invia richieste POST, non GET. Vedi anche il protocollo BOSH , che usa lo stesso principio, spiegato in maggiori dettagli nella sezione 4.

Il concetto può essere applicato alle richieste HTTP GET; probabilmente dovresti codificare i dati in uscita nel percorso di destinazione, o come intestazione personalizzata, perché le richieste HTTP GET non dovrebbero avere corpi non vuoti (lo standard HTTP lo consente, ma non dovrebbe accadere nella pratica, e credo che renderebbe il firewall molto sospetto).

Non conosco nessuno strumento esistente, ma questo è un buon esercizio di programmazione.

Ovviamente, superare la configurazione del firewall è solo una parte del soggetto. Presumo che chiunque applichi restrizioni così pesanti alle richieste Web installerà anche alcuni dispositivi di monitoraggio per essere avvisati di attività di rete insolite e qualsiasi tunneling dovrebbe attivare tale sistema.

Se i servizi di fronting capaci non sono bloccati (reti di Content Delivery come Google Apps Engine, Amazon CloudFront, Azure CDN, servizi che servono il contenuto di un gran numero di siti di solito difficili da bloccare), puoi incapsulare un Richiesta GET HTTP in una richiesta HTTP GET a questi servizi.

Guarda il plugin di trasporto Meek che Tor ha e che implementa questa idea. Puoi anche trovare ulteriori informazioni tecniche su GitHub , e Tor propone anche altri plug-in di trasporto che potrebbero essere utili.