Like OpenSSL::SSL::SSLSocket#connect_nonblock

Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Iñaki Baz Castillo]

Hi, I need something like OpenSSL::SSL::SSLSocket#connect_nonblock but
without raising exceptions, you know ;)

Unfortunatelly it seems that Kgio:SSL is just for servers, am I right?

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I need something like OpenSSL::SSL::SSLSocket#connect_nonblock but
> without raising exceptions, you know ;)
> 
> Unfortunatelly it seems that Kgio:SSL is just for servers, am I right?

See Kgio::SSLConnector, the lib/flipper* stuff uses it for connecting to
SSL servers.  There's no separate API for SSL session establishment in
kgio-monkey, just expect all read/write methods to potentially return
either :wait_readable or :wait_writable.

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Iñaki Baz Castillo]

2012/4/9 Eric Wong <normalperson@yhbt.net>:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> Hi, I need something like OpenSSL::SSL::SSLSocket#connect_nonblock but
>> without raising exceptions, you know ;)
>>
>> Unfortunatelly it seems that Kgio:SSL is just for servers, am I right?
>
> See Kgio::SSLConnector, the lib/flipper* stuff uses it for connecting to
> SSL servers.  There's no separate API for SSL session establishment in
> kgio-monkey, just expect all read/write methods to potentially return
> either :wait_readable or :wait_writable.

Hi Eric, the doc says:

-------------------
Kgio::SSLConnector
Like Kgio::SSL, but for SSL/TLS clients that connect to clients, not
SSL/TLS servers.
-------------------

So, if the doc wrong? maybe it should say:

"Like Kgio::SSL, but for SSL/TLS clients that connect to *servers*,
not SSL/TLS servers."

:)

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Iñaki Baz Castillo]

2012/4/9 Iñaki Baz Castillo <ibc@aliax.net>:
> Hi Eric, the doc says:
>
> -------------------
> Kgio::SSLConnector
> Like Kgio::SSL, but for SSL/TLS clients that connect to clients, not
> SSL/TLS servers.
> -------------------
>
> So, if the doc wrong? maybe it should say:
>
> "Like Kgio::SSL, but for SSL/TLS clients that connect to *servers*,
> not SSL/TLS servers."
>
> :)


BTW:

-------------------
Kgio::SSLConnector.new(io, ssl_ctx, hostname, session = nil)

Initializes and SSL/TLS client socket. Like Kgio::SSL.new, except
hostname is required for verification and session may be specified as
an OpenSSL::SSL::Session object.
-------------------


Two points:

1) The doc should say "Initializes an SSL/TLS client socket." :)

2) What does it mean "hostname is required for verification"? I hope
it does not mean that "hostname" is a required argument and it's
matched against the CommonName field in the server certificate. That
would be a really ugly limitation of certificate validation since
there are other ways to validate a certificate (i.e. SubjectAltName
fields).


Thanks a lot.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 2012/4/9 Iñaki Baz Castillo <ibc@aliax.net>:
> > Hi Eric, the doc says:
> >
> > -------------------
> > Kgio::SSLConnector
> > Like Kgio::SSL, but for SSL/TLS clients that connect to clients, not
> > SSL/TLS servers.
> > -------------------
> >
> > So, if the doc wrong? maybe it should say:
> >
> > "Like Kgio::SSL, but for SSL/TLS clients that connect to *servers*,
> > not SSL/TLS servers."
> >
> > :)

Correct, can you send a patch for this?

> -------------------
> Kgio::SSLConnector.new(io, ssl_ctx, hostname, session = nil)
> 
> Initializes and SSL/TLS client socket. Like Kgio::SSL.new, except
> hostname is required for verification and session may be specified as
> an OpenSSL::SSL::Session object.
> -------------------
> 
> 
> Two points:
> 
> 1) The doc should say "Initializes an SSL/TLS client socket." :)

Also correct, patch? :)

> 2) What does it mean "hostname is required for verification"? I hope
> it does not mean that "hostname" is a required argument and it's
> matched against the CommonName field in the server certificate. That
> would be a really ugly limitation of certificate validation since
> there are other ways to validate a certificate (i.e. SubjectAltName
> fields).

(I'm not remotely close to being an SSL expert, and kgio-monkey includes
 plenty of disclaimers :)

