"Please consider the impacts of banning HTTP" (issue #107 di WhiteHouse/https su GitHub)
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.
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-http...
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.
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@vortex.com> To: nnsquad@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@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
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@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.
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-http...
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.
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@vortex.com> To: nnsquad@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@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@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
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
participants (3)
-
Alessio Melandri -
Fabio Pietrosanti (naif) - lists -
Simone Basso