@ibc, actually, opposite of what the methods may look like, TLSv1_client_method() forces TLSv1, while SSLv23_client_method() allows us to use any version of the protocol:

"OpenSSL 1.0.1 introduced support for TLSv1.1 and TLSv1.2. These are not
used by mutt. This patch fixes that.

Counter-intuitively, the OpenSSL folks have TLSv1_client_method()
negotiate only TLSv1.0, and SSLv23_client_method() remains the only
method which can negotiate different versions. This is true at least as
of 1.0.1c (the latest release at time of writing).

The attached patch uses SSLv23_client_method() and SSL_CTX_set_options()
to then disable SSLv2 and SSLv3." -- http://marc.info/?l=mutt-dev&m=133780326310758

And as you can see here: http://www.openssl.org/docs/ssl/SSL_CTX_new.html

TLSv1_method(void), TLSv1_server_method(void), TLSv1_client_method(void)
A TLS/SSL connection established with these methods will only understand the TLSv1 protocol. A client will send out TLSv1 client hello messages and will indicate that it only understands TLSv1. A server will only understand TLSv1 client hello messages. This especially means, that it will not understand SSLv2 client hello messages which are widely used for compatibility reasons, see SSLv23_*_method(). It will also not understand SSLv3 client hello messages.

SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages and will indicate that it also understands SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best choice when compatibility is a concern.

The list of protocols available can later be limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the SSL_CTX_set_options() or SSL_set_options() functions. Using these options it is possible to choose e.g. SSLv23_server_method() and be able to negotiate with all possible clients, but to only allow newer protocols like SSLv3 or TLSv1.

So effectively, EM in the current state, does support TLS.

Thanks for the information @archseer. However in EventMachine-LE version 1.1.4 there is a new options in start_tls() called :ssl_version:

New EM::Connection option for start_tls() method: :ssl_version (valid values are :SSLv23, :SSLv3 and :TLSv1, default value is :SSLv23).

For example in SIP protocol just TLSv1 must be used and never SSLvX, so when my EM based SIP server initiates a TLS connection I set :ssl_version => :TLSv1 and things work.

Anyhow, the point here is that this is a real issue, a real feature, a real need, but will be ignored in EM.

I am aware of EM-LE, however I do not agree with a lot of the changes you did in it. For instance, this ssh_version feature you just described, you use a conditional that explicitly specifies the protocol, whereas, SSL_CTX_set_options() or SSL_set_options() allows us to opt out of specific versions (so in an essence, you could opt out of SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 to use TLS only, or opt out of just one and allow other versions, useful for allowing TLS and SSLv3).

We'd just specify a hash of allowed/disallowed protocol versions, i.e. :optout => [:SSHv2, :SSHv1] or :allow => [:TLSv1]

To enable this functionality, all we'd need to do is pass an extra param, which would default to SSL_OP_ALL and would be used on this line: https://github.com/eventmachine/eventmachine/blob/master/ext/ssl.cpp#L152

instead of doing all of this

@archseer you don't agree "with a lot of changes in EM-LE"? Could you please explain a bit more which ones (a part from this one)?

I like your solution a lot and will try to implement it in EM-LE when I get some spare time: ibc#15

Anyhow, regardless how this is implemented, an extra option is needed for start_tl() and hende "all" those (or similar to) in my modification is required. This is because a new option must to be passed from Ruby land to C land and then to C++ land.

Thanks a lot.

We'd just specify a hash of allowed/disallowed protocol versions, i.e. :optout => [:SSHv2, :SSHv1]
or :allow => [:TLSv1]
To enable this functionality, all we'd need to do is pass an extra param, which would default to >>SSL_OP_ALL and would be used on this line:

Hi.
sorry, but i can't find a documentation for that. Where do i have to put in :allow => [:TLSv1] if i want to force a TLSv1.0 connection?

Thanks.
Alex

https://github.com/ibc/EventMachine-LE/blob/master/lib/em/connection.rb#L396

Thanks ibc ...but this is for the eventmachine-le? :)

Is there a way to do this in the "normal" 1.0.3

Well, the code you quote above is not in "normal" eventmachine. In fact, in "normal" eventmachine there is nothing interesting and new since years because developers ignore everything (including IPv6 patches that make eventmachine to properly work in IPv6 networks). And that is why EventMachine-LE does exist. Now my question is: why do you think that EM-LE is not valid for you?

I just wanted to test something with the already installed version.
...and perhaps because I have no idea how to install and make it work with my existing siriproxy version :)

I'm pretty sure the project README explains very clear how to use eventmachine-le instead of eventmachine in any project ;)

https://github.com/ibc/EventMachine-LE#usage

Thank's a lot :)

and i only have to replace

• require 'eventmachine'
  with
• require "eventmachine-le"
• require "em-udns"

and what happens to things like
EventMachine::start_server - or - include EventMachine::Protocols::LineText2
nothing to change here?

I'm the author of em-udns so I am very sure it works with eventmachine-le ;)

Yes, your steps are the correct ones. Basically calling require "eventmachine-le" sets its gem lib the first one, so before the "normal" eventmachine. So any call to require "eventmachine" doing after that would not attempt to load the "normal" eventmachine.

NOTE: Be sure that you DO NOT load any gem or Ruby library that calls to require "eventmachine" before the line require "eventmachine-le". That's all.

hm...
starting the script fails with this error:
siriproxy.rb:5:in `require': cannot load such file -- eventmachine-le (LoadError)

another question... are these the original, but extendet eventmachine files in "le" version? can i just replace the old ones?

Ha. Nice!... working. Thank's again :)

Hi, please open an issue in eventmachine-le Github project, and let's continue there ;)

BTW: Have you installed eventmachine-le? And I don't fully understand your second question.

Yes, i installed it.... did not work in the beginning, but now it does. ... :)

I wasn't aware of this discussion (unfortunately) when I did this: #438.

It's similar to changes applied to EventMachine-LE, but with tests and using what @archseer suggested SSL_CTX_set_options with SSL_OP_NO_SSLv2, etc).

@ibc would you consider applying my PR to EventMachine-LE?

@fabiokung let's talk about this in ibc#15 please

Closing in favor of PR #570

@sodabrew I don't think this should be closed. #570 addresses the original issue, but does not address the concerns I had.

Ok, I re-read some of the linked issues, and the changes in eventmachine-le aren't necessarily a final resolution to all of the concerns. Reopening, will need to come back to this and do some more work.

@archseer I think your suggestion of the enable / disable option list is the best one.

In particular, SSL is basically dead now, since BEAST and POODLE. So we'll need something like this:

Apache (enable all, opt-out of some)

SSLProtocol All -SSLv2 -SSLv3

nginx (disable all, opt-in to some)

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

@archseer I think your suggestion of the enable / disable option list is the best one.

@sodabrew #438

Thanks @fabiokung I will follow up on your PR!

Superseded by #654