- nexa - server-nexa.polito.it

Berkman Center Webcast live oggi ore 18 - Intellectual Privacy

by Giuseppe Futia

Intellectual Privacy http://cyber.law.harvard.edu/events/luncheon/2015/04/Richards <http://cyber.law.harvard.edu/events/luncheon/2014/06/sigal> *with author Neil Richards* Today, 6.00 pm Webcast live: http://cyber.law.harvard.edu/interactive/webcast http://nexa.polito.it/berkman-webcast-live Why is it bad when the government or companies monitor our reading or web-surfing? We have intuitions that this kind of surveillance is bad, but have failed to explain why digital monitoring in an age of terror and innovation is really a problem. In Intellectual Privacy, Neil Richards offers a new way of thinking about monitoring of our thinking, reading, and communications, one that ensures that our ideas and values keep pace with our technologies. Although we often think of privacy and free speech as being in conflict, Richards shows how privacy and free speech are often essential to each other. He explains the importance of 'intellectual privacy,' protection from surveillance or interference when we are engaged in the processes of generating ideas - thinking, reading, and speaking with confidantes before our ideas are ready for public consumption. In our digital age, in which we increasingly communicate, read, and think with the help of technologies that track us, increased protection for intellectual privacy has become an imperative. A timely and provocative book on a subject that affects us all, Intellectual Privacy will radically reshape the debate about privacy and free speech in our digital age. About Neil Neil Richards is an internationally-recognized expert in privacy law, information law, and freedom of expression. He is a professor of law at Washington University School of Law, an affiliate scholar with the Stanford Center for Internet and Society, a member of the Advisory Board of the Future of Privacy Forum, and a consultant and expert in privacy cases. He graduated in 1997 with degrees in law and history from the University of Virginia, and served as a law clerk to Chief Justice William H. Rehnquist. Professor Richards is the author of Intellectual Privacy (Oxford Press 2015). His many writings on privacy and civil liberties have appeared in many academic journals including the Harvard Law Review, the Columbia Law Review, the Virginia Law Review, and the California Law Review. He has written for a more general audience in Time, Slate, Wired, CNN.com, Forbes, the Boston Review, and the Chronicle of Higher Education. Professor Richards regularly speaks about privacy, technology, and civil liberties throughout the United States and Europe, and also appears frequently in the media. At Washington University, he teaches courses on privacy, free speech, and constitutional law, and is a past winner of the Washington University School of Law's Professor of the Year award. He was born in England, educated in the United States, and lives with his family in St. Louis. He is an avid cyclist and a lifelong supporter of Liverpool Football Club.

April 28, 2015

Paper: "Towards Multilateral Standards for Surveillance Reform"

by J.C. DE MARTIN

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2551164 *Towards Multilateral Standards for Surveillance Reform* Ian Brown University of Oxford - Oxford Internet Institute Morton H. Halperin Open Society Foundations (OSF) Ben Hayes Independent Ben Scott Independent Mathias Vermeulen European University Institute January 5, 2015 Oxford Internet Institute Discussion Paper, January 2015 Abstract: Edward Snowden’s revelations about the mass surveillance capabilities of the United States’ National Security Agency and its partners have created a unique opportunity to work towards the adoption of multilateral human rights-compliant standards for government surveillance conducted against nationals of other countries. This paper attempts to map a path toward new international standards for foreign intelligence collection, in order to achieve increased transparency, control and oversight of national surveillance practices. We provide a basic comparison of the legal frameworks governing foreign surveillance law in the US and selected EU Member States, and set out the applicable international human rights law and major reform initiatives in as far as they relate to foreign surveillance and its oversight. We attempt to identify key issues relevant to all signals intelligence reform efforts and to provide an analytical framework to guide the development of new standards and realistic options for reform. Number of Pages in PDF File: 40 Keywords: surveillance, interception, signals intelligence, international human rights law, FISA, FISA Amendments Act, European Convention on Human Rights, International Covenant on Civil and Political Rights, privacy, sovereignty

April 28, 2015

Ars: "NSA spied on EU politicians and companies with help from German intelligence"

by J.C. DE MARTIN

