Permalink
Browse files

Bundle root certs

  • Loading branch information...
1 parent aa7a254 commit 664e21290a56f67abde9e009a8949f5324ee9350 @sqrrrl sqrrrl committed May 31, 2013
Showing with 2,186 additions and 1 deletion.
  1. +2,183 −0 lib/cacerts.pem
  2. +3 −1 lib/google/api_client.rb
View
@@ -109,8 +109,10 @@ def initialize(options={})
@discovered_apis = {}
self.connection = Faraday.new do |faraday|
- faraday.adapter Faraday.default_adapter
faraday.options.params_encoder = Faraday::FlatParamsEncoder
+ faraday.ssl.ca_file = File.expand_path('../../cacerts.pem', __FILE__)
+ faraday.ssl.verify = true
+ faraday.adapter Faraday.default_adapter
end
return self

5 comments on commit 664e212

@raggi
Member
raggi commented on 664e212 Jun 10, 2013

Please please please don't do this, we should be representing much better than this. It is totally out of line for us to be taking on the responsibility of being an authoritative client CA.

It makes /some/ more sense to bundle just our own cert chain, but bundling these certs is wrong. We also need a well defined process for updating these, and a policy for how and when.

@sporkmonger
Collaborator

My preference would be that this be done only as a fallback if the root CA certs are unavailable from another source.

@sqrrrl
Member
sqrrrl commented on 664e212 Jun 10, 2013

This was done at the request of the security & API teams and is consistent with the libraries for other languages. Java & PHP already bundle the root certificates. The idea is to limit the set of root CAs to those that are authorized to vouch for Google and prevent a compromised or rogue CA from issuing certificates for www.googleapis.com or other related domains and enabling man-in-the-middle attacks.

@raggi - this only affects connections made via the API client and doesn't supplant a system's root CAs for other uses. The certificates included are limited to those Google uses as their own roots.

@raggi
Member
raggi commented on 664e212 Jun 15, 2013

@sqrrrl that's interesting, because it looks more like the curl bundle to me, than the Google authorized CA list.

I think we'd only need:

C=US/O=Google Inc/CN=Google Internet Authority
C=US/O=Equifax/OU=Equifax Secure Certificate Authority

My more pressing question is though, how is this going to be managed for updates? Do old versions of this gem become totally invalid if one of the certs in the chain becomes invalid? How long are released versions of the gem supposed to last?

@raggi
Member
raggi commented on 664e212 Jun 15, 2013

FTR - the reason I'm pressing this, is that I've found at least 4 gems bundling out of date cacert.pems that were obtained by their authors from insecure connections to curl.haxx.se (which did not, at the time of last investigation, even support SSL connections). I really don't want to encourage this in the community.

Please sign in to comment.