SIAMO GEEK

Tag: ssl

  • Prima versione di LibreSSL

    LibreSSLÈ stata rilasciata la prima versione di LibreSSL, aggiornata oggi alla 2.0.1.

    LibreSSL si propone come rimpiazzo di OpenSSL dopo i problemi iniziati con heartbleed. Il team di BSD ha avviato il progetto con l’intenzione di produrre un codice meno fumoso, più stabile e sicuro.

    Il codice di OpenSSL ha sulle spalle una lunga storia di compatibilità verso il basso che ha trasformato il codice in qualcosa di poco gestibile e prono agli errori.

    LibreSSL ha tolto di mezzo la compatibilità con piattaforme non più utilizzate in produzione, come MS-DOS, VMS, NetWare, Windows a 16 bit, Windows NT e OS/2 e con essa un sacco di problemi.

    Di fatto OpenSSL utilizza un C compatibile con ogni compilatore possibile da quello dell VMS al QuickC 1.5 all’ultimo gcc, con il risultato che deve reinventare al proprio interno il fuoco, la ruota e l’acqua calda. Una delle conseguenze di tutto ciò è che OpenSSL ha una propria libreria di allocazione della memoria che non è controllabile dal sistema operativo o dai normali tool di debug, ma ha una propria serie di API per fare il debug della gestione della memoria.

    (altro…)

  • OpenSSL e software open

    Sono state scoperte e corrette altre sei vulnerabilità di OpenSSL. Enfasi su “corrette”.

    Dopo Heartbleed qualcuno ha dubitato della bontà del software open, altri hanno visto quel problema come un argomento a favore di una circolazione limitata dei sorgenti.

    Sono argomenti facilmente confutabili con l’esperienza della storia e le basi della sicurezza informatica.

    (altro…)

  • SMTP STARTTLS in crescita

    Un rapporto di Facebook dimostra che la cifratura della posta elettronica ha raggiunto una “massa critica”.

    Questa è senza dubbio una buona notizia per la tutela dei dati personali perché il normale protocollo SMTP, figlio di quando Internet era un’altra cosa, dialoga in chiaro.

    L’estensione STARTTLS consente anche ad SMTP di passare ad una connessione cifrata utilizzando la medesima connessione TCP.

    (altro…)

  • Heartbleed: anche le password

    by heartbleed.comAncora su OpenSSL / Hearthbleed, i maggiori siti dovrebbero aver già predisposto gli aggiornamenti necessari a superare il problema. Adesso è il turno dei singoli utenti.

    Una delle conseguenze di Hearthbleed è la possibilità che il traffico https sia stato intercettato e decriptato. Con esso pure le password per accedere ai singoli servizi. Le conseguenze sono ovvie.

    Il consiglio a tutti gli utenti è quello di cambiare al più presto TUTTE le password di Home Banking, Facebook, Google, LinkedIn, PayPal, Amazon e di tutti i vari servizi in giro sul web a cui siete iscritti (specie quelli in cui c’è movimento di denaro o dati di carte di credito) perché potrebbero essere state compromesse. E’ difficile ma dobbiamo presumere per sicurezza che sia stato fatto.

    Mai, mai, mai, mai utilizzare su questi siti una password che utilizzate anche per lavoro. MAI! Se craccano il servizio esterno mettete in pericolo pure l’infrastruttura dove lavorate. Se l’avete fatto in passato occorre cambiare anche quella password (supponendo che le regole interne non vi obblighino già a farlo regolarmente).

    Mai, mai, mai, mai utilizzare la stessa password su più siti diversi. MAI! Se viene compromesso un sito possono (anzi lo fanno di sicuro) provare a vedere se lo stesso account è presente su altri servizi.

    Ad esempio se vi catturano la password di Facebook che mettiamo sia uguale a (esempio assurdo) quella del vostro Home Banking pensate che di essere al sicuro?

    Avere password differenti è importante, pensate al vostro portachiavi. Avete un unica chiave oppure una chiave per ogni porta che dovete aprire?

    Per quanto riguarda la complessità della password… lasciamo stare la teoria che vorrebbe password lunghe chilometri con ghirigori, maiuscole, minuscole, numeri, simboli, giravolte, sbirigudi ed antani. Proteggiamo pesantemente  (magari con l’autenticazione multipla e con SMS di avviso) l’account che per voi è fondamentale. Quello su cui magari vi arrivano le notifiche dagli altri account e tramite il quale possono accedere agli altri servizi. Per gli altri servizi si può utilizzare una password più semplice da ricordare (ATTENZIONE: semplice non significa banale o completamente idiota) e magari dove disponibile attivare sempre l’autenticazione multipla.

    Per fare un esempio recentemente è saltata fuori la storia di un giornalista a cui hanno rubato tutti gli account semplicemente perché sono riusciti ad introdursi nella sua posta elettronica. Una volta preso il controllo delle mail gli hanno cambiato le password di tutto, rubato gli account Twitter, Facebook, Google+ e i domini Internet dei propri siti web. Fate voi.

    E se pensate “a me non succederà mai perché chi vuoi che mi attacca a me” siete le vittime perfette. Pensate che la maggior parte di questi attacchi non sono mirati ma fatti con script automatici. A loro non interessa chi siete ma solo i vostri account.

    L’ho già detto “Mai, mai, mai, mai utilizzare su questi siti una password che utilizzate anche per lavoro. MAI!” ? Ve lo ridico giusto per essere sicuri.

    Fine del pippone.

  • Heartbleed: non solo i server

    by heartbleed.comQuando si parla di heartbleed quasi tutti pongono l’accento sulla falla di sicurezza dei server.

    Ma le librerie OpenSSL sono utilizzate anche dai client, altrimenti chi si collegherebbe al server? 🙂

    Anche qui stiamo parlando di programmi prevalentemente Linux/FreeBSD o comunque in genere dei porting da Linux/FreeBSD su altre piattaforme.

    I programmi client utilizzano le stesse librerie e le stesse funzioni dei server. Tra questi si annoverano cURL e wget, molto utilizzati non solo dagli utenti per scaricare file, ma da molti script e programmi terzi per i medesimi scopi. Al di fuori del protocollo https, si può citare fetchmail.

    La libreria OpenSSL è utilizzatissima da quasi tutti i programmi che implementano SSL/TLS.

    È quindi essenziale che tutti aggiornino appena possibile OpenSSL ad una versione successiva la 1.0.1f, anche se non hanno server con abilitato https.

    Aggiornamento 13 aprile 2014 – Uno script in Python permette di verificare se un client è vulnerabile.

  • Heartbleed

    by heartbleed.comHeartbleed è il nome di una vulnerabilità molto seria scoperta sulla libreria OpenSSL dalla versione 1.0.1 alla 1.0.1f incluse.

    OpenSSL è utilizzata per il traffico https da molti software, tra cui Apache e nginx che da soli costituiscono il 66% dei server web, anche se bisogna rilevare che non tutti i server web hanno https abilitato.

    Microsoft Internet Information Server non è interessato da questo problema.

    I prodotti Apple non sono interessati dal problema, con l’eccezione dell’AirPort per cui è disponibile un aggiornamento.

    Tutto è cominciato nel 2012 con la release di OpenSSL 1.0.1 che introduce il supporto di RFC6520 e implementa l’heartbeat sulle connessioni TLS. Questa funzione serve a mantenere il canale aperto e impedire, quindi, che client e server debbano rinegoziare la connessione in caso di temporanea inattività. L’espediente dell’heartbeat o keep-alive è utilizzato in molti contesti in cui si invia un pacchetto dati senza informazioni con il solo scopo di resettare eventuali contatori di inattività.

    Il problema di OpenSSL è che una riposta al’heartbeat modificata ad arte può rivelare all’attaccante informazioni di vario tipo. Non è possibile utilizzare questa vulnerabilità per eseguire codice sul server remoto, ma questo non è certo un fattore mitigante, vediamo perché. (altro…)

  • Testimonianza di Snowden al Parlamento Europeo

    Lo scorso dicembre la Commissione per le libertà civili, giustizia e affari interni del Parlamento Europeo ha inviato ad Edward Snowden alcune domande nell’ambito dell’inchiesta sulla sorveglianza di massa dei cittadini europei.

    Snowden ha deciso di partecipare con una diretta video, che non è ancora stata resa pubblica, ma è disponibile una trascrizione di domande e risposte riprodotta alla fine di questo articolo e scaricabile anche in formato PDF tramite il link nell’IFRAME di Scribd.

    La lettura del testo è molto interessante: non contiene nulla di nuovo, ma fa il punto sulla posizione di Snowden e sulle sue motivazioni.

    Dal punto di vista tecnico questo passaggio è degno di nota:

    The good news is that there are solutions. The weakness of mass surveillance is that it can very easily be made much more expensive through changes in technical standards: pervasive, end-to-end encryption can quickly make indiscriminate surveillance impossible on a costeffective basis. The result is that governments are likely to fall back to traditional, targeted surveillance founded upon an individualized suspicion. Governments cannot risk the discovery of their exploits by simply throwing attacks at every “endpoint,” or computer processor on the end of a network connection, in the world. Mass surveillance, passive surveillance, relies upon unencrypted or weakly encrypted communications at the global network level.

    Come molti esperti del settore ripetono da tempo, la cifratura dei dati è utile; per citare un esempio, si veda il discorso di Mikko Hyppönen sulla NSA. (altro…)

  • Perfect Forward Secrecy

    Il protocollo HTTPS come è implementato da molti siti o browser ha un problema con il futuro.

    Ipotizzando che qualcuno stia registrando tutto il traffico HTTPS di un sito adesso potrebbe solamente avere in mano dei dati illeggibili. Ma cosa succederebbe se venisse trafugata la chiave segreta, oppure se un domani i computer riuscissero in poche settimane a scardinare la chiave utilizzata?

    C’è un passaggio fondamentale nei primi millisecondi del protocollo HTTPS:

    Il browser, verificato il certificato, invia un messaggio al server che contiene un altro numero casuale cifrato con la chiave pubblica del server

    Quindi, chi riuscisse a calcolare o trafugare la chiave privata del server potrebbe decifrare tutto il traffico HTTPS protetto con quella coppia di chiavi, ipoteticamente salvato negli anni, che fino a quel momento non era decifrabile (retrospective decryption).

    Lo scambio di una chiave segreta condivisa su un canale non sicuro è un problema non nuovo. Whitfield Diffie, Martin Hellman e Ralph Merkle avevano trovato una soluzione già negli anni ’70 del secolo scorso elaborando quello che poi sarebbe diventato il protocollo Diffie-Hellman per lo scambio di chiavi (brevetto US4200770 ora scaduto).

    Anche in questo caso bisogna fare un passo indietro per vedere come funzionano le cose dietro le quinte.

    (altro…)

  • Postfix: forzare il dialogo cifrato fra due MTA

    È possibile forzare il dialogo cifrato TLS tra due server di posta elettronica (MTA).

    Di seguito viene spiegato come farlo con Postfix 2.10.2, l’ultima disponibile, compilata sul server in cui gira con il supporto TLS attivato. È naturalmente possibile ottenere lo stesso risultato anche con altri MTA o con versioni precedenti di Postfix (sconsiglio di scendere sotto la 2.6.0 ed è meglio evitare il range  2.9.0 – 2.9.5 (incluse) perché hanno un baco nel calcolo del fingerprint della chiave pubblica.

    È fondamentale una certa padronanza con Postfix, che viene data per scontata dalla procedura descritta di seguito.

    (altro…)

  • La chiave di volta della sicurezza HTTPS

    Molti siti popolari stanno passando per default alle comunicazioni via HTTPS.

    Se per un sito ospitato su un solo server dedicato è un’operazione banale, Per una grossa organizzazione non è un’impresa semplice.

    Passare in HTTPS non risolve ogni problema di sicurezza sia perché è un protocollo soggetto ad attacchi (qui e qui) sia perché esiste comunque un single point of failure.

    La chiave privata.

    (altro…)

  • Certificato SSL: perché no?

    I certificati SSL sono oramai disponibili anche a prezzi assai abbordabili.

    Da NameCheap (uso quel fornitore come esempio, ma si trovano anche altrove) si possono prendere i Comodo a 7,95 dollari/anno o i GeoTrust a 9,49 dollari/anno. Con questi prezzi la domanda da porsi è se abbia ancora senso usare dei certificati auto emessi.

    Ci sono situazioni in cui i certificati di questo tipo non possono essere utilizzati. Ad esempio, se si vuole certificare non un host, ma tutti gli host di un intero dominio si sale di prezzo di un ordine di grandezza.

    (altro…)

  • Verifica dei certificati SSL

    Uno studio ha dimostrato che non è una bella idea verificare i certificati con chiamate alle librerie, ma è meglio delegare il compito a chi lo sa far bene, come il browser.

    Il problema risiede nel modo in cui vengono utilizzate le API delle librerie, non si tratta, quindi, di una vulnerabilità intrinseca delle librerie medesime.

    Secondo lo studio citato, le diverse API SSL espongono funzioni di basso livello e non offrono la possibilità di chiamare una serie di funzioni cappello con pochi e chiari parametri che permettono di effettuare la verifica di un certificato in maniera affidabile. Spesso i programmatori, vuoi per leggerezza, vuoi per poca informazione, interpretano male la documentazione delle funzioni e finiscono per commettere errori che espongono gli applicativi a vulnerabilità serie.

    Un’ipotesi formulata dalla pubblicazione è che in almeno un caso, quello dell’applicazione Android di Chase Bank, la vulnerabilità introdotta a livello applicativo sia il retaggio di un codice di test che bypassa la verifica del certificato rimasto per errore anche nel codice finale. (via Bruce Schneier)