*NSA spied on EU politicians and companies with help from German intelligence* /Spies failed to check properly what was being passed across to the US./ by Glyn Moody - Apr 24, 2015 10:21am ART Germany's intelligence service, the Bundesnachrichtendienst (BND), has been helping the NSA spy on European politicians and companies for years, according to the German news magazine Der Spiegel. The NSA has been sending lists of "selectors"—identifying telephone numbers, e-mail and IP addresses—to the BND, which then provides related information that it holds in its surveillance databases. According to the German newspaper Die Zeit, the NSA sent selector lists several times a day, and altogether 800,000 selectors have been requested. The BND realized as early as 2008 that some of the selectors were not permitted according to its internal rules, or covered by a 2002 US-Germany anti-terrorism "Memorandum of Agreement" on intelligence cooperation. And yet it did nothing to check the NSA's requests systematically. It was only in the summer of 2013, after Edward Snowden's revelations of massive NSA and GCHQ surveillance, that the BND finally started an inquiry into all the selectors that had been processed. […] Continua qui: http://arstechnica.com/tech-policy/2015/04/24/nsa-spied-on-eu-politicians-a…

April 28, 2015

Re: [nexa] la copia di cortesia... telematica

by Simone Aliprandi

Sì, certo, Stefano. Infatti l'ho segnalato nel mio post. Il problema è però il metodo: si aggiunge (chiamandolo cortesia") a carico degli avvocati un onere che in realtà la legge non richiede. Ed emerge la solita domanda: se gli avvocati caricano una copia in formato "nativo" dell'atto di citazione, chi poi verifica che è proprio uguale a quella depositata invece in cancelleria in cartaceo? (ricordo che stiamo parlando a volte di atti di 40-50 pagine A4). E' tutto il sistema che va ripensato. Un caro saluto, Simone -- Simone Aliprandi - http://www.aliprandi.org | http://www.array.eu Il 27 aprile 2015 14:10, Stefano Quintarelli <stefano(a)quintarelli.it> ha scritto: > questo pero' ha piu' senso, serve per fare il search e le annotazioni... > > > On 27/04/2015 10:58, Simone Aliprandi wrote: >> >> Torno periodicamente sul tema del processo telematico e delle sue >> estrinsecazioni più bizzarre. Adesso arriva anche la copia di cortesia >> TELEMATICA. Ecco il decreto di un giudice monogratico di Salerno: >> >> http://aliprandi.blogspot.it/2015/04/copia-cortesia-telematica-salerno.html >> Un caro saluto. >> -- >> Simone Aliprandi - http://www.aliprandi.org | http://www.array.eu >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >> >> ----- >> Nessun virus nel messaggio. >> Controllato da AVG - www.avg.com >> Versione: 2015.0.5941 / Database dei virus: 4334/9637 - Data di rilascio: >> 27/04/2015 >> >

April 27, 2015

Re: [nexa] la copia di cortesia... telematica

by Stefano Quintarelli

questo pero' ha piu' senso, serve per fare il search e le annotazioni... On 27/04/2015 10:58, Simone Aliprandi wrote: > Torno periodicamente sul tema del processo telematico e delle sue > estrinsecazioni più bizzarre. Adesso arriva anche la copia di cortesia > TELEMATICA. Ecco il decreto di un giudice monogratico di Salerno: > http://aliprandi.blogspot.it/2015/04/copia-cortesia-telematica-salerno.html > Un caro saluto. > -- > Simone Aliprandi - http://www.aliprandi.org | http://www.array.eu > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > ----- > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2015.0.5941 / Database dei virus: 4334/9637 - Data di rilascio: 27/04/2015 >

April 27, 2015

la copia di cortesia... telematica

by Simone Aliprandi

Torno periodicamente sul tema del processo telematico e delle sue estrinsecazioni più bizzarre. Adesso arriva anche la copia di cortesia TELEMATICA. Ecco il decreto di un giudice monogratico di Salerno: http://aliprandi.blogspot.it/2015/04/copia-cortesia-telematica-salerno.html Un caro saluto. -- Simone Aliprandi - http://www.aliprandi.org | http://www.array.eu

April 27, 2015

R: Re : Re: Scatole nere algoritmiche -- e che problema c'è?

by Blengino

