Un recente studio condotto in collaborazione tra ricercatori della Stanford University e della University of Texas at Austin ha permesso la pubblicazione di un documento riguardante la validazione dei certificati SSL (Secure Sockets Layer) nelle applicazioni non-browser, un pratica basata secondo gli autori su quello che potrebbe essere definito "The most dangerous code in the world" (il codice più pericoloso al Mondo).
Supportati da una ricca documentazione, gli accademici hanno effettuato una approfondita analisi su quello che di fatto è considerato lo standard per la protezione delle comunicazioni attraverso la Rete; lo studio è stato concentrato in particolare sul ruolo svolto da SSL nel contrasto agli attacchi di tipo man-in-the-middle, cioè quelle incursioni in cui un terzo, solitamente malevolo, riesce ad interferire sulle comunicazioni tra due soggetti.
>> Leggi: Attacco man-in-the-middle con Cain
SSL è stato concepito in modo da rappresentare un'ultima barriera di protezione per i dati in transito, così, anche nel caso in cui una rete dovesse essere compromessa e finire sotto il controllo remoto di utenti malintenzionati, il protocollo dovrebbe comunque essere in grado di garantire che lo scambio di informazioni tra client e server sia integro e autentico.
Secondo i ricercatori, questa dinamica presenterebbe una passaggio critico al momento dell'autenticazione del server, cioè nella fase in cui quest'ultimo presenta il suo certificato per stabilire una connessione SSL; perché quest'ultima possa ritenersi sicura, spetterà al client verificare che il certificato proposto sia genuino, cioè rilasciato da un'autorità per la certificazione, non revocato e corrispondente al dominio di riferimento.
Ora, secondo la tesi esposta, l'implementazione di SSL nei browser Web darebbe luogo a continui aggiornamenti per la correzione dei bug via via identificati, in questo modo i vendor riuscirebbero a mantenere un livello di sicurezza perlomeno accettabile dal punto di vista della navigazione su Internet.
Ma SSL viene utilizzato anche in numerose applicazioni non-browser che richiedono connessioni sicure, è per esempio il caso dell'autenticazione ai server da parte di Apps mobile per Android o iOS, dell'utilizzo di servizi per l'archiviazione e la sincronizzazione multi-dispositivo tramite cloud computing o dei trasferimenti di informazioni relative ad acquirenti e acquisti sulle piattaforme di commercio elettronico.
Ora, sulla base di quanto proposto dagli autori, le applicazioni non-browser avrebbero il loro punto di debolezza nel fatto di non presentare una propria implementazione di SSL, ma di utilizzare soluzioni (OpenSSL, GnuTLS, JSSE..) e librerie (cURL, Apache HttpClient..) di terze parti sulle quali i vendor non avrebbero pieno controllo. Tale problema riguarderebbe anche servizi particolarmente importanti nei settori del cloud hosting e nella fornitura di gateway per il pagamento.
Le soluzioni a tale problema potrebbero risiedere nella concezione di API più solide per SSL, nella creazione di uno standard per le verifiche tecniche sull'utilizzo corretto delle librerie SSL e nello sviluppo di strumenti di analisi più avanzati per l'individuazione degli errori; passi fondamentali per un settore, quello delle applicazioni non-browser che accedono alla Rete, in continua espansione.
