Re: jabberd-2.3.0 release

2013-11-26 Thread Eric Koldeweij

Christof,

I had the same problem, luckily I ran on a test server. I could not even 
login with my client.


There has been a change in sx/ssl.c line 899. The line now reads
ctx = SSL_CTX_new(TLSv1_2_method());

This means that it will support TLS v1.2 only. Connections using SSLv3 
or TLS v1.1 and earlier are not accepted any more. There is also another 
issue that if a secure connection cannot be established for any reason 
(incompatible protocol or verification failed or similar) it will retry 
many times in very rapid succession for 10 minutes.


You can get the old behavior back by changing the line above back to the 
2.2.17 version:

ctx = SSL_CTX_new(SSLv23_method());

I think a better solution would be to use the SSLv23_method and disable 
SSLv3 with an option immediately after:


SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);

I have not tested this yet but as far as I can see it will leave you 
with support for TLS v1.0, v1.1 and v1.2.
An even better solution would be to make the SSL settings 
user-configurable. This is not trivial to do though.


Regards,
Eric.


On 11/26/13 07:40, Christof Meerwald wrote:

On Mon, 18 Nov 2013 17:18:07 +0100, Tomasz Sterna wrote:

Next jabberd2 release is finally available.

Get 2.3.0 release at GitHub: https://github.com/jabberd2/jabberd2/releases

I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me
with a broken server. The s2s component now just connects to a remote
server, switches the stream to TLS, gets the certificate, disconnects
and immediately connects again. The log file doesn't give any reason
for this connection/disconnection loop and it's not clear what
configuration settings need to be updated to make it work again (as
the NEWS file isn't that helpful). But as there is no delay between
the connects/disconnects (and no useful error message), this behaviour
might be considered a bug anyway...

Guess I'll have to do some debugging and code reviewing in the next
few days...


Christof







Re: jabberd-2.3.0 release

2013-11-26 Thread Carlos Lopez
If you are interested you can try the changes I made in 
http://suchat.org/sx/ssl.c

For protocols TLS v1.0, v1.1 and v1.2.

Carlos
El 26/11/13 10:11, Eric Koldeweij escribió:

Christof,

I had the same problem, luckily I ran on a test server. I could not 
even login with my client.


There has been a change in sx/ssl.c line 899. The line now reads
ctx = SSL_CTX_new(TLSv1_2_method());

This means that it will support TLS v1.2 only. Connections using SSLv3 
or TLS v1.1 and earlier are not accepted any more. There is also 
another issue that if a secure connection cannot be established for 
any reason (incompatible protocol or verification failed or similar) 
it will retry many times in very rapid succession for 10 minutes.


You can get the old behavior back by changing the line above back to 
the 2.2.17 version:

ctx = SSL_CTX_new(SSLv23_method());

I think a better solution would be to use the SSLv23_method and 
disable SSLv3 with an option immediately after:


SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);

I have not tested this yet but as far as I can see it will leave you 
with support for TLS v1.0, v1.1 and v1.2.
An even better solution would be to make the SSL settings 
user-configurable. This is not trivial to do though.


Regards,
Eric.


On 11/26/13 07:40, Christof Meerwald wrote:

On Mon, 18 Nov 2013 17:18:07 +0100, Tomasz Sterna wrote:

Next jabberd2 release is finally available.

Get 2.3.0 release at GitHub: 
https://github.com/jabberd2/jabberd2/releases