>From Resolution 2045 (2015) On Mass Surveillance Parliamentary Assembly of Council of Europe: 19. The Assembly therefore urges the Council of Europe member and observer States to: 19.1. ensure that... the creation of back doors or any other techniques to weaken or circumvent security measures or exploit their existing weaknesses should be strictly prohibited; all institutions and businesses holding personal data should be required to apply the most effective security measures available; Per dire. Buon 25 aprile a tutti C. -----Messaggio originale----- Da: nexa-bounces(a)server-nexa.polito.it [mailto:nexa-bounces@server-nexa.polito.it] Per conto di Stefano Quintarelli Inviato: venerdì 17 aprile 2015 17:53 A: Antonio Casilli Cc: 'nexa' Oggetto: Re: [nexa] Re : Re: Scatole nere algoritmiche -- e che problema c'è? l'articolo dell'epoca diceva che gli ISP dovevano individuare i comportamenti sospetti e decrittare le comunicazioni. queste sono funzioni di polizia da un lato e non vedo come sia possibile decrittare, dall'altro. l'articolo attuale non mi pare dica le stesse cose e non spiega i contorni dell'operazione. c'e' il testo della legge, per capire bene ? ciao!, s. On 17/04/2015 09:23, Antonio Casilli wrote: > Ahinoi per le black boxes non si tratta affatto di perquisizioni a distanza, ma di intercettazioni massive-passive extragiudiziali di tutto il traffico, con vaghe possibilità di ricorso ex post presso (di fatto esautorati) organi di controllo da parte dei FAI. Purtroppo non posso per ragioni di tempo rispondere oggi nel dettaglio a questa mail, ma (giustamente per sapere cosa aspettarsi in discussione della legge intercettazioni) ecco il pezzo di Fabio Chiusi apparso su wired: > http://www.wired.it/attualita/2015/03/22/sorveglianza-digitale-lotta-t > errorismo-perche-nuova-legge-francese-non-modello-imitare/ > > + GoogleTranslation del pezzo di Andrea Fradin, che ha intervistato dei ricercatori in algoritmica p: > https://translate.googleusercontent.com/translate_c?depth=1&nv=1&rurl= > translate.google.com&sl=fr&tl=en&u=http:%2F%2Frue89.nouvelobs.com%2Fno > de%2F258672&usg=ALkJrhgRPtkDyH228H4h9d0qFVLRTTRdkQ > > ----- Mail d'origine ----- > De: Stefano Quintarelli <stefano(a)quintarelli.it> > À: Antonio Casilli <antonio.casilli(a)telecom-paristech.fr>, nexa > <nexa(a)server-nexa.polito.it> > Envoyé: Thu, 16 Apr 2015 21:17:01 +0200 (CEST) > Objet: Re: [nexa] Scatole nere algoritmiche -- e che problema c'è? > > scritto cosi' ci sono ben poche informazioni per dare un giudizio... > > l'emendamento che ho segnalato nella legge del terrorismo prevedeva la > possibilita' di installare trojan che acquisissero lo stock delle > informazioni presenti nei computer bersaglio. > > questo e' simile ad una perquisizione con la differenza che in questo > caso il sospettato non sa di essere oggetto di perquisizione; altra > differenza e' che si prendono tutti i dati di una vita (come in una > perquisizione), ma questi dati sono molto piu' di dettaglio (nel > fisico magari conservi le lettere alla morosa e le bollette, non i > messaggini agli amici e non per tutta la vita) > > cosa ben diversa e' una intercettazione che, per l'appunto, intercetta > il flusso delle conversazioni (non lo stock dei dati) da un certo > momento in poi e per un periodo limitato. > > entrambe le fattispecie sono limitate per quanto riguarda le ipotesi > di reato in cui possono essere disposte, e sono disposte da un giudice. > > un giudice domani decide che si devono intercettare tizio e caio per > una ipotesi di reato e le loro conversazioni e SMS che si scambiano, > per un periodo limitato di tempo, vengono registrati ed archiviati, > per un periodo limitato di tempo. > > ovviamente quando viene decisa una intercettazione, a differenza della > perquisizione, la decisione e' segreta (mica diciamo all'imputato > "guarda che ti stiamo intercettando") > > le informazioni nel post indicato da Antonio (grazie!) fanno intuire > che trattasi di cosa piu' simile ad una intercettazione, con la > differenza che non si consoce il contenuto, in quanto cifrato. meno > invasivo quindi rispetto ad una intercettazione normale. > > si intuisce anche che non tutto il traffico viene intercettato ma solo > una parte sulla base di criteri (che come nelle intercettazioni devono > necessariamente essere segreti). > > l'importante e' che cio' avvenga per un periodo limitato, arcivhiato > per un periodo limitato, e disposto da un giudice, ed attuabile per > un limitato numero di ipotesi di reati gravi. > > ripeto il "si intuisce", perche' non ci sono elementi sufficienti nel post. > > se invece fosse deciso non da un giudice, per qualunque fattispecie di > reato, per un tempo indefinito, ed intercettasse e registrasse tutto > il traffico in transito (ma mi pare tecnicamente assai arduo, to say > the least), beh, allora sarebbe decisamente una cosa grave. > > se qualcuno ha elementi in piu', il tema mi interessa, dato che tra > poco avremo da parlare di intercettazioni, alla Camera. > > ciao!, s. > > > On 16/04/2015 13:39, Antonio Casilli wrote: >> Dear all, >> >> ieri, in piena notte e in presenza di appena 30 deputati, l'Assemblée Nationale francese ha approvato l'emendamento più pericoloso della Legge Intelligence ("Loi renseignement") attualmente in discussione: quello sulla istallazione di "scatole nere" presso i fornitori d'accesso internet, per intercettare dei pattern di "comportamenti sospetti" sulla base di algoritmi non sottoposti a controllo democratico (v. mia mail del 30 marzo scorso). >> >> Un post di un informatico franco-italiano vi aiuterà a comprendere dov'è il problema e per quale motivo la cosa concerne l'Italia. >> >> http://signord.tevac.com/2015/04/16/declinazioni-nazionali-sorveglian >> za/ > >> >> Per quelli che invece vogliono fare lo sforzo immane di usage Google Translate, ecco una selezione di articoli degli ultimi giorni: >> - Le Monde >> http://www.lemonde.fr/pixels/article/2015/04/15/pourquoi-la-loi-sur-l >> e-renseignement-cristallise-les-critiques_4615766_4408996.html >> - Le Nouvel Obs >> http://rue89.nouvelobs.com/2015/04/15/lalgorithme-gouvernement-sera-i >> ntrusif-inefficace-prouve-258672 >> - Numerama >> http://www.numerama.com/magazine/32809-l-assemblee-adopte-les-boites- >> noires-qui-surveilleront-votre-comportement.html >> - Il sito NextInPact fa dei rendiconto in tempo reale del dibattito >> (agghiacciante) all'Assemblée Nationale >> http://www.nextinpact.com/news/93837-loi-renseignement-compte-rendu-t >> roisieme-journee-debats.htm >> >> Nel frattempo, la lista degli oppositori a questa legge, che già >> contava magistrati, poliziotti, la CNIL, Human Rights Watch, la Lega >> dei Diritti dell'Uomo, Amnesty International, da ieri conta anche il >> World Wide Web Consortium: >> https://twitter.com/w3c/status/588372724805951488 >> >> > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > _______________________________________________ nexa mailing list nexa(a)server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

