Alfonso Maruccia

SSL, il più grosso pericolo del mondo connesso

Ricercatori statunitensi descrivono il più diffuso sistema di trasmissione dati in sicurezza come fortemente a rischio di attacchi man-in-the-middle. La colpa non è dei programmatori, però, bensì delle API e delle librerie

Roma - Le potenziali insicurezza della tecnologia SSL (Secure Socket Layer) rappresentano un grosso problema per le comunicazioni telematiche fuori dal browser, e in questo caso non si parla solo di banali app per Android ma di un gran numero di software di importanza critica responsabili del trasferimento dati in rete.

A identificare l'ennesima, problematica insicurezza di SSL sono due ricercatori statunitensi (University of Texas di Austin e Stanford University), che arrivano a definire la validazione dei certificati SSL nel software fuori dal browser web come il più pericoloso codice del mondo.

Client di instante messaging, applicazioni business che si interfacciano alle reti di e-payment di PayPal e Amazon, il numero e la qualità dei programmi affetti dal problema sono a dir poco preoccupanti. E non si tratta (almeno, non soltanto) del codice scritto per i suddetti software, dicono i ricercatori: il problema sono le librerie standard usate per implementare le comunicazioni SSL.
JSSE, OpenSSL oppure GnuTLS, niente si salva dal difetto strutturale di complicare la vita al programmatore offrendo API con un design pessimo e una scelta di opzioni confusa. Il risultato è sempre lo stesso: i programmatori implementano la validazione dei certificati SSL in maniera errata o comunque potenzialmente vulnerabili a pericolosi attacchi di tipo man-in-the-middle.

Per provare la loro teoria, i ricercatori sono riusciti a far accettare dai software in oggetto tre diverse tipologie di certificati fasulli: un certificato auto-firmato con il nome corretto, un certificato auto-firmato con un nome casuale e uno proveniente da un'autorità valida ma concesso al dominio errato ("AllYourSSLAreBelongto.us"). La soluzione a questo ennesimo problema è evidente, dicono gli esperti: fornire ai programmatori librerie e interfacce più chiare e con funzionalità di log degli errori maggiormente consistenti.

Alfonso Maruccia
Notizie collegate
  • SicurezzaAndroid, quando l'SSL va stortoUn gran numero di app androidi è vulnerabile ad attacchi di tipo man-in-the-middle, dicono i ricercatori, a causa di cattive implementazioni delle comunicazioni su standard SSL
