Impossibile forzare HTTPS durante la connessione al server proxy, anche se la porta 443 è aperta

1

Ho cercato di utilizzare HTTPS ogni volta che eseguivo la navigazione web sensibile attraverso un server proxy. Idealmente uso una combinazione di HTTPS, un proxy anonimo o elitario e DuckDuckGo per tutte le mie ricerche sul web. Recentemente ho riscontrato un problema con questo però. Fino ad ora, non ho avuto problemi a forzare HTTPS quando mi collego a un proxy, ma proprio ora ho iniziato a ricevere un errore "400: Connessione rifiutata" quando lo faccio. Ho usato NMap per vedere quali porte erano aperte sul proxy.

sudo nmap -p 1-1024 -sX 0.0.0.0
Nmap scan report for 0.0.0.0
Host is up (0.092s latency).
All 1024 scanned ports on 0.0.0.0 are open|filtered

Nmap done: 1 IP address (1 host up) scanned in 96.98 seconds

Quindi tutte le porte sono aperte, incluso 443, quindi dovrei essere in grado di farlo. Ho ricevuto questo errore per ogni proxy che ho provato, quindi sembra essere un problema alla mia fine. L'output NMap suggerisce che potrebbe avere qualcosa a che fare con il firewall. Inoltre, sono stato in grado di telnet sulla porta 80 ma non su 443.

Quindi in fondo la mia domanda è: perché sta succedendo questo e come risolverlo?

    
posta Legend of Overfiend 28.03.2017 - 01:22
fonte

1 risposta

1

Suppongo che tu stia utilizzando un proxy anonimo e questo non è qualcosa che tu o la tua azienda avete sotto controllo. Se è così, sei davvero in balia della configurazione di quel server. Anche l'output nmap non è qualcosa che vorrei prendere a cuore, un sistema con 1.024 porte aperte non è realistico.

All 1024 scanned ports on 0.0.0.0 are open|filtered

Sono abbastanza sicuro che il traffico venga filtrato da qualche parte lungo la linea che sta infrangendo nmap. Inoltre, una scansione Xmas non è qualcosa che suggerirei di usare a meno che tu non abbia un uso specifico per esso, attenersi a qualcosa come una scansione TCP ( -sS ) o anche una scansione connect () ( -sT ). È molto probabile che la scansione stia accendendo qualche apparecchio lungo la strada e sta facendo cadere pacchetti pensando che il traffico sia falso.

Un HTTP 400 è una cattiva richiesta. Potrebbe trattarsi di qualcosa di sbagliato nella tua trasmissione, come un'intestazione non valida, o potrebbe essere che il server non parli in HTTPS e tu stia cercando di parlare con un server HTTP usando HTTPS. Probabilmente dovrai consultare i registri di accesso del proxy per ulteriori informazioni su 400. potresti avere qualcosa in locale se puoi abilitare la registrazione di debug, forse anche una traccia di pacchetti.

    
risposta data 28.03.2017 - 03:31
fonte

Leggi altre domande sui tag