Come dovrebbe reagire il software quando i Captive Portals oi certificati SSL non attendibili impediscono la connettività?

5

Devo risolvere un problema in cui la chiamata HTTPS iniziale (o forse solo) a un sito Web è bloccata da un captive portal, non gestito da me. La risoluzione è stata quella di chiedere all'utente di navigare verso un sito "http" per poter dire allo stack del software di accedere tramite il portale.

Da una prospettiva dell'app vedo che il sito previsto è:

  • SSL non è disponibile (nessuno dei codici di risposta ICMP)
  • SSL ha un certificato non attendibile dal portale
  • SSL ha un certificato non attendibile e contenuto inatteso (login al portale)

Ognuno di questi comportamenti si traduce in un risultato diverso da parte di vari stack software, sistemi operativi e software di home-brew.

Qual è il modo più compatibile di gestire i portali in cattività quando:

  1. Accesso a un sito Web che offre servizi REST protetti, app SPA o simili?
  2. Richiesta da un'app su iOS, Android che sfrutta il framework HTTP integrato per quella piattaforma
  3. Richiesta da un'app che non fa leva sul framework HTTP della piattaforma, ma utilizza invece OpenSSL, BouncyCastle o Monotouch / MonoDroid
  4. Richiesta da un PC desktop (OSX o Windows)

w.r.t. # 4, so che OSX tenterà di contattare link per determinare se un reindirizzamento 301/302 è a posto. .. o se il portale sostituisce semplicemente il contenuto direttamente tramite MITM / Content Injection.

    
posta random65537 15.10.2015 - 19:02
fonte

2 risposte

4

Non solo OSX, ma la maggior parte delle piattaforme ora richiede un URL noto e verifica se il contenuto è sostituito o manomesso per rilevare gli hotspot.

Windows 7+:

NCSI performs a DNS lookup on www.msftncsi.com, then requests http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text Microsoft NCSI.

NCSI sends a DNS lookup request for dns.msftncsi.com. This DNS address should resolve to 131.107.255.255. If the address does not match, then it is assumed that the internet connection is not functioning correctly.

Fonte: link

Android 4.2.2 +:

http://clients3.google.com/generate_204

Fonte: # 1 & # 2

La maggior parte di questi URL può essere modificata se la privacy è un problema.

La soluzione per la tua applicazione sarebbe quella di fare una richiesta HTTP GET e vedere se questa viene manomessa.

Sulla maggior parte degli hotspot che utilizzo, vedo una sessione SSL / TLS in errore a causa della firma del sito da parte del provider di hotspot piuttosto che da quella che stavo tentando di visitare (non hanno i certificati per il sito Sto tentando di visitare) che il tuo controllo del nome host TLS / SSL verrà contrassegnato ... o semplicemente bloccherà la connessione finché non vedranno un HTTP OTTENERE a un sito che possono MITM ... che sembrerebbe un timeout.

Un vantaggio nell'avere un link URL di stile piuttosto che riutilizzare Microsoft o Google è che puoi provare a fornire più informazioni utili su lo stato della tua applicazione se l'URL di stato segnala che il servizio è integro, ma la rete dell'utente non consente loro di connettersi al tuo endpoint TLS / SSL se il link la pagina è inattiva, quindi forse anche la tua applicazione non funziona.

    
risposta data 06.03.2016 - 12:41
fonte
-1

È certo: usa Tor e / o I2P, sono gli strumenti esatti di cui hai bisogno: strati di trasporto resistenti alle manomissioni.

UPDATE: il problema degli "URL predefiniti" è che sono ... predefiniti . Facile da realizzare una trappola su un percorso di un pacchetto di rete da app a server. La radice del problema è che i protocolli di routing tradizionali sono molto "semplici", troppo facili da manomettere. Il significato stesso del termine "Darknet" è che non è sostenibile nel significato della manomissione del routing.

    
risposta data 06.03.2016 - 14:49
fonte

Leggi altre domande sui tag