Di codice aperto e sicurezza

Il prezioso Thierry Riva, ieri mi ha chiesto di chiarire perché dicevo, rapidamente, che è necessario il codice aperto per la sicurezza. Ne è venuto un commento lungo che ho pensato valesse la pena di pubblicare qui, per dargli più visibilità. Commento lungo, ma scritto in fretta: può essere involuto ed oscuro a tratti. Se per te così è, non farmi mancare le tue osservazioni.

Addurre motivi di sicurezza per l’adozione di codice chiuso è la politica della sicurezza tramite all’ascondità (se vogliamo giocare a tradurre con preziosismi). Qui la voce Wikipedia: https://en.wikipedia.org/wiki/Security_through_obscurity
È da larga parte della comunità considerata una posizione assolutamente errata.

Dal punto di vista dell’utente è una posizione assolutamente inaccettabile: come fai a sapere che il programma non sta operando a tuo danno? Devi sorvegliarlo, e sperare di identificare il comportamento sospetto. L’altro giorno ho visto qualcuno dire, per scherzo, che Dropbox, che stava richiedendo molta CPU sulla sua macchina, integra un minatore BitCoin: un’applicazione molto esosa in risorse, che forgia la moneta numeriale Bitcoin. Era una battuta. E se fosse vero? Certo, in questo caso sarebbe davvero difficile: il codice sorgente per il client di Dropbox è a codice aperto, ma in molti altri casi sarebbe assolutamente possibile.
E quando sei, che so, il ministero della difesa francese, e tutti i tuoi computer funzionano con Windows… chi ti garantisce che Microsoft non accede ai tuoi dati per darli agli Stati Uniti? Nessuno. E non ho fatto un esempio a caso.

Dall’altro lato, il codice aperto permette a tutti di guardare: gli utenti possono controllare personalmente cosa installano. Non tutti ne hanno le competenze, certo, ma idealmente un certo numero di loro può e deve, servendo da garanzia nei confronti della comunità.

Quando invece devi garantire la sicurezza di un elemento numeriale, aprire il codice permette a tante paia d’occhi di guardare. Notoriamente quattro occhi vedono meglio di due: ma la cosa continua, e quattrocento vedono ancora meglio. Indubitabilmente il codice aperto pone le condizioni preliminari necessarie per la sicurezza degli utenti e dei prodotti.

Da ultimo consideriamo però la situazione in cui un prodotto chiuso viene venduto in cambio di moneta sonante, mentre uno libero conta solo sulle donazioni. Se il secondo si ritrova in ristrettezze, la qualità del lavoro ne risente. E piano piano inizia a tagliare: prima sul superfluo, poi sul “lusso”, dopo sul non fondamentale, e da ultimo sull’essenziale. Questo è stato il caso di OpenSSL, il cui autore principale faceva la fame. Negli ultimi 10 anni sono finiti dei bachi gravissimi nel codice, che sono stati scoperti e risolti solo recentemente, grazie ad una revisione completa.

