On Tue, 23 Oct 2018 at 09:42:54 +0200, Lionel Elie Mamane wrote: > On Tue, Oct 23, 2018 at 07:34:54AM +0200, Guilhem Moulin wrote: >> On Mon, 22 Oct 2018 at 17:25:11 +0200, Lionel Elie Mamane wrote: >>> On Mon, Oct 22, 2018 at 04:33:21PM +0200, Guilhem Moulin wrote: >>>> Might be orthogonal to the git:// vs. https:// vs. ssh:// >>>> discussion. Gerrit uses JGit as Git implementation, while >>>> git-daemon(1) spawns “normal” (C-based) git-upload-pack(1) >>>> processes. > >>> For us developers of LibreOffice, and thus consumers of the Gerrit >>> / Git service of freedesktop.org and TDF, whether the difference >>> comes from the protocol itself or a different git implementation on >>> the server to serve the different protocols is intellectually >>> interesting (thanks for that!), but materially inconsequential: if >>> using git: will be faster, we will use git:. > >> Following the same logic, you want gerrit.libreoffice.org to serve >> content over plain http:// so you can save the two round-trips when >> you launch your browser to submit your reviews? Oo > > Submission (write access) is something else entirely than code > download (read access); the security requirements are massively > different. (Yes, I would prefer to be certain that the code I get is > the right one; however, if I don't and try to submit a patch on top of > code that is not the on in the TDF repo, it will fail. Unless the > attacker also constructed git that exploits SHA collisions?) Another (theoretic) attack vector is to strip a reference from the initial git-upload-pack advertisement so the dev doesn't get a bugfix or something; at least not until said dev relocates to a safer network. > (The above analysis does not apply to gerrit-as-a-website, because > there the link between the code I see and the code I approve is not > on my local machine, but depends on the security of the connection; > and because I don't know how to secure reading but not writing on a > website.) One way is to add https:// to form action fields. Not suggesting that we do that, though :-) If GET requests are served over plaintext links even for authenticated users, then an eavesdropper could sniff session cookies and hijack connections. > If the two round trips are multiplied by many many requests to serve > one operation, then I may notice. Where "operation" is one action for > the user, not one action for the program. E.g., "git fetch", "git > push", One has to pay the the full TLS overhead for each `git fetch` (AFAIK libcurl doesn't do session sharing across processes.). And the full SSH2 overhead for each `git push`, modulo connection multiplexing. > "load a complete web page with all images, javascript, dependencies, > etc", "post an answer to a gerrit change", Login form aside, all content is served from the gerrit box, so a single connection is used to serve all resources on a given page. And our server is configured to cache TLS sessions IDs, so clicking around doesn't cost an extra handshake for each page. >> Things have changed since 2012, encryption is faster (there are >> modern stream ciphers and hardware acceleration is more widespread), >> and for situations like this one there is no reason not to encrypt >> data in transit. > > I would have thought symmetric encryption already wasn't a bottlneck, > at least on the client side (maybe on the server side it was?) in > 2012; I think one could even back then easily saturate a 100Mbps > connection using less than 100% of one core of an entry-level desktop > CPU. You're right, it was probably a few years before that. Perhaps the main changes of the past few years is public perception. For reference, GMail defaulted to https:// in early 2010 [0], Facebook in summer 2013 [1] (feeling the heat of the Snowden leaks?), Wikipedia in early 2015 (2013 for authenticated users) [2] > Many public key crypto operations per seconds is (was?) another issue > altogether. Is, esp. for RSA (we're not using EdDSA currently). -- Guilhem. [0] https://gmail.googleblog.com/2010/01/default-https-access-for-gmail.html https://transparencyreport.google.com/https/overview [1] https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-default/10151590414803920/ [2] https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
