Per chi fosse interessato, qui trovate le 3 lezioni su #cibernetica, #informatica e #CyberSecurity che ho tenuto ieri per la #CGIL
Perché proprio dal #lavoro su cui si fonda la nostra democrazia, può rinascere una piena #cittadinanza cibernetica.
http://www.tesio.it/2022/04/22/Fondamenti_di_CyberSecurity.html
@Shamar
il certificato del sito è sbagliato 😅 ho dovuto abbassare il livello di sicurezza per accedere, è un test di ingresso? 😆
Splendida obiezione!
Che browser stai usando e con che plug-in?
Hai voglia di condividere uno screenshot?
Non è sbagliato: semplicemente non c'è un certificato SSL il che, per il #Web di Google, è inaccettabile.
#HTTPS non è la soluzione a tutti i problemi ed ne crea di nuovi che possono o meno essere rilevanti per la tua organizzazione.
Essendo distribuito solo via HTTP, il mio sito può essere cachato da proxy intermedi, riducendo il carico del server e rimuovendo per me la possibilità di tracciare i miei visitatori.
Inoltre il mio sito non contiene form o contenuti sensibili per cui i visitatori non possono cedere dati personali a me o a terzi.
HTTPS impedisce il caching intermedio e costringe il browser a contattare direttamente il server. Ed indovina chi controlla il 65-70% dei server su internet?
Chi effettua l'SSL offloading del 65-70% del traffico? Proprio il cloud di #Google, #Amazon e #Microsoft.
Comunque se ritieni il tuo fornitore di connettività una minaccia peggiore di tutte le CA che potrebbero rilasciare certificati falsi (entrambe minacce estremamente improbabili quando visiti il mio sito) puoi usare https://web.archive.org/ come proxy cifrato ai miei contenuti (magari via TorBrowser così che nemmeno la wayback machine possa tracciarti).
Il sito non è servito solo tramite http. Quel dominio risponde al protocollo https ma il certificato è firmato per il server ovh che lo ospita.
Forse, al di là dei giudizi sul visitatore, il servizio è configurato male e non dovrebbe nemmeno ascoltare la porta SSL
Non è chiaro cosa intendi per "possibilità di tracciare i visitatori", è una facoltà indipendente dal protocollo.
Il proxying di qualche maleintenzionato invece potrebbe alterare il contenuto in modo incontrollabile
Porca miseria, hai ragione!
Non capisco perché OVH modifichi/ignori la configurazione del mio sito in cui ho esplicitamente disabilitato HTTPS.
Ora controllo...
Ok, ora se accedi al sito HTTP con un browser sensato (che non legge https dove c'è scritto http:// ) vedi correttamente il sito http.
Se accedi al sito usando https://www.tesio.it (o con un browser che non rispetta le richieste dell'utente per "proteggerlo") vieni rediretto al host cifrato https://encrypted.tesio.it
Si stanno anche rigenerando i certificati SSL via Let Encrypt ma ci potrebbe volere un po'.
Almeno finché OVH non pasticcia di nuovo la mia configurazione.
Poi sì: un sito senza TLS abilitato NON dovrebbe ascoltare sulla porta 443.
PS: i miei non erano "giudizi sul visitatore": al massimo sono giudizi sull'incompetenza dilagante che mette TUTTO dietro TLS anche quando non c'è letteralmente alcuna ragione per farlo, impedendo il caching intermedio.
E d'altronde, uno dei limiti del HTTPS è che mischia autenticazione con riservatezza mentre le due cose potrebbero e dovrebbero essere gestite separatamente.
Se non consideri una minaccia il tuo fornitore di connettività, sei leggermente meno sicuro di prima perché usando i certificati TLS sei vulnerabile anche ad attacchi da parte delle CA.
Che però contrariamente all'assenza di TLS il browser non ti segnalerebbe.
Dunque sì, ti senti più sicuro, ma lo sei quanto prima o meno.
In compenso, ogni tua visita via HTTPS è tracciabile sul server web, cosa che non sarebbe vero se usassi HTTP (o un protocollo migliore che distinguesse autenticazione e riservatezza).
Che in questo caso è irrilevante perché io non traccio nessuno... ma l'equazione HTTPS = Sicurezza è di grande aiuto a Google & friends.
@Shamar
Adesso mi sento indubbiamente più sicuro 😁