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? OoSubmission (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