I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me
with a broken server. The s2s component now just connects to a remote
server, switches the stream to TLS, gets the certificate, disconnects
and immediately connects again. The log file doesn't give any reason
for this connection/disconnection loop and it's not clear what
configuration settings need to be updated to make it work again (as
the NEWS file isn't that helpful). But as there is no delay between
the connects/disconnects (and no useful error message), this behaviour
might be considered a bug anyway...

Guess I'll have to do some debugging and code reviewing in the next
few days...


Christof












Re: jabberd-2.3.0 release

2013-11-26 Thread Tomasz Sterna
Dnia 2013-11-26, wto o godzinie 07:40 +0100, Christof Meerwald pisze:
 I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me
 with a broken server. The s2s component now just connects to a remote
 server, switches the stream to TLS, gets the certificate, disconnects
 and immediately connects again.

I guess the network is not that ready for 'TLS Everywhere' [1] yet.

Maybe it is worth releasing 2.2.18 without that change.


[1] https://github.com/jabberd2/jabberd2/commit/ad9ead7816

-- 
Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/





XMPP connections

2013-11-26 Thread Haider Ali
Hi Everyone

Can anyone let me know that how XMPP handle so many connections. Since we
know that we can only open 2 ^ 16 = 65536 ports ( connections ) with a
single machine. But i came to know that single xmpp server can handle more
connections than 65536.


Re: XMPP connections

2013-11-26 Thread Eric Koldeweij

Hello,

A typical XMPP server will open only one port, port 5222. All clients 
will connect to that port so in theory an almost unlimited number of 
connections are possible to that server. This is not particular to XMPP 
but is a basic TCP/IP client/server feature, exactly the same goes for 
other services for instance a web server. The 65536 port limit is a 
client limit, not a server limit. A client can not have more than 65536 
connections open to any other host at the same time (65536 is 
theoretical, in reality this number will be much lower).


Regards,
Eric.

On 11/26/13 11:41, Haider Ali wrote:

Hi Everyone

Can anyone let me know that how XMPP handle so many connections. Since 
we know that we can only open 2 ^ 16 = 65536 ports ( connections ) 
with a single machine. But i came to know that single xmpp server can 
handle more connections than 65536.






Re: XMPP connections

2013-11-26 Thread Reinhard Max

Hi,

On Tue, 26 Nov 2013 at 11:41, Haider Ali wrote:

Can anyone let me know that how XMPP handle so many connections. 
Since we know that we can only open 2 ^ 16 = 65536 ports ( 
connections ) with a single machine. But i came to know that single 
xmpp server can handle more connections than 65536.


your assumption that there can only be a single connection per port 
number at a time is wrong. A combination of local IP address and port 
can be used for many connections at once as long as the remote IP 
address *or* the remote port number are different between each of 
them.


Server sockets do this automatically with every call to accept(), but 
for client sockets you have to set the SO_REUSEADDR option to allow a 
second bind() while socket using the same port number is still open.


cu
Reinhard




Re: XMPP connections

2013-11-26 Thread Reinhard Max


On Tue, 26 Nov 2013 at 12:09, Eric Koldeweij wrote:

The 65536 port limit is a client limit, not a server limit. A client 
can not have more than 65536 connections open to any other host at 
the same time (65536 is theoretical, in reality this number will be 
much lower).


A client can even have more connections to a single server as long as 
all combinations of local and remote port numbers are distinct. So, 
the actual (theoretical) limit is 64k^2 connections per unique 
combination of local and remote IP addresses.


Or in other words, it is the combination of local IP address, local 
port number, remote IP address and remote port number that uniquely 
identifies a TCP connection and if only one of these four values is 
different we are looking at two separate connections that can exist in 
parallel.


cu
Reinhard




Re: XMPP connections

2013-11-26 Thread Tomasz Sterna
Dnia 2013-11-26, wto o godzinie 01:41 -0900, Haider Ali pisze:
 Since we know that we can only open 2 ^ 16 = 65536 ports ( connections
 ) with a single machine.

That's a common myth.

Google is your friend:
http://www.quora.com/TCP-IP/What-is-the-maximum-number-of-simultaneous-TCP-connections-achieved-to-one-IP-address-and-port

The TCP/IP standard sets up unique connection identifiers as the tuple
of local IP Address, local TCP port number, remote IP address, and
remote TCP port number. In your example, the local numbers are both
fixed, which leaves approximately 2^32 remote IP (version 4) addresses,
and 2^16 TCP port numbers, or an approximate total potential
simultaneous TCP connections of 281,474,976,710,656 (2^48, or 2.81 *
10^14, or 281 trillion).