12 Commenti

  1. Il grosso problema del sistema delle donazioni e che c’è chi tra grandi vantaggi da questi software senza dare il minimo contributo a chi si è impegnato indirettamente dei interessi di quest’ultimi.
    OpenSSL rientra a pieno in questa casistica, con le aziende che fanno un sacco di soldi con il loro ruolo di CA (certification authority).

  2. Il codice aperto è (nel 90% dei casi) più sicuro. Come chiaramente spiegato nel post, se qualcosa è davanti agli occhi di tutti, beh, tutti possono vedere *cosa* effettivamente fa il software. Purtroppo il codice aperto (anche qui nel 90% dei casi) vuol dire pochi soldi, perché tutti possono prendere il tuo codice e riutilizzarlo (più o meno) a piacere. Le donazioni non bastano mai: per una libreria ENORME come OpenSSL arrivano poche migliaia di dollari ogni anno. Proprio per questo grosse aziende come Google, Facebook, Microsoft, etc. hanno deciso di contribuire economicamente supportando questi grandi progetti (OpenSSL in primis).

    • Benvenuto, Marco!

      Come mai solo nel 90% dei casi? Secondo me è più sicuro sempre. Ovviamente parlo dell’impostazione, non della realizzazione: come ho detto, il codice aperto è, secondo me, il prerequisito per la sicurezza.

      Sì, i soldi non bastano mai, ma del resto è una definizione di base dell’economia: la scarsità è inerente al sistema, le risorse sono sempre limitate e tutto sta nella scelta della loro allocazione.
      Nel caso di SSL i soldi bastavano per andare avanti… male, con l’acqua alla gola e seminando morte e distruzione. Ma considerando l’enorme platea dei beneficiari di questa biblioteca (penso che library sia da tradurre in quest’accezzione) in realtà ci vuole poco per farla funzionare bene. Poco e tanto allo stesso tempo: un cambiamento di mentalità, con consapevolezza responsabile dei beni comuni.

      • Dico nel 90% dei casi per due motivi:
        1 – Il codice open source è (ovviamente) leggibile da tutti, quindi spesso non serve fare reverse engineering disassemblando file binari e leggendo codice Assembly esageratamente difficile da comprendere. Il codice è lì, alla portata di tutti, di solito ben commentato e se si vuole cercare una vulnerabilità nel codice, beh, leggi il codice, testi la vulnerabilità e volendo la puoi vendere a malintenzionati. La superficie di attacco è molto più ampia rispetto ad un sistema chiuso.
        2 – Come già puntualizzava Thierry Riva, dietro ai prodotti commerciali ci sono professionisti pagati fior fior di soldi per fare il loro lavoro. Questi professionisti hanno investito ore e soldi per seguire corsi universitari, master, PhD e corsi di aggiornamento vari e ovviamente vogliono essere pagati. Non gli basta (e direi giustamente), la “gloria” che si ottiene creando un prodotto Open Source di successo.
        Ovviamente anche dietro ai prodotti Open Source ci sono professionisti (penso a Linux, dove i Core Developer sono pagati dalle varie IBM, Intel, Red Hat, Canonical, etc.), ma è comunque una cosa diversa e abbastanza isolata.

        • Allora siamo d’accordo: il codice aperto è -al 100%- prerequisito necessario ma non sufficiente.
          Oh, certo, il problema del sostegno finanziario è fondamentale: lo evocavo per primo, in effetti.

          Le eccezioni sono però abbastanza numerose! Linux, AOSP, Chromium, Opera, tutti i prodotti della Mozilla Foundation, bash, Ubuntu, Open Whisper Systems, TextMate…
          La gloria non basta, assolutamente, ma la soluzione è semplice: basta che finanziamo i prodotti open source che usiamo!

  3. Scusate ma non si é sempre detto che ios è più sicuro di Android?
    Allora non può sostenersi che la sicurezza dipende dalla progettazione?
    In fondo, prima che una nuova versione di ios venga rilasciata sono parecchi gli occhi che la controllano.

    • Sì, si è detto, ma tu credi a tutto quello che “si dice”? 🙂 Al di là di tutto, per quel che ne so non si parlava di questo, quanto del controllo imposto sulle applicazioni e dell’integrazione con i terminali: troppi telefoni Android non sono “seguiti” dai produttori, e questo è **MALE**.
      La sicurezza è multifattoriale, la sicurezza è un processo. Scegliere il codice aperto sta alla radice, alle fondamenta, è un prerequisito. Certo, Apple (ed altri) ha i mezzi per garantire una buona revisione del codice (perché, Google forse no?), ma tante paia d’occhi di Apple sono sempre meno di quelle necessarie (lo prova il Jailbreak, ad esempio). E poi c’è sempre la questione dell’utente: letto qui e l’articolo collegato? http://koolinus.tevac.com/2014/07/23/fyi-for-your-information/

  4. Purtroppo con l’inglese ho qualche difficoltà ma ho afferrato il concetto.
    Sono convinto però che nel futuro ci sarà sempre spazio per i sistemi chiusi, fatti su misura per noi utenti medi che saremmo in grado di prendere virus o altro pure con la più sicura distro di Linux.
    In fondo, sembra che alla gente piaccia essere spiata (Facebook e soci). Ciao

    • Quale passo in inglese ti crea problemi? La pagina di Wikipedia? Hai guardato la versione italiana? Mhh, io ora, ed in effetti è molto stringata: https://it.wikipedia.org/wiki/Sicurezza_tramite_segretezza

      Se non sei pericoloso con OS X, non c’è motivo per cui tu lo sia con Linux. Non farti paura da solo!
      Non credo che la gente si faccia spiare perché le piace, ma perché non ci fa abbastanza caso. La differenza è labile, ma esiste, spero!

  5. Hai ragione, ho fatto un pò di confusione, lo dimostra la mia precedente risposta parlava di “Open source” mentre tu parli di “Codice aperto”.

    Il protocollo TCI/IP che citavo è stato sviluppato come standard aperto, vale a dire che chiunque può prenderlo così com’è e usarlo, ma non mi risulta che ti sia permesso modificarlo come standard.

    Altra cosa è l’Open source e le sue varie licenze (FreeBSD, NetBSD, openBSD, BSD, per citarne solo alcune), che puoi prendere, usare e modificare come ti pare e magari anche fare accettare il codice che hai scritto al detentore del progetto che lo integrerà nella licenza base o una sua variante.

    Personalmente sono contro l’Open source, prevalentemente per ragioni di ordine economico e che proprio per questo non creano codice più sicuro.

    Alla base di prodotti “sicuri” c’è sempre un team molto competente, una base utenti che ne faccia parte per garantire alle informazioni di risalire la gerarchia e migliorare e correggere il codice in un processo continuo.
    Il grande pericolo del codice “Open source” è la mancanza di fondi che porta inesorabilmente a una mancanza di risorse, in casi estremi alla fuga delle vere menti pensanti e di riflesso al decadimento del codice.

    Al limite si potrà pensare che sul lungo periodo vi sono maggiori probabilità di codice sano in un progetto “open source”.
    La mia convinzione resta che la qualità del lavoro di chi è correttamente retribuito e motivato produce una migliore qualità di codice.

    Ciao.

    • Grazie delle risposte, Thierry.
      Dunque, sgombriamo il campo agli equivoci: io parlo di “codice aperto” per il mio vezzo di usare l’italiano. Mi spiace che questo ti induca a credere che c’è una distanza rispetto all’open source (ossia letteralmente, sorgente aperta) perché non è così, ti chiedo scusa.

      Il protocollo TCI/IP lo puoi pure modificare, ma buona fortuna, se non è l’IETF a modificarlo, per farlo adottare da chiunque! E poi quando si modificano gli standard, anche a livello ufficiale, come per IPv6, che fa evolvere IPv4, non è facile fare adottare da tutti la novità. Nessuna differenza con le varie licenze che dici tu: solo che, essendo un protocollo per la comunicazione… se non hai nessuno con cui comunicare perché sei il solo ad adottarlo…

      È vero: l’insicurezza economica mina i progetti con codice aperto. Ma è un problema facile da cambiare, perché la causa ne siamo noi stessi! Non sta scritto da nessuna parte che chi scrive codice aperto faccia la fame. E del resto non è così per Linux (il cui finanziamento è affidato alla Linux Foundation), per Firefox, Thunderbird e tutti i prodotti Mozilla, per Chromium, Android… sono tanti i progetti open source sostenuti adeguatamente. Spesso da una grossa società, ma non necessariamente: come ricorda Stallman, codice aperto non significa “prodotto gratuito”.

  6. Pingback: Ad occhi chiusi | Signor D

Lascia un commento

I campi richiesti sono evidenziati con *.