26 Commenti alla Notizia SSL, il più grosso pericolo del mondo connesso
Ordina
  • Sinceramente mi stupisco che qualcuno qui si stupisca (scusate il giro di parole). La rete, già agli albori, non è stata concepita pensando alla sicurezza, e quelli non più tanto giovani se lo dovrebbero ricordare.
    - "Internet si for porn" - Occhiolino
    non+autenticato
  • Why you think the net was born?
    non+autenticato
  • LOL, se ne sono accorti ora?

    Queste "ricerche" mi fanno più ridere che piangere.

    Io nemmeno ci provo ad accedere al sito della mia banca via browser, preferisco andarci e farmi la coda che devo fare piuttosto che dare carta bianca a chi il danno sa farlo e vuole farlo.

    Se poi considerare che a TANTE banche gli scadono i certificati SSL e "abituano" gli utenti a ignorare quelle schermate: risultato? un banale attacco man in middle sui certificati farebbe tranquillamente intercettare il traffico ad un attaccante senza nessuno sforzo
    non+autenticato
  • E, giusto per precisare, non pensiate che le chiavette RSA siano la salvezza perché non lo sono affatto!

    Infatti nel momento in cui sto "sniffando" il traffico per via dell'attacco man in middle, posso:
    - far passare il mio traffico tramite il sistema che fa lo sniffing
    - acquisire il codice RSA inserito e riusarlo

    ^^
    non+autenticato
  • Quanto è brutta l'ignoranza che fa venì er mal di panza. I numeri RSA non sono riusabii e scadono dopo circa 30 secondi.
    Qundi anche se intercetti la comunicazione non puoi fare come ti pare.
    Continua ad andare in banca a piedi che è meglio disconnettiti da internet che campi meglio. Oppure passa a banche leggermente più serie.
    La mia non mi direbbe mai vai avanti ugualmente se il certificato è scaduto.
    Comunque la ricerca è inutile senza i dettagli. E' come dire che tutti gli italiani sono gay.
    non+autenticato
  • e tu hai idea in 30 secondi che fine possono fare i tuoi dati ?

    Mi ricordo di pochi mesi fà che ho visto il sito di una banca che
    mostrava il form di login sulla Home Page IN CHIARO ! ! !

    e ti chiedeva anche il famoso numerino RSA...

    morale con un banale maninthemiddle potevo riprodurre la pagina della banca,
    1) prendere una prima volta i tuoi codici per fare il login,
       rispondendoti "codici errati, riprovare"
    2) prendere di nuovo i tuoi codici al secondo tentativo e usarli per
       far partire un bel bonifico...
    3) mostrarti un messaggio del tipo "problemi di connessione, riprovare
       tra 60 minuti...

    e in tanto il bonifico viaggiava...
  • - Scritto da: orlangio
    > e tu hai idea in 30 secondi che fine possono fare
    > i tuoi dati
    > ?
    >
    > Mi ricordo di pochi mesi fà che ho visto il sito
    > di una banca
    > che
    > mostrava il form di login sulla Home Page IN
    > CHIARO ! !
    > !

    Per curiositá , quando é successo e con che banca ?
    non+autenticato
  • NOTA: la mia non è una istigazione a delinquere...
    mi pare questa, e non hanno ancora corretto...

    http://www.intesasanpaolo.com/scriptIbve/retail20/...
  • <iframe id="ifrmloginweb20" scrolling="no" src="https://www.intesasanpaolo.com/script/Login2Servle..." ......</iframe>

    HTTPS Occhiolino
    non+autenticato
  • certo, certo, https://.... SICURISSIMO ! !

    c'è scritto dentro la pagina della banca...

    dentro la pagina originale...

    ma se a te invece arriva la pagina di dot.lupin, che fai ?

    vai a vedere/analizzare il codice html prima di fare INVIO ?

    Zero Cultura della sicurezza informatica,
    per me sarebbero da denunciare...

    Comunque purtroppo il 90% delle persone neanche verifica se la pagina è
    in HTTPS od è HTTP...
  • - Scritto da: orlangio
    > e tu hai idea in 30 secondi che fine possono fare
    > i tuoi dati
    > ?

    > e ti chiedeva anche il famoso numerino RSA...

    nel mio caso il pin viene usato sui pagamenti non al login, e ti assicuro che anche avessi rubato il pin con user e pwd non è proprio banale preparare una transazione ex novo in pochi secondi
    non+autenticato
  • - Scritto da: Saltimbanco
    > il pin con user e pwd non è proprio banale
    > preparare una transazione ex novo in pochi
    > secondi
    Ci sono software che fanno miracoli!!! Basta fare da proxy in modo da bloccare la richiesta del client dandogli un finto messaggio di ok e fare la propria transazione con il pin RSA che non va riusato ma va usato perchè i pin rsa non sono riusabili
    non+autenticato
  • - Scritto da: daniele_dll _rosica
    > - acquisire il codice RSA inserito e riusarlo
    >
    > ^^

    DelusoDelusoDelusoDelusoDeluso ritira subito quello che hai detto DelusoDelusoDelusoDelusoDeluso
    non+autenticato
  • Il sottotitolo dice una cosa (sbagliata)... l'articolo dice il contrario. L'api può essere anche confusa o dal "pessimo design" ma la colpa alla fine è del programmatore che scrive il codice e non lo verifica. Parola di un programmatore.
    non+autenticato
  • Già... poi si fa presto a sparare nel mucchio. Quale browser sono vulnerabili? Quali applicazioni? Tutte quelle che usano openssl? Dipende dalle librerie o dalle applicazioni?
    Insomma o l'articolo di PI è inutile oppure lo è la ricerca, vado ad informarmi meglio
    non+autenticato
  • - Scritto da: Ignoranza
    > Già... poi si fa presto a sparare nel mucchio.
    > Quale browser sono vulnerabili? Quali
    > applicazioni? Tutte quelle che usano openssl?
    > Dipende dalle librerie o dalle
    > applicazioni?
    > Insomma o l'articolo di PI è inutile oppure lo è
    > la ricerca, vado ad informarmi
    > meglio

    Bravo, se ti fossi informato prima, avresti capito che non si parla di browser.

    https://crypto.stanford.edu/~dabo/pubs/abstracts/s...
    non+autenticato