Alberto Bartoli - Blog

(8 Agosto: cambiato il titolo) Due eventi recenti molto interessanti. Kazakhstan government is now intercepting all HTTPS traffic In Kazakhistan, ogni utente può navigare su Internet solo dopo avere inserito il Governo tra le Certification Authority fidate dai propri dispositivi. Ciò implica che il Governo del Kazakhistan può operare da Man-In-The-Middle nei confronti di tutte le comunicazioni HTTPS, quelle "crittate" che usiamo ogni giorno: può cioè  vedere  e  modificare   tutto  ciò che viene trasmesso  nei due sensi . Ripeto, può vedere e modificare le comunicazioni crittate. Spiegare i dettagli tecnici è troppo lungo...specialmente per una mattina di fine luglio...se uno ha la pazienza di leggere la dispensa "Security" del corso di Reti di Calcolatori trova tutti i dettagli. Peraltro, penso che questa azione renda impossibile, in Kazakhistan, l'uso del browser Chrome e di molte app per smartphone (per motivi tecnici inadatti a fine luglio.....

Lasciatemi dire che è una piccola soddisfazione...nonché un altro esempio di  sfera di cristallo . Pochi giorni fa  hanno accettato un nostro lavoro ad una importante conferenza internazionale di sicurezza informatica: we developed a methodology for detecting fraudulent pages within trusted sites , that is, pages created by attackers within web sites of trusted organizations and placed at URLs at which no page is supposed (by the administrators of those sites) to exist.  ... The problem is highly relevant for many reasons, including: HTTPS does not provide any defense in this respect (the fraudulent pages are hosted on sites that, from HTTPS point of view, are authenticated and with content integrity); Pochi minuti fa, un grande Internet provider inglese, probabilmente il più grande provider al mondo, ha pubblicato un  blog post  in cui informa che sul sito della Polizia della Malesia è in corso un attacco di phishing  proprio del genere indica...

Nella lezione di ieri abbiamo descritto HTTPS, il protocollo utilizzato comunemente per accedere a servizi autenticati (GMail, Facebook, banche, acquisti on line, etc). Abbiamo evidenziato che di norma il web server espone il form nel quale inserire le credenziali attraverso HTTPS. Ciò sembra inutile, in quanto non c'è nessun vantaggio nell'imporre che la richiesta di prelievo del form e lo stesso form viaggino con garanzia di riservatezza. La riservatezza è necessaria solo per la richiesta inviata subito dopo avere prelevato il form, cioè per la richiesta che contiene le credenziali. Questa slide sintetizza il motivo per il quale prelevare il form su HTTPS sembra inutile ma non lo è: Secondo molti esperti, nel 2011 il governo della Tunisia ha forzato tutti gli Internet provider del paese a modificare i form esposti su HTTP dai servizi "importanti" (GMail, Facebook etc). Nelle pagine contenenti i form venivano aggiunte, durante il transito dal server al browser,...

Ci risiamo... Adobe security chief Brad Arkin has warned that hackers have managed to create malicious files with Adobe's digital code-signing signature. According to a blog post published on Thursday, the issue appears to have been the result of hackers compromising a vulnerable build server Adobe plans next week to revoke the certificate for all code signed before July 10, 2012... (più precisamente: butta via la propria chiave privata e chiave pubblica, poi chiede alla propria CA di revocare il certificato che associa Subject=Adobe a quella chiave pubblica) However, even when a CA (Certificate Authority) revokes a certificate for an abused private key, any digital signature made before the revocation date will remain valid. Ogni volta che parlo di queste cose non manco di evidenziare questi problemi.  Vedi anche questo post .

L'update di Windows di stamani contiene una revoca di certificati ( "update to the certificate revocation list" ). Questo update è anche necessario al fine di "keep your systems certificate list up to date" . Questa frasetta in apparenza innocua ("vabbé, uno dei soliti aggiornamenti") nasconde in realtà qualcosa di molto delicato ed importante. L'update infatti serve a rimuovere dal TrustSet alcuni Issuer Microsoft (!). Ripeto: serve a rimuovere dal TrustSet alcuni Issuer Microsoft. Spero sia chiaro a tutti cosa significhi. L'update riferisce un articolo della Knowledge Base Microsoft identificato con KB2718704. Cercando questo identificatore su Google si trova un security advisory emesso da Microsoft proprio ieri: Microsoft is aware of active attacks using unauthorized digital certificates derived from a Microsoft Certificate Authority. An unauthorized certificate could be used to spoof content, perform phishing attacks, or perf...

Chiunque abbia seguito uno dei miei corsi sulle applicazioni pratiche della crittografia a chiave pubblica ha: sentito ripetere fino alla nausea che tutte si basano su tre ipotesi, che se le ipotesi non sono verificate allora non c'è nessuna garanzia, che soddisfare una ipotesi può essere difficile o meno ma è sempre un atto di fede etc etc etc. certamente pensato: "Bartoli è un pò fissato con queste cose". Rivest, la "R" di RSA ed uno dei tre inventori della crittografia a chiave pubblica, ha sottolineato di recente più o meno le stesse cose con le quali martello gli studenti da anni: Rivest, a professor at MIT and one of the inventors of the RSA algorithm, said that keeping the corresponding secret keys secret can be just as hard. The assumption that secret keys could be kept private is one of the underlying principles of public-key cryptography, and if it can't be done properly, then the cryptosystems that rely on it can fail. "The assumptio...

