[#36711] [Ruby 1.9 - Bug #4821][Open] Random Segfaults (in start_thread?) — Ivan Bortko <b2630639@...>

22 messages 2011/06/03

[#36730] [Ruby 1.9 - Feature #4824][Open] Provide method Kernel#executed? — Lazaridis Ilias <ilias@...>

56 messages 2011/06/04

[#36750] [Ruby 1.9 - Feature #4830][Open] Provide Default Variables for Array#each and other iterators — Lazaridis Ilias <ilias@...>

24 messages 2011/06/05

[#36785] [Ruby 1.9 - Feature #4840][Open] Allow returning from require — Rodrigo Rosenfeld Rosas <rr.rosas@...>

53 messages 2011/06/06
[#36811] Re: [Ruby 1.9 - Feature #4840][Open] Allow returning from require — Yusuke ENDOH <mame@...> 2011/06/07

Hello,

[#36799] [Ruby 1.9 - Feature #4845][Open] Provide Class#cb_object_instantiated_from_literal(object) — Lazaridis Ilias <ilias@...>

11 messages 2011/06/06

[#36834] [Ruby 1.9 - Feature #3905] rb_clear_cache_by_class() called often during GC for non-blocking I/O — Charles Nutter <headius@...>

10 messages 2011/06/08
[#36860] Re: [Ruby 1.9 - Feature #3905] rb_clear_cache_by_class() called often during GC for non-blocking I/O — Eric Wong <normalperson@...> 2011/06/08

Charles Nutter <headius@headius.com> wrote:

[#36863] Object#trust vs Object#taint — Aaron Patterson <aaron@...>

Hi,

16 messages 2011/06/08
[#36866] Re: Object#trust vs Object#taint — Yukihiro Matsumoto <matz@...> 2011/06/08

Hi,

[#36873] Re: Object#trust vs Object#taint — Aaron Patterson <aaron@...> 2011/06/09

On Thu, Jun 09, 2011 at 07:49:06AM +0900, Yukihiro Matsumoto wrote:

[#37071] [Ruby 1.9 - Feature #4877][Open] Unify Variable Expansion within Strings — Lazaridis Ilias <ilias@...>

12 messages 2011/06/12

[#37106] ruby core tutorials location — Roger Pack <rogerdpack2@...>

Hello all.

10 messages 2011/06/13
[#37107] Re: ruby core tutorials location — Jon <jon.forums@...> 2011/06/13

> Hello all.

[#37115] Re: ruby core tutorials location — Roger Pack <rogerdpack2@...> 2011/06/13

> Rather than adding links to source code, I would prefer the wikibooks link and others under a new Tutorials section of http://www.ruby-lang.org/en/documentation/ as well as adding http://ruby.runpaint.org/ to the existing Getting Started section.

[#37117] Re: ruby core tutorials location — Jon <jon.forums@...> 2011/06/13

> > Rather than adding links to source code, I would prefer the wikibooks link and others under a new Tutorials section of http://www.ruby-lang.org/en/documentation/ as well as adding http://ruby.runpaint.org/ to the existing Getting Started section.

[#37128] Re: ruby core tutorials location — Roger Pack <rogerdpack2@...> 2011/06/14

> I like what you're trying to do and see how great that tutorial connection from rdoc/yard could be, say, mixing with existing ruby-doc.org and rubydoc.info. ut I question embedding source links to info in which the info can easily grow outdated or abandoned as time passes. I also question the ongoing maintenance burdens.

[#37137] Re: ruby core tutorials location — Jon <jon.forums@...> 2011/06/14

> > I like what you're trying to do and see how great that tutorial connection from rdoc/yard could be, say, mixing with existing ruby-doc.org and rubydoc.info. ut I question embedding source links to info in which the info can easily grow outdated or abandoned as time passes. I also question the ongoing maintenance burdens.

[#37164] [Ruby 1.9 - Feature #4890][Open] Enumerable#lazy — Yutaka HARA <redmine@...>

30 messages 2011/06/16

[#37170] [Ruby 1.9 - Bug #4893][Open] Literal Instantiation breaks Object Model — Lazaridis Ilias <ilias@...>

61 messages 2011/06/16

[#37207] [Ruby 1.9 - Feature #4897][Open] Define Math::TAU and BigMath.TAU. The "true" circle constant, Tau=2*Pi. See http://tauday.com/ — Simon Baird <simon.baird@...>

43 messages 2011/06/17

[#37286] [Ruby 1.9 - Bug #4916][Open] [BUG] Segmentation fault - dyld: lazy symbol binding failed: Symbol not found: _ASN1_put_eoc — Hiroshi NAKAMURA <nakahiro@...>

9 messages 2011/06/22

[#37324] [Ruby 1.9 - Bug #4923][Open] [ext/openssl] test_ssl.rb: test_client_auth fails — Martin Bosslet <Martin.Bosslet@...>

19 messages 2011/06/23

[#37576] [Ruby 1.9 - Feature #4938][Open] Add Random.bytes [patch] — Marc-Andre Lafortune <ruby-core@...>

13 messages 2011/06/27

[#37612] [Ruby 1.9 - Bug #4941][Open] cannot load such file -- rubygems.rb (LoadError) — Lazaridis Ilias <ilias@...>

25 messages 2011/06/28

[ruby-core:37691] [Ruby 1.9 - Feature #4481][Feedback] Add client_ca method to OpenSSL::SSLSocket

From: Martin Bosslet <Martin.Bosslet@...>
Date: 2011-06-30 15:17:48 UTC
List: ruby-core #37691
Issue #4481 has been updated by Martin Bosslet.

Category set to ext
Status changed from Closed to Feedback
Assignee changed from Martin Bosslet to Hiroshi Nakamura

Just added Ippei's patch. I took the liberty to add a sentence to RDoc pointing out that in contrast to SSLContext#client_ca=, where we set X509::Certificates, the newly added SSLSocket#client_ca will only return an array of X509::Names.

I looked at how this is used internally by OpenSSL and as it turns out this list seems neither to be checked nor used at all during the handshake except for sending the list to the client. This means that it would be perfectly possible to send any list of certificates to the client, no matter if they're actually trusted or not. As a consequence, this means that it is the programmer's duty to keep this list correct and meaningful with respect to the actually trusted X509::Certificates.

This made me wonder - wouldn't it be nicer to have the list pre-populated with the CA certificates of the underlying X509::Store that serves as the basis for client certificate validation to have a meaningful default setting? Should the need arise to have a custom setting (e.g. sending a filtered subset of the trusted CA's in specific situations), developers would still be able to do so by overriding the default list using SSLContext#client_ca= on the server side.

Another thing I don't like too much is that since the list is not checked internally it would also be possible to send untrusted CAs to the client. Although this is not undermining the security it still makes no sense since a client using a certificate issued by an untrusted CA would ultimately get rejected anyway. But nevertheless, I'd feel better if we forbid such silly things right away. Since we only use SSL_CTX_add_client_CA(SSL_CTX *ctx, X509 *cacert) for feeding the client CA list in ext/openssl, it would be possible for us to actually verify that those CA certificates are 

a) contained in the list of trusted CA certificates or
b) at least that they are trusted intermediate certificates whose certificate path leads up to a trusted root being among the trusted CAs. 

Wouldn't this be better? Or am I overlooking anything?

What do you guys think? Should one or both of these features added to what we have right now? If you think so, I would open a new ticket so this one can be closed.

PS: (I'll add further tests once we concluded on the topic, I just added a very basic test for now).
----------------------------------------
Feature #4481: Add client_ca method to OpenSSL::SSLSocket
http://redmine.ruby-lang.org/issues/4481

Author: Ippei Obayashi
Status: Feedback
Priority: Normal
Assignee: Hiroshi Nakamura
Category: ext
Target version: 1.9.3


=begin
Please add "client_ca" method to OpenSSL::SSLSocket to solve the following problem.

Problem:
If a SSL server decide to authenticate clients using client-certificates,
the server can send the list of client CAs to a client as a hint, and
the client can use the list to select an appropriate certificate.
But the current ruby's ext/openssl does not have the API to access the list.

Solution:
Add a wrapper function for SSL_get_client_CA_list.

Two patches (new method and test) are attached to this message.
=end



-- 
http://redmine.ruby-lang.org

In This Thread

Prev Next