Quattro confini da verificare prima di pagare tramite VPN
Un browser protetto, un tunnel e HTTPS proteggono ciascuno un confine diverso. Eseguite quattro controlli in ordine, fermatevi al primo che non riuscite a verificare, poi decidete.
Percorrete i quattro confini in ordine e la maggior parte delle domande sul pagamento si risponde da sola. Il primo è l'ambiente in cui viene eseguita la transazione, il secondo è il percorso del suo traffico, il terzo è se il sito è davvero quello che volevate raggiungere, e il quarto è ciò che il destinatario apprende dalla transazione indipendentemente dal percorso. Una suite di sicurezza che unisce un browser protetto a un tunnel vi invita a trattare un pulsante come un'unica garanzia, ed è esattamente lì che i controlli vengono saltati. Ogni controllo ha la propria condizione di arresto, e l'ordine conta perché uno successivo non può riparare un guasto precedente.
Primo: cosa limita davvero l'ambiente protetto
Il testo commerciale di una modalità di pagamento di solito elenca restrizioni: quali altre applicazioni possono interagire con la sessione, se gli appunti e la cattura dello schermo sono limitati, se la sessione gira su un desktop separato. Ciò che non stabilisce è che un componente host privilegiato, un driver o un meccanismo di input fuori dalla sandbox non possano raggiungere la sessione. Essere in una sandbox è la descrizione di un confine, non una promessa su ogni attaccante.
Leggete l'elenco delle funzioni dell'edizione che avete davvero installato, perché le modalità raggruppate spesso differiscono tra livelli consumer e talvolta mancano sui dispositivi gestiti. Confrontate quell'elenco con il guasto che vedete prima di supporre che il confine abbia tenuto.
Poi fermatevi e chiedetevi se il guasto che state inseguendo è locale. Se la pagina di pagamento viene visualizzata male solo dentro la modalità protetta, l'ambiente è il sospetto e il tunnel è irrilevante. Se viene visualizzata correttamente ovunque ma la transazione fallisce ancora, state guardando il confine successivo, e indebolire la modalità protetta non aiuterà.
Secondo: quale traffico trasporta il tunnel
Un tunnel protegge il traffico che copre, e la copertura è un fatto di configurazione, non una proprietà del prodotto. Chiedete se è incluso il traffico del browser protetto stesso, se la modalità aggira il tunnel per ragioni di prestazioni o di portale captive, e se una regola di tunnel diviso esclude la destinazione. Un browser normale che mostra l'indirizzo di uscita del fornitore non dimostra nulla su un ambiente di navigazione separato avviato da un altro processo.
Provate la copertura dall'interno dell'ambiente invece che dal desktop. Caricate una pagina che riflette il vostro indirizzo pubblico nella sessione protetta e confrontatela con l'indirizzo che vedete fuori, poi ripetete dopo aver riconnesso il tunnel. Se i due coincidono mentre il tunnel dichiara un'uscita diversa, la modalità non usa il tunnel e quella discrepanza merita di essere risolta prima di inserire i dati della carta. Anche cambiare l'indirizzo di uscita si sovrainterpreta facilmente: vi dice quale rete vede il venditore, non chi è il venditore.
Terzo: verificate il servizio invece del badge
La validazione del certificato è ciò che autentica la destinazione, e continua a funzionare dopo l'uscita del tunnel perché è un meccanismo separato. Una finestra protetta di marca e un indicatore Connected non dicono nulla sulla catena di certificati presentata dal sito che avete raggiunto.
Quando qualcosa sembra sbagliato, leggete il certificato prima di scartare l'avviso. Il comando qui sotto chiede la catena che il sito presenta realmente e indica allo strumento di fallire su un errore di verifica.
openssl s_client -connect shop.example:443 -servername shop.example -verify_return_errorConfrontate il soggetto e l'emittente di quell'output con l'indirizzo digitato, e confermate l'esito della verifica invece della presenza di un lucchetto. Un avviso dentro un browser protetto resta un avviso, e la causa abituale è una discrepanza di nome host, una risposta DNS dirottata o un apparato di intercettazione sul percorso. Nessuna di queste è riparata dal tunnel, e una modalità che sopprime in silenzio l'avviso ha rimosso informazioni che vi servivano.
Quarto: cosa apprende comunque il destinatario
Il sito di pagamento riceve tutto ciò che gli inviate: l'account con cui accedete, l'indirizzo di consegna, lo strumento della carta e l'importo. Un'uscita di rete diversa cambia l'indirizzo di origine nei registri del venditore e lascia quei campi esattamente com'erano. Se l'account è già legato a voi, il tunnel ha cambiato una piccola parte del quadro e nulla della parte identificativa. Non è un motivo per saltare il tunnel, solo un motivo per smettere di aspettarsi che faccia questo lavoro.
La documentazione di Bitdefender su Safepay descrive un browser protetto con un'integrazione del tunnel correlata, che è un buon esempio di un prodotto che copre due confini senza fonderli. L'ambiente e il percorso sono entrambi utili, e nessuno dei due si fa garante del venditore.
Per un pagamento che vi sta a cuore, partite dall'indirizzo pubblicato dell'organizzazione o dalla sua applicazione ufficiale, mantenete i controlli di identità richiesti dal sito e rifiutate qualsiasi assistente offerto da un avviso inatteso sulla pagina di pagamento. Se la modalità protetta o il tunnel causano un guasto, nominate prima il confine: avviare l'ambiente, raggiungere la rete, validare il certificato o autenticare l'account. Poi usate il percorso di ripristino supportato dal fornitore per quello strato invece di disattivare le protezioni per vedere se la pagina si carica.