April 25, 2015

Re: [nexa] "Please consider the impacts of banning HTTP" (issue #107 di WhiteHouse/https su GitHub)

by Fabio Pietrosanti (naif) - lists

On 4/24/15 7:27 PM, Simone Basso wrote: > > Voi cosa ne pensate? Condivido in particolare il punto che la maintenance sia decisamente maggiore e che questo sia un problema legato alla gestione dei certificati digitali, che richiede interventi manuali fatti con una certa periodicità (oltre a costi). Solo quando abilitare HTTPS e gestire il certificate-lifecycle sarà interamente automatizzato con un approccio machine-to-machine sarà possibile una diffusione pervasiva dell'uso di TLS/SSL. Con l'ACME protocol [1] del progetto letsencrypt [2] queste problematiche dovrebbero risolversi. [1] https://github.com/letsencrypt/acme-spec [2] https://letsencrypt.org/getinvolved/ -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi

April 24, 2015

Re: [nexa] "Please consider the impacts of banning HTTP" (issue #107 di WhiteHouse/https su GitHub)

by Alessio Melandri

Grazie Simone per aver affrontato questo tema. Mi lasciano perplesso alcune argomentazioni di @jhourcle. In particolare "Non-sensitive web traffic does exist." Se scarico un dataset, chessò il dump di Wikipedia, secondo la sua ipotesi, è traffico non sensibile. Tuttavia IMHO lo diventa sul lungo periodo, quando tracciando le abitudini e le configurazioni del browser mi pare si riesca perfino, con una buona percentuale, a identificare un utente che gira su TOR. Qui la questione è intedersi su cosa sia sensibile e non mi scandalizzerei se la risposta fosse *tutto*. Mi è piaciuto invece il voler rimarcare la catena di effetti causata dall'aumento dell'elaborazione dovuto all'HTTPS. Acutizza il digital divide (IMHO solo dove già presente; con un livello decente di banda l'effetto sull'utente finale è poco percettibile) ma anche e oserei dire soprattutto, è una scelta con un forte impatto ecologico. Questo ci mostra che certi software strategici hanno un grande impatto sui consumi mondiali. Come se dall'oggi al domani, con un numero relativamente piccolo di modifiche, si facessero inquinare le automobili attualmente in circolazione di un offset in più. Condivido i rischi legati alla sicurezza ma li vedo anche come una buona opportunità. Specie nel software libero, c'è una correlazione tra quanto si "stressa" una libreria e la sua qualità. Alessio Melandri 2015-04-24 19:27 GMT+02:00 Simone Basso <bassosimone(a)gmail.com>: > Cari tutti, > > tl;dr ho sempre pensato che il traffico HTTP dovrebbe sempre essere > cifrato. Alcune discussioni e articoli letti recentemente mi hanno > fatto capire che il problema e' piu' complesso e articolato, e voglio > convidere con voi quello che ho letto e alcune mie riflessioni. > > Qualche giorno fa ho letto sulla lista NNSquad una email (in calce a > questo messaggio) che penso possa essere utile per trollare^W^W^W > parlare un po' dei costi della crittografia su questa lista. > > La parte piu' interessante di questa email era in realta' una > discussione probabilmente destinata ad andare ancora avanti: > > "Please consider the impacts of banning HTTP": > > https://github.com/WhiteHouse/https/issues/107 > > La discussione viene aperta da Joe Hourclé (@jhourcle), "webserver e > database admin" presso il Solar Data Analysis Center della NASA. > > La discussione ruota attorno alla policy del governo americano che > mira a fare usare HTTPS a tutti i siti del governo: > > > The American people expect government websites to be secure and their > > interactions with those websites to be private. Hypertext Transfer > > Protocol Secure (HTTPS) offers the strongest privacy protection > > available for public web connections with today’s internet technology. > > The use of HTTPS reduces the risk of interception or modification of > > user interactions with government online services. > > > > This proposed initiative, “The HTTPS-Only Standard,” would require the > > use of HTTPS on all publicly accessible Federal websites and web > services. > > > > https://https.cio.gov/ > > Il nucleo dell'argomentazione di @jhourcle e' che HTTPS ha senso per > proteggere informazioni personali; dove non sono coinvolte informazioni > personali, si puo' decidere caso per caso se usare HTTPS oppure se sia > meglio continuare ad usare HTTP. Ossia che la policy "migriamo tutto > ad HTTP adesso" sia eccessivamente strict. > > In particolare @jhourcle sostiene che i dati scientifici sono dati non > sensibili che possono passare in chiaro (magari firmati), che ci sono > dei costi infrastrutturali nel servire grosse quantita' di dati usando > HTTPS, che usando HTTPS aumenta la superficie d'attacco, che ci sono dei > problemi non tanto di migrazione quanto di maintenance. > > Per quanto riguarda i problemi di maintenance, in particolare, @jhourcle > puntualizza che: > > > I'm actually less concerned about the deployed and working than in long > > term maintenance. It's pretty typical to get support initially, but then > > resources are re-assigned once things are rolled out, leaving > > departments and projects to deal with the increased workload on their > > own. Consider it like technical debt -- up-front costs may be > > insignificant when you calculate the reoccurring costs > > [...] > > Many of these science tools were written at the beginning of missions > > that have since ended, and there is no funding to maintain them. > > E questo sicuramente e' un primo spunto di discussione, visto come viene > finanziata la ricerca (ma anche l'open source). > > Un altro spunto viene dalle risposte a @jhourcle, alcune delle quali > mettono in luce possibili conseguenze nefaste di non usare HTTPS. > > Ximin Luo (@infinity0) dice in particolare questa cosa molto > convincente: > > > HTTP as commonly used in web browsers, allows javascript injection > > attacks against your users. Even if your website doesn't have any > > "sensitive information", the attacker gains the ability to abuse your > > users for their own purposes. This is how the recent massive attack on > > Github was carried out - someone, ahem, attacked plaintext HTTP > > advertising traffic on seemingly innocent / unsensitive websites, to > > turn those users effectively into a massive botnet for DDoS against > Github. > > Tornando a quello che penso io, come dicevo la mia posizione di base > sull'argomento era "HTTPS sempre". Poi ho cominciato a capire che il > problema e' un po' piu' complesso durante il workshop NNTools2015 > (http://nexa.polito.it/nntools2015) che abbiamo organizzato qui a Nexa. > > Mi aveva colpito in particolare la presentazione del prof. Marco Mellia > (Politecnico di Torino) relativa al suo paper sui costi di HTTPS: > > > Researchers from CMU, Telefonica, and Politecnico di Torino have > > presented a paper at ACM CoNEXT that quantifies the cost of the "S" in > > HTTPS. The study shows that today major players are embracing end-to-end > > encryption, so that about 50% of web traffic is carried by HTTPS. This > > is a nice testament to the feasibility of having a fully encrypted web. > > The paper pinpoints also the cost of encryption, that manifests itself > > through increases in the page loading time that go above 50%, and > > possible increase in battery usage. However, the major loss due to the > > "S" is the inability to offer any in-network value added services, that > > are offered by middle-boxes, such as caching, proxying, firewalling, > > parental control, etc. > > > > > http://www.yro.slashdot.org/story/14/12/04/1513255/the-cost-of-the-s-in-htt… > > Sinceramente non sono molto interessato alla perdita dei servizi "value > added" nella rete, che probabilmente si possono spostare piu' vicini > agli utenti, ma mi interessa invece molto il discorso relativo a quelle > che sono le performance. Leggevo proprio qualche giorno fa che e' > stato abbastanza difficile per Neflix implementare HTTPS, e che hanno > risolto facendo la parte di cifratura simmetrica nel kernel: > > > Netflix will soon use the HTTPS protocol to authenticate and encrypt > > customer streams, a move that helps ensure what users watch stays > > secret [...] "In order to [...] implement TLS functionality, we > > designed a hybrid TLS scheme whereby session management would stay > > in the application space, but the bulk encryption would be inserted > > into the sendfile data pipeline in the kernel" > > > > > http://arstechnica.com/security/2015/04/it-wasnt-easy-but-netflix-will-soon… > > Tra l'altro, proprio nei commenti di questo articolo su Neflix qualcuno > suggeriva che forse non e' il caso di cifrare anche i video, che e' un > po' l'argomentazione di @jhourcle. Pero' non cifrare i video puo' voler > dire rivelare le proprie preferenze non solo, diciamo, a Netflix ma > anche al proprio ISP, e questo puo' dare fastidio. > > Tornando alla cifratura nel kernel, ma anche parlando semplicemente di > libssl, l'aumento della superficie di attacco, e' una argomentazione > interessante, che rimarra' vera finche' non salira' la qualita' delle > librerie che implementano SSL. Una variante "light" di questo > scetticismo verso SSL l'avevo gia' letta tempo fa nei sorgenti di Very > Secure FTP daemon (il che non significa che se lo dicono anche loro sia > giustificato lo scetticismo, ma che non e' un'opinione isolata). > > > vsftpd-2.0.0 introduces SSL / TLS support using OpenSSL. OpenSSL is > > a massive quantity of code which is essentially parsing complex > > protocol under the full control of remote malicious clients. SSL / > > TLS is disabled by default, both at compile time and run time. This > > forces packagers and administrators to make the decision that they > > trust the OpenSSL library. I personally haven't yet formed an opinion > > on whether I consider the OpenSSL code trustworthy. > > > > https://security.appspot.com/vsftpd/TRUST.txt > > Voi cosa ne pensate? > > Grazie per l'attenzione, > > Simone Basso > http://nexa.polito.it/people/sbasso > > > -------- Forwarded Message -------- > Subject: [ NNSquad ] Negative impact of HTTPS-only on agencies with > nonsensitive data > Date: Mon, 20 Apr 2015 08:32:51 -0700 > From: Lauren Weinstein <lauren(a)vortex.com> > To: nnsquad(a)nnsquad.org > > > Negative impact of HTTPS-only on agencies with nonsensitive data > > This is actually an extremely interesting discussion about the > potential impacts of a U.S. government HTTPS-only initiative on > underfunded government agencies with massive amounts of nonsensitive > legacy data -- in this case, NASA. Do read: > > "Please consider the impacts of banning HTTP": > > https://github.com/WhiteHouse/https/issues/107 > > - - - > > --Lauren-- > Lauren Weinstein (lauren(a)vortex.com) http://www.vortex.com/lauren > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Member: ACM Committee on Computers and Public Policy > Lauren's Blog: http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >

April 24, 2015

"Please consider the impacts of banning HTTP" (issue #107 di WhiteHouse/https su GitHub)

by Simone Basso

Cari tutti, tl;dr ho sempre pensato che il traffico HTTP dovrebbe sempre essere cifrato. Alcune discussioni e articoli letti recentemente mi hanno fatto capire che il problema e' piu' complesso e articolato, e voglio convidere con voi quello che ho letto e alcune mie riflessioni. Qualche giorno fa ho letto sulla lista NNSquad una email (in calce a questo messaggio) che penso possa essere utile per trollare^W^W^W parlare un po' dei costi della crittografia su questa lista. La parte piu' interessante di questa email era in realta' una discussione probabilmente destinata ad andare ancora avanti: "Please consider the impacts of banning HTTP": https://github.com/WhiteHouse/https/issues/107 La discussione viene aperta da Joe Hourclé (@jhourcle), "webserver e database admin" presso il Solar Data Analysis Center della NASA. La discussione ruota attorno alla policy del governo americano che mira a fare usare HTTPS a tutti i siti del governo: > The American people expect government websites to be secure and their > interactions with those websites to be private. Hypertext Transfer > Protocol Secure (HTTPS) offers the strongest privacy protection > available for public web connections with today’s internet technology. > The use of HTTPS reduces the risk of interception or modification of > user interactions with government online services. > > This proposed initiative, “The HTTPS-Only Standard,” would require the > use of HTTPS on all publicly accessible Federal websites and web services. > > https://https.cio.gov/ Il nucleo dell'argomentazione di @jhourcle e' che HTTPS ha senso per proteggere informazioni personali; dove non sono coinvolte informazioni personali, si puo' decidere caso per caso se usare HTTPS oppure se sia meglio continuare ad usare HTTP. Ossia che la policy "migriamo tutto ad HTTP adesso" sia eccessivamente strict. In particolare @jhourcle sostiene che i dati scientifici sono dati non sensibili che possono passare in chiaro (magari firmati), che ci sono dei costi infrastrutturali nel servire grosse quantita' di dati usando HTTPS, che usando HTTPS aumenta la superficie d'attacco, che ci sono dei problemi non tanto di migrazione quanto di maintenance. Per quanto riguarda i problemi di maintenance, in particolare, @jhourcle puntualizza che: > I'm actually less concerned about the deployed and working than in long > term maintenance. It's pretty typical to get support initially, but then > resources are re-assigned once things are rolled out, leaving > departments and projects to deal with the increased workload on their > own. Consider it like technical debt -- up-front costs may be > insignificant when you calculate the reoccurring costs > [...] > Many of these science tools were written at the beginning of missions > that have since ended, and there is no funding to maintain them. E questo sicuramente e' un primo spunto di discussione, visto come viene finanziata la ricerca (ma anche l'open source). Un altro spunto viene dalle risposte a @jhourcle, alcune delle quali mettono in luce possibili conseguenze nefaste di non usare HTTPS. Ximin Luo (@infinity0) dice in particolare questa cosa molto convincente: > HTTP as commonly used in web browsers, allows javascript injection > attacks against your users. Even if your website doesn't have any > "sensitive information", the attacker gains the ability to abuse your > users for their own purposes. This is how the recent massive attack on > Github was carried out - someone, ahem, attacked plaintext HTTP > advertising traffic on seemingly innocent / unsensitive websites, to > turn those users effectively into a massive botnet for DDoS against Github. Tornando a quello che penso io, come dicevo la mia posizione di base sull'argomento era "HTTPS sempre". Poi ho cominciato a capire che il problema e' un po' piu' complesso durante il workshop NNTools2015 (http://nexa.polito.it/nntools2015) che abbiamo organizzato qui a Nexa. Mi aveva colpito in particolare la presentazione del prof. Marco Mellia (Politecnico di Torino) relativa al suo paper sui costi di HTTPS: > Researchers from CMU, Telefonica, and Politecnico di Torino have > presented a paper at ACM CoNEXT that quantifies the cost of the "S" in > HTTPS. The study shows that today major players are embracing end-to-end > encryption, so that about 50% of web traffic is carried by HTTPS. This > is a nice testament to the feasibility of having a fully encrypted web. > The paper pinpoints also the cost of encryption, that manifests itself > through increases in the page loading time that go above 50%, and > possible increase in battery usage. However, the major loss due to the > "S" is the inability to offer any in-network value added services, that > are offered by middle-boxes, such as caching, proxying, firewalling, > parental control, etc. > > http://www.yro.slashdot.org/story/14/12/04/1513255/the-cost-of-the-s-in-htt… Sinceramente non sono molto interessato alla perdita dei servizi "value added" nella rete, che probabilmente si possono spostare piu' vicini agli utenti, ma mi interessa invece molto il discorso relativo a quelle che sono le performance. Leggevo proprio qualche giorno fa che e' stato abbastanza difficile per Neflix implementare HTTPS, e che hanno risolto facendo la parte di cifratura simmetrica nel kernel: > Netflix will soon use the HTTPS protocol to authenticate and encrypt > customer streams, a move that helps ensure what users watch stays > secret [...] "In order to [...] implement TLS functionality, we > designed a hybrid TLS scheme whereby session management would stay > in the application space, but the bulk encryption would be inserted > into the sendfile data pipeline in the kernel" > > http://arstechnica.com/security/2015/04/it-wasnt-easy-but-netflix-will-soon… Tra l'altro, proprio nei commenti di questo articolo su Neflix qualcuno suggeriva che forse non e' il caso di cifrare anche i video, che e' un po' l'argomentazione di @jhourcle. Pero' non cifrare i video puo' voler dire rivelare le proprie preferenze non solo, diciamo, a Netflix ma anche al proprio ISP, e questo puo' dare fastidio. Tornando alla cifratura nel kernel, ma anche parlando semplicemente di libssl, l'aumento della superficie di attacco, e' una argomentazione interessante, che rimarra' vera finche' non salira' la qualita' delle librerie che implementano SSL. Una variante "light" di questo scetticismo verso SSL l'avevo gia' letta tempo fa nei sorgenti di Very Secure FTP daemon (il che non significa che se lo dicono anche loro sia giustificato lo scetticismo, ma che non e' un'opinione isolata). > vsftpd-2.0.0 introduces SSL / TLS support using OpenSSL. OpenSSL is > a massive quantity of code which is essentially parsing complex > protocol under the full control of remote malicious clients. SSL / > TLS is disabled by default, both at compile time and run time. This > forces packagers and administrators to make the decision that they > trust the OpenSSL library. I personally haven't yet formed an opinion > on whether I consider the OpenSSL code trustworthy. > > https://security.appspot.com/vsftpd/TRUST.txt Voi cosa ne pensate? Grazie per l'attenzione, Simone Basso http://nexa.polito.it/people/sbasso -------- Forwarded Message -------- Subject: [ NNSquad ] Negative impact of HTTPS-only on agencies with nonsensitive data Date: Mon, 20 Apr 2015 08:32:51 -0700 From: Lauren Weinstein <lauren(a)vortex.com> To: nnsquad(a)nnsquad.org Negative impact of HTTPS-only on agencies with nonsensitive data This is actually an extremely interesting discussion about the potential impacts of a U.S. government HTTPS-only initiative on underfunded government agencies with massive amounts of nonsensitive legacy data -- in this case, NASA. Do read: "Please consider the impacts of banning HTTP": https://github.com/WhiteHouse/https/issues/107 - - - --Lauren-- Lauren Weinstein (lauren(a)vortex.com) http://www.vortex.com/lauren Founder: - Network Neutrality Squad: http://www.nnsquad.org - PRIVACY Forum: http://www.vortex.com/privacy-info Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info Member: ACM Committee on Computers and Public Policy Lauren's Blog: http://lauren.vortex.com Google+: http://google.com/+LaurenWeinstein Twitter: http://twitter.com/laurenweinstein Tel: +1 (818) 225-2800 / Skype: vortex.com

April 24, 2015