Bugzilla – Full Text Bug Listing
| Summary: | Use HTTPS for download.eclipse.org | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Martin Kamp Jensen <martin.kamp.jensen> | ||||
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | b.michael, contact, david_williams, demiobenour, denis.roy, dennis.huebner, dlazerka, Ed.Merks, fedor.brunner, gunnar, Jonathan.Leitschuh, mamacdon, markus.kell.r, mikael.barbero, mn, pascal, richard.birenheide, sascha | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=507657 https://bugs.eclipse.org/bugs/show_bug.cgi?id=435426 https://bugs.eclipse.org/bugs/show_bug.cgi?id=550999 |
||||||
| Whiteboard: | |||||||
| Bug Depends on: | 423715 | ||||||
| Bug Blocks: | 435426, 450195, 509332 | ||||||
| Attachments: |
|
||||||
|
Description
Martin Kamp Jensen
There are two inherent problems with this: 1. download.e.o moves a _lot_ of traffic. About 90% of our bandwidth, so I'm not sure what impact this would have on the server's processors. I'm sure it would be maintainable, but I need to approach with caution. 2. Our mirrors do not use https. If download.e.o supports https and that is viewed as a good thing, folks could stop using mirrors, which will end up costing us a ton more bandwidth. I'm not opposed to to the idea; au contraire, I agree this should be done, but before flipping the switch I think some investigation needs to be done. The friends mirror can be used right now to download over https. Of course, you must become a Friend of Eclipse :) http://friends.eclipse.org/ I'd support Martin strongly for the following reason: When using tycho for Eclipse Maven builds one has to to specify a target platform to compile against. Unfortunately I could not dig up a Nexus repository to build against (which typically serve via https), eg. for Luna, therefore I have to resort to a target definition pointing to download.eclipse.org. For build integrity reasons it would be good to be able to fetch via https. N.B. Ideal solution for my problem would be to have product builds in central Maven but I am not sure if this is the right place to offload this. Some opinions on SSL cost: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html https://www.imperialviolet.org/2011/02/06/stillinexpensive.html (In reply to Richard Birenheide from comment #3) > Some opinions on SSL cost: You may have missed comment #1. About 90% of Eclipse's bandwidth needs are handled by our free mirror sites, most/all of which do not support SSL. So although the cost of using SSL for download.eclipse.org traffic may seem negligible, the cost of supporting all our downloads on SSL is quite gigantic. And if we enable SSL on download.eclipse.org there will be increased incentive to use it instead of the mirrors. *** Bug 464884 has been marked as a duplicate of this bug. *** Couple of ideas on resolving this issue: 1. Can we force/recommend/create incentive for the mirrors to use HTTPS as well? 2. Serve at least checksums over HTTPS. 3. Add digital signature. Even over HTTP it cannot be faked. 4. Don't serve downloads through main site at all, only checksums. Some projects learned importance of serving downloads over HTTPS the hard way. For example, Linux Mint was recently breached, and after that they moved to HTTPS -only. They don't serve their downloads at all, only through mirrors, but they serve checksums over HTTPS. And in general, idea "We don't improve our website because users would start using it more" sounds strange to me. I'd second Dzmitry strongly here. Maybe one can point mirrors to https://letsencrypt.org/. (In reply to Dzmitry Lazerka from comment #6) > Couple of ideas on resolving this issue: > 1. Can we force/recommend/create incentive for the mirrors to use HTTPS as > well? > 2. Serve at least checksums over HTTPS. > 3. Add digital signature. Even over HTTP it cannot be faked. > 4. Don't serve downloads through main site at all, only checksums. We have a central checksum service on HTTPS://www.eclipse.org If you see some projects not using it, they should. We don't require it. > And in general, idea "We don't improve our website because users would start > using it more" sounds strange to me. It should sound strange since that is not what I said. :) If download.eclipse.org cannot be served over HTTPS, the best alternative is to have a small download script be downloaded from https://eclipse.org, and have this script (which includes an embedded SHA256/SHA384/SHA512/Blake2b/Skein/etc hash, but not MD5 or SHA1 which are insecure) do the actual downloading. It is important that the process of checking the hash be automated. Also, I think that all downloads from Eclipse should be digitally signed, and that all tools that download from Eclipse should verify the digital signature. This includes e.g. the Eclipse IDE. This is really the only solution in the presence of mirrors. (In reply to Dzmitry Lazerka from comment #6) > Couple of ideas on resolving this issue: > 2. Serve at least checksums over HTTPS. It is the easiest way to go - start serving p2 metadata files only over HTTPS. Unfortunately, the whole checksum story is kind a broken: - the only message digest algo supported by p2 is MD5 - MD5 is broken for quite a some time - current support for checksums in p2 makes it hard to support new message digest algorithms - MD5 generation was broken in Tycho, forcing people to disable checksum generation/consumption completely. See bug #357513 for details, fortunately it has been fixed 2 weeks ago. I'm trying to address p2-related side in bug #423715. Once it is done, it will make sense to serve p2 metadata only over HTTPS. On the other hand, I was told that with the new hardware for download.eclipse.org EF will have enough machine power to switch the whole download.eclipse.org to HTTPS. (In reply to Martin Kamp Jensen from comment #0) > download.eclipse.org is only served via HTTP. For security reasons it should > also (only?) be served via HTTPS. > > We are accessing update sites via download.eclipse.org and need to be sure > that we are in fact downloading from download.eclipse.org. > > Note that eclipse.org already has a wildcard SSL certificate that can also > be used for download.eclipse.org. Could you please highlight the specific security problems you are trying to solve that are not solved by having all the Jars from the release repo be signed? > - the only message digest algo supported by p2 is MD5 > - MD5 is broken for quite a some time Could you please indicate with specific aspect is broken? > - MD5 generation was broken in Tycho, forcing people to disable > checksum generation/consumption completely. See bug #357513 for > details, fortunately it has been fixed 2 weeks ago. Two things: 1) Even though Tycho was not generating the checksums, other tools were able to generate the MD5 and insert those into the artifacts.xml. 2) For the Eclipse release train where all the artifacts are signed, the absence of checksum is not an issue since the signature is checked at download time. (In reply to Pascal Rapicault from comment #12) > > - the only message digest algo supported by p2 is MD5 > > - MD5 is broken for quite a some time > Could you please indicate with specific aspect is broken? These hash and collision attacks have been demonstrated in the public in various situations, including colliding document files and digital certificates. https://en.wikipedia.org/wiki/MD5#Security > > - MD5 generation was broken in Tycho, forcing people to disable > > checksum generation/consumption completely. See bug #357513 for > > details, fortunately it has been fixed 2 weeks ago. > Two things: Both things are true, that's why 'kind a broken' and not 'completely broken'. (In reply to Pascal Rapicault from comment #11) > (In reply to Martin Kamp Jensen from comment #0) > > download.eclipse.org is only served via HTTP. For security reasons it should > > also (only?) be served via HTTPS. > > Could you please highlight the specific security problems you are trying to > solve that are not solved by having all the Jars from the release repo be > signed? Every unencrypted HTTP request reveals information about a user’s behavior, and the interception and tracking of unencrypted browsing has become commonplace. Today, there is no such thing as non-sensitive web traffic, and public services should not depend on the benevolence of network operators. When properly configured, HTTPS can provide a fast, secure connection that offers the level of privacy and reliability that users should expect from government web services. https://https.cio.gov/everything/ See also 435426 for related. *** Bug 509332 has been marked as a duplicate of this bug. *** Created attachment 275245 [details]
"not secure" branding
With the latest Chrome version, Eclipse downloads are now officially branded as "Not Secure".
(moving to Website and removing unrelated dependencies) I'm increasing the severity of this issue because at this point, download.eclipse.org is not even reachable via https, i.e. it's impossible to transfer checksums over an integral, secure connection. IMHO this should have a higher priority. What is the current plan to provide https for d.e.o.? Do the concerns from 2014 still apply? https://download.eclipse.org for the first time. This has been implemented. Hi Eclipse Team, I'm reaching out asking for your support on the initiative to formally deprecate the download of dependencies over HTTP by January 15th, 2020. The full scope of my research is captured in this article I published on June 10th titled 'Want to take over the Java ecosystem? All you need is a MITM!' https://medium.com/bugbountywriteup/want-to-take-over-the-java-ecosystem-all-you-need-is-a-mitm-1fc329d898fb?source=friends_link&sk=3c99970c55a899ad9ef41f126efcde0e As a part of this research project I reached out to some of the most used artifact server owners in our industry: Sonatype of Maven Central, Pivotal of Spring, RedHat, and JFrog of JCenter bintray. I discussed with them that one way to resolve this issue is to shut down the HTTP (port 80) endpoint, thus breaking insecure builds that could be maliciously compromised. Sonatype agreed to this and will moving forward with the depreciation on January 15th, 2020. https://central.sonatype.org/articles/2019/Apr/30/http-access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/ JFrog has also agreed to also do this, as has Pivotal. I would appreciate it if the Eclipse Foundation followed the rest of the industry in this initiative and formally deprecated the HTTP port for download.eclipse.org and any/all other artifact servers operated by the Eclipse Foundation. If the Eclipse foundation will publish a blog post about joining this initiative, I'm happy to include a link to it in the Gradle 6.0 release notes. Jonahtan, this ticket (about enabling https) has been resolved. Please open a new one if you want to discuss the deprecation of http. Thanks. |