oggi, 29 aprile 2021, ore 08:30 ho vissuto per la prima volta l'apice
della follia della sicurezza.
Firefox non mi permette l'accesso ai miei dati.
Uso desktop e Raspberry collegati in rete locale 192.168 ecc. per
monitorare e loggare dati di miei consumi domestici. Vi accedo con
Firefox via semplici protocolli HTML per visualizzare tabelle sullo
schermo.
Ho fatto poco fa uno degli infiniti aggiornamenti Firefox. Da allora
non ho piu' accesso alle tabelle.
Il programma indica "connection not secure", e la chiude.
Entro nel menu, ci sono opzioni per permettere l'accesso a microfono,
videocamera ecc. Una dozzina di domande meno quella fondamentale "sito
sicuro, non applicare misure di sicurezza".
Ho inserito il sito locale nel Security Dashboard come "Allow". Non
serve. FF risponde che il sistema remoto (remoto, vabbe!) cerca di
accedere alla mia "location". Cioe', qualcuno dall'indirizzo
192.168.1.147 cerca di accedere a 192.168.1.147. Chissa' chi puo'
essere.
Faccio "Allow" su tutto, non funziona.
Qualcuno puo' darmi suggerimenti in merito?
FF purtroppo non considera che un indirizzo che inizia per 192.168.x.x
NON puo' fare parte del grande Internet.
E anche se gli hacker di tutto il mondo mi dovessero leggere la
temperatura del salotto - chissenefrega! Grande rivelazione, anteprima
mondiale - e' tra i 18.5 e i 22 gradi ed e' in relazione alla
temperatura esterna, che e' dato oggettivo e pubblico. Incredibile, no?
Dalla versione 83, Firefox supporta la modalità HTTPS-Only
(l'equivalente dell'estensione HTTPS Everywhere). Suppongo che sulla
88 sia attiva di default, il che è un'OTTIMA COSA.
Per mettere uno specifico sito in lista bianca, segui le istruzioni:
Sull'ottima cosa ho qualche dubbio, almeno per quanto riguarda le reti
locali quando Internet e' scollegato.
L'informazione linkata non e' piu' valida. Ora occorre andare sul
Protection Dashboard, qui c'e' un link piccolissimo "Manage your
privacy and security settings". Nel menu e' presente l'opzione "Don't
enable HTTPS-Only Mode". Che da me e' sempre stata opzione prescelta.
Temo, dopo avere visto diversi commenti online, che ormai FF e altri
scelgano da soli i livelli di protezione necessari e non lascino piu'
all'utente la possibilita' di gestirli in pieno. L'era nella quale era
possibile usare browser generici come interfacce verso apparecchi,
dispositivi ecc. tramite semplici dialoghi HTML sta terminando.
Sull'ottima cosa ho qualche dubbio, almeno per quanto riguarda le reti locali quando Internet e' scollegato.
No, nessun dubbio: anche se le informazioni non sono riservate, non
c'è alcun motivo valido per mandare in rete dati in chiaro. Le
connessioni non criptate sono intercettabili, ed è facilissimo
iniettare del contenuto malevolo.
L'informazione linkata non e' piu' valida. Ora occorre andare sul Protection Dashboard, qui c'e' un link piccolissimo "Manage your privacy and security settings". Nel menu e' presente l'opzione
"Don't enable HTTPS-Only Mode". Che da me e' sempre stata opzione prescelta.
Disabilitare in toto HTTPS Only mode è una pessima idea. Dovrebbe
essere tuttora possibile mettere un singolo sito in modalità HTTP,
però magari la documentazione non è aggiornata.
Nella peggiore delle ipotesi, puoi installare HTTPS Everywhere come
estensione ed affidarti a quella (che gestisce anche le whitelist).
Temo, dopo avere visto diversi commenti online, che ormai FF e altri scelgano da soli i livelli di protezione necessari e non lascino piu' all'utente la possibilita' di gestirli in pieno.
Io credo che la maggior parte delle persone non sappiano, o almeno non
si prendano il tempo per imparare, come proteggersi. Quindi che
Firefox abbia scelto una policy sicura per default è una novità che
apprezzo (per molte cose, la sua sicurezza non è esattamente allo
stato dell'arte). Finora non mi è mai capitato di non poter
L'era nella quale era possibile usare browser generici come interfacce verso apparecchi, dispositivi ecc. tramite semplici dialoghi HTML sta terminando.
Ma neanche per idea, l'HTML è lo stesso identico anche su una
connessione criptata. Sarebbe invece bello che terminasse l'era dei
dispositivi in rete senza alcun livello di protezione - poco importa
che siano in rete locale.
Tanto per citare una battuta ormai tristemente famosa: la S in IoT sta
per Sicurezza.
Finora non mi è mai capitato di non poter personalizzare quello di cui
avevo bisogno. Firefox è parecchio configurabile, e ha una valanga di
estensioni per fare anche quello che non è già previsto
nell'interfaccia.
non riesco a capire se siamo d'accordo o in completo disaccordo. Io non
uso in alcun modo IoT, verso il quale sono estremamente critico.
Infatti lo sconsiglio vivamente. Viva la 'S'.
Qui' pero' manca completamente la 'U' di usabilita'.
Nel caso specifico ho un programma residente sul mio PC che ascolta un
socket dal quale legge un carattere alla volta. Al primo carattere che
non coincide con un formato ben preciso, rigetta l'intero messaggio. Da
browser partono richieste http://indirizzolocale/qualificatori cui
risponde con "codice 200, tutto bene, ti invio 500 caratteri, eccoti il
contenuto HTML." Non capisco perche' non debba piu' funzionare e come
farlo funzionare. Passare a HTTPS e richiedere un certificato e'
decisamente eccessivo.
Su Internet finora ho potuto appurare che (1) il problema e'
conosciuto, (2) Firefox non lo documenta e (3) non c'e' proprio modo di
dire "fidati, conosco quel sito, mi prendo io i rischi, limitati a
piazzarmi sullo schermo quello che ti invia".
Almeno noi interessati a Linux dovremmo concordare che in ultima
istanza non spetta a chi mette a disposizione un programma decidere
direttamente o indirettamente l'uso che ne facciamo, specie se non c'e'
nulla di illegale.
Forse il prossimo passo sara' disabilitare 'sudo'? Cosi' corriamo
ancora meno rischi...
Non capisco perche' non debba piu' funzionare e come farlo funzionare. Passare a HTTPS e richiedere un certificato e' decisamente eccessivo.
Perché non debba funzionare ho provato a spiegartelo: le richieste in
chiaro sono troppo facili da sovvertire - qualsiasi attaccante le può
usare per scopi malevoli con sforzo nullo. Passare ad un certificato
autofirmato richiede un paio di comandi, non è chiedere troppo:
certamente ti avrebbe portato via molto meno tempo dello scrivere
queste email.
Su Internet finora ho potuto appurare che (1) il problema e' conosciuto, (2) Firefox non lo documenta e (3) non c'e' proprio modo di
dire "fidati, conosco quel sito, mi prendo io i rischi, limitati a piazzarmi sullo schermo quello che ti invia".
Mah, che ci sia gente che si lamenta non ne dubito; Firefox però non
solo lo documenta per benino, ma dice anche che il modo esiste.
Almeno noi interessati a Linux dovremmo concordare che in ultima istanza non spetta a chi mette a disposizione un programma decidere
direttamente o indirettamente l'uso che ne facciamo, specie se non c'e' nulla di illegale.
Forse il prossimo passo sara' disabilitare 'sudo'? Cosi' corriamo ancora meno rischi...
Su molte distribuzioni sudo non è installato, ed è compito
dell'amministratore decidere se aggiungerlo e quali utenti abilitare.
Secure by default è una buona politica.
Ma qui andiamo fuori dal seminato.
La documentazione ufficiale di Mozilla che ti ho linkato dichiara di
essere valida anche per Firefox 88. Se è sbagliata non lo posso
controllare (ho Firefox versione ESR), ma dice esplicitamente che
quello che chiedi tu si può fare. Sarei ESTREMAMENTE stupito che
questa funzione sia stata tolta - anche perché purtroppo di siti in
solo HTTP ce ne sono in giro moltissimi (ad esempio, un certificato
SSL su governo.it è stato aggiunto solo dopo l'insediamento governo
Draghi... non aggiungo altro).
Forse c'è un bug da qualche parte: ma se una funzione è documentata
correttamente e a me non funziona, in prima istanza mi aspetto che il
problema sia mio e non del resto del mondo. Se verifico che così non
è, apro una issue.
Perché non debba funzionare ho provato a spiegartelo: le richieste in
chiaro sono troppo facili da sovvertire - qualsiasi attaccante le può
usare per scopi malevoli con sforzo nullo. Passare ad un certificato
autofirmato richiede un paio di comandi, non è chiedere troppo:
certamente ti avrebbe portato via molto meno tempo dello scrivere
queste email.
Non sapevo che si potessero generare certificati autofirmati, credevo
che fossero in ogni caso di responsabilita' di aziende terze. Mi potete
dare un link, che provo?
La documentazione ufficiale di Mozilla che ti ho linkato dichiara di
essere valida anche per Firefox 88. Se è sbagliata non lo posso
controllare (ho Firefox versione ESR), ma dice esplicitamente che
quello che chiedi tu si può fare. Sarei ESTREMAMENTE stupito che
questa funzione sia stata tolta
ci provo, ma avevo cercato in dettaglio anche prima
Vi do' ragione che tutti i collegamenti dovrebbero essere in HTTPS. Il
giorno che lo saranno, ma con banca o siti governativi lo sono gia',
potremo fare a meno del doppio codice di identificazione che adesso e'
richiesto, per l'appunto, dalle banche?
Posso restare convinto che certe precauzioni siano eccessive, in
particolare se si fa attenzione a come usare il conto e si fanno
verifiche periodiche? Ho Ebanking da quando l'hanno introdotto, piu' o
meno 1995, e le uniche situazioni di rischio che ho incontrato sono
state le mail delle principesse nigeriane o di banche nelle quali non
ho il conto che chiedono immediate verifiche online. SPAM, faccenda
chiusa.
mi sento di aggiungere un commento relativo al problema originale: nota
che anche se HTTPS Everywhere è attivo, dà la possibilità di accedere al
sito egualmente anche se non supporta HTTPS (il messaggio contiene un
tasto "Continue to HTTP site", che se premuto disattiva HTTPS Everywhere
per quel sito in particolare). Inoltre, HTTPS Everywhere non pare essere
attivo di default quando Firefox viene aggiornato alla versione 88 da
una precedente; o almeno, così non è successo sul mio Ubuntu.
Tu prima parlavi di un messaggio relativo alla localizzazione, allora il
problema mi pare differente: il sito web al quale sta accedendo cerca di
invocare la Geolocation API, che per specifiche deve funzionare solo su
HTTPS (per evidenti motivi di sicurezza). Se ti va, puoi descrivere un
po' più nel dettaglio il tuo setup e il messaggio di errore che ricevi?
Credo il problema sia diverso dall'avere un sito in rete locale che non
supporta HTTPS.
Riguardo le altre domande:
- si possono generare certificati autofirmati, ma di default non
vengono accettati dal browser, almeno fintanto che la root of trust del
certificato autofirmato non è aggiunta al browser - che non è sempre
un'ottima idea. È possibile però aggiungere eccezioni a firefox in modo
da accettare anche un certificato autofirmato per uno specifico dominio.
In generale, una CA non certificherà mai un dominio che non è registrato
su un DNS pubblico.
- il doppio codice di identificazione che citi per le banche
garantisce qualcosa di diverso da HTTPS: HTTPS garantisce che la
connessione fra la tua macchina e il server della banca non venga letta
o modificata da malintenzionati (confidenzialità, integrità); gli schemi
di identificazione della banca invece garantiscono che sia tu ad
effettuare la connessione, e non qualcun altro che si spaccia per te e
ha aperto una connessione HTTPS con la banca (autenticazione). Entrambi
gli schemi sono necessari e si complementano.
Il problema con Firefox sembra finalmente risolto e ti ringrazio per la
tua mail molto esaustiva. Salto tutto, vorrei farti una domanda
riguardo ebanking.
Sei a conoscenza di statistiche ufficiali sul rischio di abuso di
identita', truffe da parte di terzi ecc.?
Quello che non mi convince in PSD2 e' che il costrutto e' complicato e
soprattutto non e' gestibile solo da desktop. Tutte le soluzioni
attuali hanno un cellulare o smartphone da qualche parte nella catena
di verifica.
Al momento io accedo ancora ai servizi bancari via generatore TAN.
Questo richiede l'inserimento fisico della mia carta con chip
nell'apparecchio, una password e codici che mi invia la banca su
desktop.
Se ora dovessi passare alla app dovrei (1) acquistare uno smartphone,
(2) fare abbonamento con TIM o Vodafone o qualcun altro fornendo loro
una marea di dati personali, copia dei documenti ecc. e (3) abilitare
un account gmail, di nuovo fornendo dati.
Quanto vorrei e' sapere se la complessita' e i costi di PSD2 sono in
relazione a un effettivo beneficio. Se il mio rischio ora e' 1 su
10exp-6, probabilmente anche meno, ha senso spendere 500-1000 EUR e
farmi profilare da google per portare il rischio a 10exp-9?
Da 2-3 anni cerco documenti ufficiali, la descrizione del problema che
PSD2 vuole risolvere, senza successo.
Se hai informazioni a proposito, sarei molto interessato.
purtroppo non so esserti molto d'aiuto per quanto riguarda le
statistiche, il mio interesse sul tema è molto più teorico/accademico
che pratico.
La parte che descrivi della PSD2 si chiama "Strong Customer
Authentication" [1], e sostanzialmente descrive i requisiti necessari ad
implementare una autenticazione in due fattori. In generale, non può
essere considerata sicura (nel senso di autentica e confidenziale) una
comunicazione che passa esclusivamente per una piattaforma
potenzialmente compromessa (cioé il computer), per questo motivo ci si
affida ad un dispositivo fidato esterno (come ad esempio il generatore
di codici che descrivi).
Non conosco il regolamento nel dettaglio, ma francamente non vedo motivo
per non considerare sicuro il sistema che tu descrivi - certamente ha
tutti gli elementi per soddisfare i requisiti della SCA. Considera che
SCA serve proprio perché le misure di sicurezza che tu descrivi e usi
non erano obbligatorie, era cioè ancora possibile autorizzare operazioni
di pagamento con metodi meno sicuri (ricordo ad esempio che con la mia
banca fino a relativamente poco tempo fa avevo semplicemente due
password, una per accedere al portale e una seconda per autorizzare le
transazioni - l'autenticazione in due fattori era opzionale e caldamente
raccomandata da loro stessi, ma non obbligatoria). Se l'autenticazione è
effettuata unicamente tramite password, sia la compromissione della
piattaforma sia rivelare la password (prendi ad esempio un keylogger,
social engineering, una password debole, un qualche breach ad un altro
servizio in cui lo stesso utente ha riciclato le stesse credenziali)
possono avere risultati catastrofici.
D'altro canto immagino che le banche vogliano semplificare la gestione
della loro infrastruttura e probabilmente tagliare qualche costo sulla
produzione dei generatori, assumendo che grossomodo tutti abbiano uno
smartphone. Capisco il tuo fastidio nel vederti "imposto" l'uso dello
smartphone di cui vorresti farne a meno - qui temo che la
giustificazione abbia meno a che fare con l'information security e più
con decisioni arbitrarie della banca.
Tutte perfette le tue considerazioni, aggiungo solo una nota; uno dei
fondamenti della PSD2 è che tu sappia non solo CHE stai autorizzando
un'operazione (come avviene con OTP hardware o simile) ma anche QUALE
operazione stai autorizzando, facendoti vedere importo e ultime cifre
dell'iban (su un canale diverso dal pc, es. smartphone o sms), proprio
per evitare un tipo di truffe molto diffuse negli ultimi anni, cioè
man-in-the-browser[1] (un malware o simile nel tuo pc che ti fa vedere
una cosa sul video, ma ne fa un'altra dietro, e ovviamente usa il tuo
OTP per autorizzare un'operazione diversa da quella che volevi fare tu).
Tecnicamente un token hardware è molto più sicuro (anche se..[2]) sia di
uno smartphone (malware, ecc) che di un sms (es sim swapping sempre più
diffuso), ma non risolveva il problema di cui sopra, e ovviamente ha
costi di gestione molto maggiori, per cui credo si sia optato "per il
male minore".
con il sistema che - per fortuna - ancora funziona la banca invia
codici relativi alla transazione che appaiono sul generatore TAN.
Voglio inviare 100 EUR a tizio, mi arrivano barrette codificate sullo
schermo del desktop, il generatore le decodifica e chiede Tizio? <si>
100 EUR? <si> allora inserisci 12345 di TAN.
Questa soluzione e' stata introdotta dalla mia banca intorno al 2010.
Funziona e i clienti sono soddisfatti, cosi' mi hanno detto allo
sportello.
Diversi specialisti in Germania, dove TAN e' ancora diffuso, indicano
che come sicurezza TAN e' addirittura maggiore che lo smartphone,
propio perche' occorre avere in mano il generatore e la carta bancaria
che idealmente sono consegnati di persona. Un malintenzionato dovrebbe
falsificare l'identita' allo sportello, rubare posta cartacea, avere
accesso al PC della vittima, conoscere le password. Temo che invece
Google, avendo accesso a tutto quanto accade su Android, avrebbe
maggiore facilita' a capire come accedere al conto. O farlo
direttamente, via app. Non per transazioni non volute, ma per leggere
saldo e movimenti...
Come avete capito, PSD2 nella sua implementazione pratica mi sembra una
soluzione a un problema solo parzialmente esistente, e che introduce
piu' criticita' di quante ne risolva.
Per il resto continuo a cercare se sono disponibili statistiche. Se
trovo qualcosa, informo i partecipanti al sito.
C'e' una soluzione ancora piu' radicale. Usare il terminale come VT100.
Con poche righe di Bash e alcuni codici di controllo si posiziona il
cursore in alto e di scrive una tabella. Un po' come il comando "top".
Update continuo in modo "push".
In confronto, Firefox adesso pesa circa mezzo Giga.
