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-https

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-use-https-to-secure-video-streams/

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@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