Website inaccessible in Chrome, ssl cert mismatch

[bf4]

You attempted to reach www.rubygems-openpgp-ca.org, but instead you actually reached a server identifying itself as *.herokuapp.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of www.rubygems-openpgp-ca.org.

You cannot proceed because the website operator has requested heightened security for this domain.

[bf4]

Created issue at source repo https://github.com/grant-olson/rubygems-openpgp-ca.org/issues/15

[grant-olson]

I stopped paying heroku $20 a month due to lack of use. The rubygems-openpgp-ca.org site is essentially deprecated. rubygems-openpgp is sitll being maintained.

For now, if you want to see the site, you can either go to the http version of the site or https here: http://desolate-spire-6189.herokuapp.com/

I do need to update links in documentation though, so I'll leave the issue open until that happens.

More info here:

http://www.rubygems-openpgp-ca.org/blog/nobody-cares-about-signed-gems.html

[bf4]

Ok.. so your thoughts on including this in the rubygems security guide? https://github.com/rubygems/guides/pull/70

[bf4]

The http version redirects me

[grant-olson]

I'm able to view the http version two different browsers here: http://www.rubygems-openpgp-ca.org/

[grant-olson]

I'm not sure what to say regarding the rubygems security guide itself, but I'll provide some general direction of where I'm coming from these days. To provide some background...

I never liked the default signing mechanism. The biggest problem in my mind was that there's no easy way to authenticate the certificate as things are currently implemented because all certificates are self-signed. Second biggest problem is that once you trust a certificate and sign off on it, you now trust it globally. You add the certificate for the foobar gem, the foobar author can now sign a forged rails gem and your system will silently accept it.

So I wrote rubygems-openpgp originally as a proof-of-concept to allow you to sign gems with OpenPGP. The advantage being that you can push the authentication chains to the existing keyserver network, and you can distinguish between two different types of trust "I trust this certificate to sign this gem" and "I trust this certificate to authenticate other certificates."

The proof of concept floated around with no-one using it. After the rubygems.org hack earlier this year, there was some new interest in signing in general and the gem. At that time I improved the code and made it production ready.

One of the big complaints against rubygems-openpgp was that an average user can't easily get into the strong set. This is of course a red-herring. You don't need to be in the strong set to take advantage of OpenPGP sigs, and you can do CA-style authentication in that environment.

So rubygems-openpgp-ca.org was born. It was intended to be a proof-of-concept for a CA style model on top of the gem. It was an attempt to bootstrap a simple way where the average user could actually authenticate people's certificates on a basic level. As detailed in the link above, the CA never got much use and without critical mass from gem authors it isn't useful to gem users.

So back to the present...

I still think rubygems-openpgp can be useful without the CA element for people interested in using it. At this point in time, I think intro documentation shouldn't use the CA keys. I think basic user documentation should tell users how to perform basic authentication of a gem based on the author's key only.

1. gpg --recv-keys 0xDEADBEEF

2. hand-wavy out-of-band authentication. Verify you have the right key and fingerprint by looking at github or author's website or comparing whatever.

3. Sign the author's key normally in gpg gpg --lsign 0xDEADBEEF
4. Now import the gem with trust gem install deadbeef --trust

This is more analogous to the instructions for X.509 sigs and bypasses the whole CA issue for now.

Documentation directed at gem authors should show them how to sign a gem, and should also provide some instructions on how to communicate to users what the authentic key is. For example I always include a few lines in the bottom of my readmes. See https://github.com/grant-olson/stackdriver-ruby for an example.

Thanks for your interest. If I can provide any more assistance, let me know.

[bf4]

Thanks for the great response.

So, you'd still advocate using the trust flag, but not with the cert authority, as the best way to go, at present. Is there any advantage to not using the trust flag, but still using verify?

Do you think I should take the entire openpgp section out? I will add your caveat to gem cert being too global. Would you mind commenting there?

[grant-olson]

So here's the thing. You need three components to properly authenticate the gem:

1. A checksum that validates the integrity of the package.
2. A digital signature that validates the checksum.
3. From a signing key that you've authenticated as legitimate.

The first two parts are easy. That's just using the crypto libraries. The third part is the part that Really Hard™. It's also the critical part. IMO the signature is worthless if you can't validate it came from an authentic source. Which is why chrome gave you a nasty browser warning earlier today.

The difference between --trust and --verify is that --verify only does steps 1 and 2.

In that sense its usefulness is limited. However, it probably does as much as the normal signing when used by most users. It will also do the continuity checks like ssh does when a key changes, so I guess there's some benefit in doing that.

OTOH, if people just start blindly signing keys without doing any real authentication so that they can use the --trust flag, that's not really any better off either. So a checklist that just tells people to run gpg --lsign so --trust works probably isn't helpful because it doesn't get into the implications of what signing a key actually means.

To be honest, rubygems-openpgp isn't anywhere close to being an accepted standard, with a half-dozen users or so. I don't know if it belong the official guides at this point. As much as I want people to use it, this probably comes off as more of an endorsement than it should be. It might be better to add a note that rubygems-openpgp exists with a link rather than writing out detailed instructions in the official guides.

[bf4]

Will remove all but a mention that it's not recommended