The hostname should be matched against CommonName and/or SubjectAltName

kgio-monkey calls SSL_set_tlsext_host_name() and
OpenSSL::SSL.verify_certificate_identity (for SubjectAltName), so one of
the methods for handling hostname verification _should_ work.

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Iñaki Baz Castillo]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

Hi, I include a patch fixing the doc typos. More inline:

2012/4/10 Eric Wong <normalperson@yhbt.net>:
>> 2) What does it mean "hostname is required for verification"? I hope
>> it does not mean that "hostname" is a required argument and it's
>> matched against the CommonName field in the server certificate. That
>> would be a really ugly limitation of certificate validation since
>> there are other ways to validate a certificate (i.e. SubjectAltName
>> fields).
>
> (I'm not remotely close to being an SSL expert, and kgio-monkey includes
>  plenty of disclaimers :)
>
> The hostname should be matched against CommonName and/or SubjectAltName

This is not entirely true. It is much more complex ;)

I'll show you some code I wrote for my SIP proxy. It's a Ruby script
that gets the SIP identities (domains) in a X.509 certificate (PEM
format). The script output is self descriptive.

I also attach two certificates:

- oversip.net.crt:  A certificate created by me with cool SIP
identities in SubjectAltName.
- github.crt: The certificate from github.com.

Run the script passing as argument each certificate ;)

And note this is just for SIP world, maybe in XMPP it's different, or
in HTTP or whatever. Each protocol specification defines how a server
certificate must be checked.




> kgio-monkey calls SSL_set_tlsext_host_name() and
> OpenSSL::SSL.verify_certificate_identity (for SubjectAltName), so one of
> the methods for handling hostname verification _should_ work.

Hummmm... not sure ;)

Well, I will be much more happy if I can set the certification
validation callback my itself ;)

I've worked too much (yet) with Ruby OpenSSL bindings, but I hope that
it does allow setting my own verification method.


Regards.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I include a patch fixing the doc typos. More inline:

I meant a proper git commit via git format-patch (with commit message,
properly crediting you) so I can just pipe the entire email (or
attachment[1]) to "git am".

> I've worked too much (yet) with Ruby OpenSSL bindings, but I hope that
> it does allow setting my own verification method.

It might be best to come up with working code for Ruby OpenSSL bindings
first.  It's better-supported, at least.

I've never considered kgio-monkey production-ready, but it should be
mostly compatible and easy to switch between the two libraries (the
long-term goal has always been to move things developed in
kgio/kgio-monkey into Ruby upstream).


[1] - I prefer patches inline since it's easier to read/review, but
      attachments are accepted if your email client breaks patches.
      (git send-email should always work, though)

Re: Like OpenSSL::SSL::SSLSocket#connect_nonblock

[Iñaki Baz Castillo]

2012/4/10 Eric Wong <normalperson@yhbt.net>:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
>> Hi, I include a patch fixing the doc typos. More inline:
>
> I meant a proper git commit via git format-patch (with commit message,
> properly crediting you) so I can just pipe the entire email (or
> attachment[1]) to "git am".

Hope it has been properly received in a separate mail :)



>> I've worked too much (yet) with Ruby OpenSSL bindings, but I hope that
>> it does allow setting my own verification method.

Here I meant: "I've NOT worked..." :)


> It might be best to come up with working code for Ruby OpenSSL bindings
> first.  It's better-supported, at least.

Ok, what I'm doing is a Gem for using Ruby sockets within
EventMachine. For now I've created the TcpClient (which depends on
Kgio::TCPSocket). Next step is TlsClient. Current code:

https://github.com/ibc/em-ruby-sockets/blob/master/lib/em-ruby-sockets.rb
https://github.com/ibc/em-ruby-sockets/blob/master/lib/em-ruby-sockets/tcp_client.rb

So ok, first I'll try Ruby OpenSSL (managing EAGAIN exception during
the TLS handshake) and once it works I'll try Kgio-monkey :)


> I've never considered kgio-monkey production-ready, but it should be
> mostly compatible and easy to switch between the two libraries (the
> long-term goal has always been to move things developed in
> kgio/kgio-monkey into Ruby upstream).

Sure.


Thanks a lot.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>