Notizia Reuters VeriSign Inc, the company in charge of delivering people safely to more than half the world's websites, has been hacked repeatedly by outsiders who stole undisclosed information from the leading Internet infrastructure company. Commento di Bruce Schneier :  The problem for all of us, naturally, is if the certificate system was hacked, allowing the bad guys to forge certificates. (This has, of course,  happened   before .) Are we finally ready to accept that the certificate system is completely broken?

UPDATE: le conseguenze ci sono, ma sono meno gravi di quanto pensavano... ( http://www.theregister.co.uk/2012/02/21/rsa_crypto_analysis/ ) Fino a qualche anno fa, nel corso di Reti I spiegavo qualche cenno di RSA, il sistema di crittografia a chiave pubblica usato "ovunque", per Internet banking, firma digitale etc. Da quando ho cercato di alleggerire un pò il corso non lo faccio più. Qui si trovano le slide che facevo. Il sistema è strutturato in questo modo : per generare una coppia chiave privata - chiave pubblica si genera una coppia di numeri primi random e molto grandi; questa coppia è nota solo al possessore della chiave privata; la chiave pubblica è il prodotto di questi numeri. In parole poverissime, la sicurezza del marchingegno si basa sul fatto che 1) dato un numero molto grande che sia il prodotto di due numeri primi, trovare questi numeri primi è computazionalmente "exceedingly expensive"; e 2) i numeri primi sono generati in modo sufficientemente ...

Nell'ultima lezione del corso abbiamo detto che in tutte le applicazioni pratiche della crittografia a chiave pubblica  l'associazione tra Subject e KPUB è descritta da dei certificati . La nozione di certificato è molto semplice in prima approssimazione ("la verità dell'associazione è garantita da una terza parte meritevole di fiducia; questa terza parte è la certification authority che ha generato il certificato") ma, come sappiamo, molto complicata nei dettagli. I certificati servono per fare in modo che il castello di garanzie offerte dalla crittografia non sia sostenuto dall'ipotesi "per ogni Subject, l'associazione Subject-KPUB è reale" ma sia invece sostenuto dall'ipotesi "per ogni certification authority CA-X, l'associazione CA-X-KPUB è reale e CA-X genera affermazioni vere" . Si tratta in entrambi i casi di ipotesi, cioè di atti di fede: affermazioni che si considerano vere a priori. Se l'ipotesi è vera allor...

Un malware nascosto in una falsa update di Flash Player è associato ad una firma digitale. Installa un nelle trusted authorities un certificato self-signed per “VeriSign Class 3 Code Signing 2009 CA”. Ovviamente falso. http://www.sophos.com/blogs/sophoslabs/?p=10078

(analisi molto dettagliata, passo-passo, di ciò che accade quando viene aperta una connessione https) Whoa! What just happened? In the 220 milliseconds that flew by, a lot of interesting stuff happened to make Firefox change the address bar color and put a lock in the lower right corner. With the help of Wireshark , my favorite network tool, and a slightly modified debug build of Firefox, we can see exactly what's going on. ... http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

Breve articolo in italiano (scritto da me) di cui consiglio caldamente la lettura a tutti. Il ruolo della crittografia nella sicurezza informatica L’effettivo ruolo della crittografia nelle applicazioni informatiche è spesso frainteso. Si tende infatti a considerare il mero uso della crittografia come sinonimo di “garanzia assoluta di sicurezza”. Purtroppo questa conclusione è del tutto infondata ed in questo breve contributo cercheremo di spiegarne il motivo. In estrema sintesi, la sicurezza di un’applicazione informatica richiede la soluzione di numerosi problemi. La crittografia risolve alcuni di essi ma è del tutto inutile per altri. Nella pratica, gli attaccanti sfruttano proprio i numerosi problemi irrisolti.

Articolo di 4 pagine, molto semplice, accessibile dal portale IEEExplore (ieeexplore.ieee.org, solo dalla rete di ateneo) che descrive un modo semplice per attaccare HTTPS/SSL (protocollo per collegarsi con banche e simili) Man-in-the-Middle Attack to the HTTPS Protocol Callegati, F. Cerroni, W. Ramilli, M. Univ. of Bologna, Bologna; This paper appears in: Security & Privacy, IEEE Publication Date: Jan.-Feb. 2009 Volume: 7, Issue: 1 On page(s): 78...

TinySSL is a Secure Sockets Layer (SSL v2/v3) and Transport Layer Security Web Server Daemon based on TinyWeb. TinySSL comes under the same licence as for TinyWEB and is FREE for commercial and non-commercial use. NOTA: SSL è trattato nella seconda parte del corso; TinySSL è utile, anche senza SSL, per "giocare" con la BASIC authentication (che non è supportata da TinyWeb); se non interessa SSL, saltare tutto e andare direttamente alla: Access Authentication TinySSL supports Basic Access Authentication (rfc-2068), which is configured in realms.cfg file. There are MD5/DES-hybrid hashes (also may be called digests) that allow avoiding cleartext reusable passwords to be stored in realms.cfg file. Each line of the file describes a single realm and has the following format: ListOfURLs RealmName User1 User2 User3 User4 .... ListOfURLs is a list of URLs (pipe-seperated) belonging to specified realm, RealmName is name of the realm as per rfc-2068 and Use...