Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Using self signed certificates for plugins: the certificate is not stored?

Yeah, the thing is, I was expecting Eclipse to work like a web browser (or even an SSH client), which basically allows the user to, like you said, add the untrusted certificate to a store of trusted certificates. If one has to do that manually with the command-line, that's not user-friendly at all.
Not to mention adding it to the JVM store is arguably not an entirely correct technical solution: it would make the certificate trusted for all Java apps, not just that Eclipse instance (some users might find that too much of a broad scope - I would).
Purchasing a certificate from a certificate authority wouldn't be the way to go either, as I hear this is fairly expensive, and all the Eclipse projects I'm working on are open-source projects, with volunteer contributors.

Seems there was already some discussion about this in bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=440430
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340345

Since a few users complained about the possibility of Man-In-Middle-Attacks, my best solution is to ask users to use HTTPS for the update-site URL. (the update site is hosted on Github, so I don't need to get my own certificate for that). However, I did this in the past and some users reported either performance problems, or other strange failures when trying to update/install using HTTPS (especially users from China)


On Thu, Feb 25, 2016 at 10:53 PM, Tom Bryan (tombry) <tombry@xxxxxxxxx> wrote:
General background: 

There is a certificate store of trusted certificates from certificate authorities.  When you purchase a code signing certificate, the issuer will verify that you are who you say your and sign your certificate with their signature, establishing a chain of trust: https://en.wikipedia.org/wiki/Chain_of_trust.  If an application encounters a certificate that is not in its certificate store and does not have a chain of trust based on one of the certificates in the certificate store, then you'll get a warning.  You can choose to ignore that warning.

To prevent the user from getting a warning when he encounters that same (untrusted) certificate again, the user has to add the certificate to his certificate store.  In some cases, like with your web browser, the application may give the user the ability to add the untrusted certificate to a store of trusted certificates.  If the app doesn't provide that option, the user will need to perform those steps separately, using OS or application-specific tools.

For Eclipse: 

I don't remember whether Eclipse is just checking against the JVM's cacerts certificate store or whether it eventually goes back to the operating system's certificate store somehow.  I believe that it's *only* checking the JVM's certificate store.  If that's true, then you just need to follow instructions for importing certificates to the JVM.  For example, 

---Tom

On 2/25/16, 2:20 PM, "tycho-user-bounces@xxxxxxxxxxx on behalf of Bruno Medeiros" <tycho-user-bounces@xxxxxxxxxxx on behalf of bruno.do.medeiros@xxxxxxxxx> wrote:

Perhaps I should be asking this in the "Eclipse Platform" forum, as it's not directly Tycho related (I think), but I thought to give it a try:

I've modified the Tycho build script to sign my plugin jars. I'm using a self-signed certificate. When I try to install the plugins, the Eclipse installer asks me, the user, if I want to trust that certificate for the installation. So far so good.

Thing is, I'd expect once the user accepts the certificate as valid, Eclipse wouldn't ask again in future installations signed with the same certificate. But it does. I've made a new release of the plugins and the installer asks again if I trust the certificate.

This seems to me to defeat the whole point, since for the user to trust that the new plugin release is from the same source as the previous one, they would have to open the details of the certificate, and manually compare the public key of the previous one to the new one and see that it matches. Obviously this is not practical, they are not gonna check. As as such theoretically someone could create a new self-signed certificate with the same name as mine, and use that to forge fake plugins.

Am I missing something here? Admittedly my knowledge of security stuff is weak. 😓



_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user



--

Back to the top