tigase/_server/server-core

Artur Hefczyc opened 1 decade ago

There seems to be problems between Tigase and Prosody in TLS hardened mode described in the topic: message#1367

Andrzej, if you have an idea on how to work with Simon to solve the problem then it's OK. However, I think it would be much easier for us to diagnose it on our controlled system.

Therefore I would like Eric to prepare a machine with Prosody for the test and you could then run s2s tests between these 2 servers. Configuration details are included in the original topic. If more information is needed, please request them from Simon.

Eric, please prepare a machine with Prosody installed for tests for Andrzej.

Artur Hefczyc commented 1 decade ago

We have got another report about Prosody compatibility issues for TLS s2s connections. Here are details:

OS: Linux Ubuntu 12.04 LTS

XMPP Server: Prosody 0.9.3

Domain: mijabber.es (Only 1 domain served)

This is my cipher String: "HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL:!DSS"

that support al this ciphers:

0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

     0x00,0x6B - DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256

     0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1

     0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1

     0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD

     0x00,0x67 - DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256

     0x00,0x33 - DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1

     0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1

     0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

     0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD

     0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384

     0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384

     0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1

     0xC0,0x0A - ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1

     0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

     0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD

     0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256

     0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256

     0xC0,0x13 - ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1

     0xC0,0x09 - ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1

     0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD

     0xC0,0x2E - ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD

     0xC0,0x2A - ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384

     0xC0,0x26 - ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384

     0xC0,0x0F - ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1

     0xC0,0x05 - ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1

     0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD

     0x00,0x3D - AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256

     0x00,0x35 - AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1

     0x00,0x84 - CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1

     0xC0,0x31 - ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD

     0xC0,0x2D - ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD

     0xC0,0x29 - ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256

     0xC0,0x25 - ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256

     0xC0,0x0E - ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1

     0xC0,0x04 - ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1

     0x00,0x9C - AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD

     0x00,0x3C - AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

     0x00,0x2F - AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1

     0x00,0x41 - CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1

I have configured my server to support only ciphers that support Forward Secrecy. For the Diffie Hellman exchanges, I use a exponent key size of 2048.

Luis G.F commented 1 decade ago

Details about the config:

s2s_require_encryption = true

s2s_secure_auth = false

Eric Dziewa commented 1 decade ago

We have Prosody installed on v34.tigase.org. Andrzej has the login information.

Luis G.F commented 1 decade ago

Hello Eric:

I'm trying to check from our side some SSL things and i see one strange behavior, the TLS/SSL handshake was unable to complete:

root@xmpp1:/etc/prosody/certs# openssl s_client -showcerts -connect tigase.im:5269 -serverpref -tls1_1  -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:failed in SSLv3 read server hello A
140438356186784:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1392367330
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

I try with all protocol versions SSL2,SSL3,TLS1,TLS1.1 and TLS1.2 without success. I take a pcap capture of the traffic between us and tigase.im too, but i'm analyzing that a this moment, i will share with you if a found any clue.

Simon Tennant commented 1 decade ago

We see the same behavior -

Tigase connects to prosody

Tigase Send stream stanza.
During TLS negotiation.
Prosody cannot parse the certificate that Tigase is presenting
In prosody certificate is null, and Prosody disconnects.

Another data point - connecting from the XMPP.net show test s2s connections being setup.

Simon Tennant commented 1 decade ago

@Andrzej - please feel free to ping me: simon@buddycloud.com, if I can provide any more data or access to a test system.

Andrzej Wójcik (Tigase) commented 1 decade ago

Luis G.F wrote:

Hello Eric:

I'm trying to check from our side some SSL things and i see one strange behavior, the TLS/SSL handshake was unable to complete:

[...]

I try with all protocol versions SSL2,SSL3,TLS1,TLS1.1 and TLS1.2 without success. I take a pcap capture of the traffic between us and tigase.im too, but i'm analyzing that a this moment, i will share with you if a found any clue.

You tried to connect to port 5269 which IS NOT an SSL secured XMPP port but PLAIN XMPP port which can be encrypted only after using STARTTLS extension of XMPP S2S protocol, due to that this test could not result in anything else that failure.

Luis G.F commented 1 decade ago

Hi Andrzej:

Yes, this is true. I see that in the pcap capture. I put another prosody server in debug mode and this is that i see in my logs, after the "proceed" from starttls, the connection is droped due to a fail in the ssl handshake.

Feb 15 13:39:10 mod_s2s	debug	opening a new outgoing connection for this stanza
Feb 15 13:39:10 mod_s2s	debug	stanza [iq] queued until connection complete
Feb 15 13:39:10 mod_s2s	debug	First attempt to connect to tigase.im, starting with SRV lookup...
Feb 15 13:39:10 adns	debug	Records for _xmpp-server._tcp.tigase.im. not in cache, sending query (thread: 0x25c2110)...
Feb 15 13:39:10 adns	debug	Sending DNS query to 127.0.0.1
Feb 15 13:39:11 socket	debug	server.lua: closed client handler and removed socket from list
Feb 15 13:39:11 adns	debug	Reply for _xmpp-server._tcp.tigase.im. (thread: 0x25c2110)
Feb 15 13:39:11 mod_s2s	debug	tigase.im has SRV records, handling...
Feb 15 13:39:11 mod_s2s	debug	Best record found, will connect to tigase.me.:5269
Feb 15 13:39:11 adns	debug	Records for tigase.me. not in cache, sending query (thread: 0x27c00f0)...
Feb 15 13:39:11 adns	debug	Sending DNS query to 127.0.0.1
Feb 15 13:39:11 adns	debug	Records for tigase.me. not in cache, sending query (thread: 0x221d4c0)...
Feb 15 13:39:11 adns	debug	Sending DNS query to 127.0.0.1
Feb 15 13:39:11 adns	debug	Reply for tigase.me. (thread: 0x27c00f0)
Feb 15 13:39:11 mod_s2s	debug	DNS reply for tigase.me. gives us 188.165.230.189
Feb 15 13:39:11 mod_s2s	debug	DNS reply for tigase.me. gives us 91.121.157.140
Feb 15 13:39:11 mod_s2s	debug	DNS reply for tigase.me. gives us 188.165.222.166
Feb 15 13:39:11 socket	debug	server.lua: closed client handler and removed socket from list
Feb 15 13:39:11 adns	debug	Reply for tigase.me. (thread: 0x221d4c0)
Feb 15 13:39:11 s2sout2609220	info	Beginning new connection attempt to tigase.im ([188.165.230.189]:5269)
Feb 15 13:39:11 s2sout2609220	debug	Connection attempt in progress...
Feb 15 13:39:11 s2sout2609220	debug	sending: <?xml version='1.0'?>
Feb 15 13:39:11 s2sout2609220	debug	sending: <stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='dev.mijabber.es' to='tigase.im' xml:lang='en' xmlns='jabber:server'>
Feb 15 13:39:11 s2sout2609220	debug	Received[s2sout_unauthed]: <features xmlns='http://etherx.jabber.org/streams'>
Feb 15 13:39:11 dev.mijabber.es:tls	debug	Received features element
Feb 15 13:39:11 dev.mijabber.es:tls	debug	tigase.im is offering TLS, taking up the offer...
Feb 15 13:39:11 s2sout2609220	debug	sending: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Feb 15 13:39:11 s2sout2609220	debug	Received[s2sout_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Feb 15 13:39:11 dev.mijabber.es:tls	debug	Proceeding with TLS on s2sout...
Feb 15 13:39:11 socket	debug	server.lua: attempting to start tls on tcp{client}: 0x2760928
Feb 15 13:39:12 socket	debug	server.lua: ssl handshake done
Feb 15 13:39:12 s2sout2609220	debug	Sending stream header...
Feb 15 13:39:12 s2sout2609220	debug	sending: <?xml version='1.0'?>
Feb 15 13:39:12 s2sout2609220	debug	sending: <stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='dev.mijabber.es' id='003fc092-dfa9-4c99-9df7-e3f521456780' to='tigase.im' xml:lang='en' xmlns='jabber:server'>
Feb 15 13:39:12 s2sout2609220	debug	certificate chain validation result: valid
Feb 15 13:39:12 x509	debug	Cert xmppAddr tigase.im matched hostname
Feb 15 13:39:12 s2sout2609220	debug	certificate identity validation result: valid
Feb 15 13:39:12 s2sout2609220	debug	Received[s2sout_unauthed]: <features xmlns='http://etherx.jabber.org/streams'>
Feb 15 13:39:12 dev.mijabber.es:tls	debug	Received features element
Feb 15 13:39:12 dev.mijabber.es:dialback	debug	Initiating dialback...
Feb 15 13:39:12 s2sout2609220	debug	sending: <db:result to='tigase.im' from='dev.mijabber.es'>
Feb 15 13:39:12 s2sout2609220	info	sent dialback key on outgoing s2s stream
Feb 15 13:39:15 socket	debug	server.lua: accepted new client connection from 188.165.230.189:45860 to 5269
Feb 15 13:39:15 s2sin26aace0	debug	Incoming s2s connection
Feb 15 13:39:15 s2sin26aace0	debug	Incoming s2s received <stream:stream xmlns='http://etherx.jabber.org/streams' version='1.0' to='dev.mijabber.es' from='tigase.im'>
Feb 15 13:39:15 mod_s2s	debug	sending: <?xml version='1.0'?>
Feb 15 13:39:15 mod_s2s	debug	sending: <stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='dev.mijabber.es' id='9038075d-4a55-430d-92fc-6e2d01f35e0e' to='tigase.im' xml:lang='en' xmlns='jabber:server'>
Feb 15 13:39:15 mod_s2s	debug	Sending stream features: <stream:features><dialback xmlns='urn:xmpp:features:dialback'/><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls></stream:features>
Feb 15 13:39:15 mod_s2s	debug	sending: <stream:features>
Feb 15 13:39:15 s2sin26aace0	debug	Received[s2sin_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Feb 15 13:39:15 mod_s2s	debug	sending: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
Feb 15 13:39:15 socket	debug	server.lua: we need to do tls, but delaying until send buffer empty
Feb 15 13:39:15 s2sin26aace0	debug	TLS negotiation started for s2sin_unauthed...
Feb 15 13:39:15 socket	debug	server.lua: attempting to start tls on tcp{client}: 0x24907d8
Feb 15 13:39:15 socket	debug	server.lua: ssl handshake error: closed
Feb 15 13:39:15 s2sin26aace0	debug	s2s disconnected: tigase.im->dev.mijabber.es (ssl handshake failed)
Feb 15 13:39:15 s2sin26aace0	debug	Destroying incoming session tigase.im->dev.mijabber.es: ssl handshake failed
Feb 15 13:39:15 socket	debug	server.lua: closed client handler and removed socket from list
Feb 15 13:39:41 socket	debug	server.lua: client 188.165.230.189:clientport read error: closed
Feb 15 13:39:41 s2sout2609220	debug	s2s disconnected: dev.mijabber.es->tigase.im (closed)
Feb 15 13:39:41 s2sout2609220	debug	Destroying outgoing session dev.mijabber.es->tigase.im: closed
Feb 15 13:39:41 s2sout2609220	info	sending error replies for 1 queued stanzas because of failed outgoing connection to tigase.im

Simon Tennant commented 1 decade ago

This looks similar to our tests:

Feb 15 13:39:15 s2sin26aace0    debug    TLS negotiation started for s2sin_unauthed...
Feb 15 13:39:15 socket    debug    server.lua: attempting to start tls on tcp{client}: 0x24907d8
Feb 15 13:39:15 socket    debug    server.lua: ssl handshake error: closed
Feb 15 13:39:15 s2sin26aace0    debug    s2s disconnected: tigase.im->dev.mijabber.es (ssl handshake failed)
Feb 15 13:39:15 s2sin26aace0    debug    Destroying incoming session tigase.im->dev.mijabber.es: ssl handshake failed
Feb 15 13:39:15 socket    debug    server.lua: closed client handler and removed socket from list
Feb 15 13:39:41 socket    debug    server.lua: client 188.165.230.189:clientport read error: closed

When we looked closer it appeared that the Tigase server wasn't offering up a certificate.

Luis G.F commented 1 decade ago

Hi Simon:

I See in my pcap capture that tigase was offer correctly a certificate, the problem arrive in the SSL handshake. After receive the "proceed" offered in STARTLS negotiation, the connection is dropped :-/

Andrzej Wójcik (Tigase) commented 1 decade ago

I think Simon is right about Tigase not sending client certificate as I've identified a code which I suppose is responsible for not sending client certificate when connection in client mode. I will work on solving this issue.

Luis - In part of log you provided I see that Prosody was trying to connect to Tigase XMPP Server and when connection was establishing from dev.mijabber.es to tigase.im TLS was negotiated successfully but, to authenticate this connection Tigase wanted to confirm it by XMPP S2S dialback and when tigase.im was establishing connection to dev.mijabber.es then TLS negotiation failed as I suppose Tigase did not send client certificate.

Thank you for bringing this issue to our attention

Luis G.F commented 1 decade ago

OK, problem found. I have my server configured with a DH param of 2048 key size, the problem is that Java doesn't support Diffie-Hellman Keys greather than 1024 bits, then tigase fails if the other side has a greather dhparam set.

I test that in my dev server (disabling the dh key of 2048) and "voilá", tigase.im connection works now.

Luis G.F commented 1 decade ago

The problem is that i can't downgrade my cipher strengh to support legacy servers that don't support DH Keys >1024. If tigase.im don't fix the issue the connection between us should be impossible.

Andrzej Wójcik (Tigase) commented 1 decade ago

Issue with DH key > 1024 is more complicated as Tigase XMPP Server is using TLS mechanisms from Java which in Java 7 is limited to DH <= 1024. This is fixed in upcoming Java 8 from what I have read, but I suppose that we will need to wait some time before Java 8 will be released as Java 8 is planned to be released on 18 of march 2014.

Simon Tennant commented 1 decade ago

While large DH keys are a problem, JavaTM Cryptography Extension is supposed to fix this.

At the same time, I'm running with Prosody's default DH params (less than 2048) but still see this.

Andrzej Wójcik (Tigase) commented 1 decade ago

Fixed sending client certificate on outgoing S2S connection when STARTTLS is used.

Daniele Ricci commented 8 years ago

I'm having issues (ssl handshake failed, unfortunately no other details on neither Tigase nor Prosody ends) with Prosody and Tigase in hardened mode (with 2048-bit DH parameters). You said:

Fixed sending client certificate on outgoing S2S connection when STARTTLS is used.

Does that need activation through a parameter? What certificate will it be using? The server one?

Daniele Ricci commented 8 years ago

Ok I just saw the commit, it's using the server certificate alright. Any advice on how to debug this? I'm getting crazy about this because I can't debug it in any way. My server is classified as "A" on the xmpp.net test: https://xmpp.net/result.php?id=484793

Andrzej Wójcik (Tigase) commented 8 years ago

Issue reported in this task was solved 2 years ago and confirmed fix works out of a box without any issues.

I would suggest to enable debugging of tigase.io and tigase.server packages but it will generate a lot of logs.

--debug=server,io

Please use our forums if you need help with particular cases which are not yet confirmed to be bugs in Tigase and I would recommend not to reopen or comment on closed task.

Type	Task
Priority	Major
Assignee	Andrzej Wójcik (Tigase)
RedmineID	1729
Spent time	12h

	Artur Hefczyc opened 1 decade ago There seems to be problems between Tigase and Prosody in TLS hardened mode described in the topic: message#1367 Andrzej, if you have an idea on how to work with Simon to solve the problem then it's OK. However, I think it would be much easier for us to diagnose it on our controlled system. Therefore I would like Eric to prepare a machine with Prosody for the test and you could then run s2s tests between these 2 servers. Configuration details are included in the original topic. If more information is needed, please request them from Simon. Eric, please prepare a machine with Prosody installed for tests for Andrzej.
	Artur Hefczyc commented 1 decade ago We have got another report about Prosody compatibility issues for TLS s2s connections. Here are details: OS: Linux Ubuntu 12.04 LTS XMPP Server: Prosody 0.9.3 Domain: mijabber.es (Only 1 domain served) This is my cipher String: "HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL:!DSS" that support al this ciphers: 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 0xC0,0x14 - ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 0xC0,0x0A - ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 0xC0,0x13 - ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 0xC0,0x09 - ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 0xC0,0x32 - ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2E - ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD 0xC0,0x2A - ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x26 - ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 0xC0,0x0F - ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 0xC0,0x05 - ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 0x00,0x84 - CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 0xC0,0x31 - ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD 0xC0,0x2D - ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD 0xC0,0x29 - ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 0xC0,0x25 - ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 0xC0,0x0E - ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 0xC0,0x04 - ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 0x00,0x41 - CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 I have configured my server to support only ciphers that support Forward Secrecy. For the Diffie Hellman exchanges, I use a exponent key size of 2048.
	Luis G.F commented 1 decade ago Details about the config: s2s_require_encryption = true s2s_secure_auth = false
	Eric Dziewa commented 1 decade ago We have Prosody installed on v34.tigase.org. Andrzej has the login information.
	Luis G.F commented 1 decade ago Hello Eric: I'm trying to check from our side some SSL things and i see one strange behavior, the TLS/SSL handshake was unable to complete: root@xmpp1:/etc/prosody/certs# openssl s_client -showcerts -connect tigase.im:5269 -serverpref -tls1_1 -state CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv3 write client hello A SSL_connect:failed in SSLv3 read server hello A 140438356186784:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1392367330 Timeout : 7200 (sec) Verify return code: 0 (ok) --- I try with all protocol versions SSL2,SSL3,TLS1,TLS1.1 and TLS1.2 without success. I take a pcap capture of the traffic between us and tigase.im too, but i'm analyzing that a this moment, i will share with you if a found any clue.
	Simon Tennant commented 1 decade ago We see the same behavior - Tigase connects to prosody Tigase Send stream stanza. During TLS negotiation. Prosody cannot parse the certificate that Tigase is presenting In prosody certificate is null, and Prosody disconnects. Another data point - connecting from the XMPP.net show test s2s connections being setup.
	Simon Tennant commented 1 decade ago @Andrzej - please feel free to ping me: simon@buddycloud.com, if I can provide any more data or access to a test system.
	Andrzej Wójcik (Tigase) commented 1 decade ago Luis G.F wrote: Hello Eric: I'm trying to check from our side some SSL things and i see one strange behavior, the TLS/SSL handshake was unable to complete: [...] I try with all protocol versions SSL2,SSL3,TLS1,TLS1.1 and TLS1.2 without success. I take a pcap capture of the traffic between us and tigase.im too, but i'm analyzing that a this moment, i will share with you if a found any clue. You tried to connect to port 5269 which IS NOT an SSL secured XMPP port but PLAIN XMPP port which can be encrypted only after using STARTTLS extension of XMPP S2S protocol, due to that this test could not result in anything else that failure.
	Luis G.F commented 1 decade ago Hi Andrzej: Yes, this is true. I see that in the pcap capture. I put another prosody server in debug mode and this is that i see in my logs, after the "proceed" from starttls, the connection is droped due to a fail in the ssl handshake. Feb 15 13:39:10 mod_s2s debug opening a new outgoing connection for this stanza Feb 15 13:39:10 mod_s2s debug stanza [iq] queued until connection complete Feb 15 13:39:10 mod_s2s debug First attempt to connect to tigase.im, starting with SRV lookup... Feb 15 13:39:10 adns debug Records for _xmpp-server._tcp.tigase.im. not in cache, sending query (thread: 0x25c2110)... Feb 15 13:39:10 adns debug Sending DNS query to 127.0.0.1 Feb 15 13:39:11 socket debug server.lua: closed client handler and removed socket from list Feb 15 13:39:11 adns debug Reply for _xmpp-server._tcp.tigase.im. (thread: 0x25c2110) Feb 15 13:39:11 mod_s2s debug tigase.im has SRV records, handling... Feb 15 13:39:11 mod_s2s debug Best record found, will connect to tigase.me.:5269 Feb 15 13:39:11 adns debug Records for tigase.me. not in cache, sending query (thread: 0x27c00f0)... Feb 15 13:39:11 adns debug Sending DNS query to 127.0.0.1 Feb 15 13:39:11 adns debug Records for tigase.me. not in cache, sending query (thread: 0x221d4c0)... Feb 15 13:39:11 adns debug Sending DNS query to 127.0.0.1 Feb 15 13:39:11 adns debug Reply for tigase.me. (thread: 0x27c00f0) Feb 15 13:39:11 mod_s2s debug DNS reply for tigase.me. gives us 188.165.230.189 Feb 15 13:39:11 mod_s2s debug DNS reply for tigase.me. gives us 91.121.157.140 Feb 15 13:39:11 mod_s2s debug DNS reply for tigase.me. gives us 188.165.222.166 Feb 15 13:39:11 socket debug server.lua: closed client handler and removed socket from list Feb 15 13:39:11 adns debug Reply for tigase.me. (thread: 0x221d4c0) Feb 15 13:39:11 s2sout2609220 info Beginning new connection attempt to tigase.im ([188.165.230.189]:5269) Feb 15 13:39:11 s2sout2609220 debug Connection attempt in progress... Feb 15 13:39:11 s2sout2609220 debug sending: <?xml version='1.0'?> Feb 15 13:39:11 s2sout2609220 debug sending: <stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='dev.mijabber.es' to='tigase.im' xml:lang='en' xmlns='jabber:server'> Feb 15 13:39:11 s2sout2609220 debug Received[s2sout_unauthed]: <features xmlns='http://etherx.jabber.org/streams'> Feb 15 13:39:11 dev.mijabber.es:tls debug Received features element Feb 15 13:39:11 dev.mijabber.es:tls debug tigase.im is offering TLS, taking up the offer... Feb 15 13:39:11 s2sout2609220 debug sending: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> Feb 15 13:39:11 s2sout2609220 debug Received[s2sout_unauthed]: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'> Feb 15 13:39:11 dev.mijabber.es:tls debug Proceeding with TLS on s2sout... Feb 15 13:39:11 socket debug server.lua: attempting to start tls on tcp{client}: 0x2760928 Feb 15 13:39:12 socket debug server.lua: ssl handshake done Feb 15 13:39:12 s2sout2609220 debug Sending stream header... Feb 15 13:39:12 s2sout2609220 debug sending: <?xml version='1.0'?> Feb 15 13:39:12 s2sout2609220 debug sending: <stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='dev.mijabber.es' id='003fc092-dfa9-4c99-9df7-e3f521456780' to='tigase.im' xml:lang='en' xmlns='jabber:server'> Feb 15 13:39:12 s2sout2609220 debug certificate chain validation result: valid Feb 15 13:39:12 x509 debug Cert xmppAddr tigase.im matched hostname Feb 15 13:39:12 s2sout2609220 debug certificate identity validation result: valid Feb 15 13:39:12 s2sout2609220 debug Received[s2sout_unauthed]: <features xmlns='http://etherx.jabber.org/streams'> Feb 15 13:39:12 dev.mijabber.es:tls debug Received features element Feb 15 13:39:12 dev.mijabber.es:dialback debug Initiating dialback... Feb 15 13:39:12 s2sout2609220 debug sending: <db:result to='tigase.im' from='dev.mijabber.es'> Feb 15 13:39:12 s2sout2609220 info sent dialback key on outgoing s2s stream Feb 15 13:39:15 socket debug server.lua: accepted new client connection from 188.165.230.189:45860 to 5269 Feb 15 13:39:15 s2sin26aace0 debug Incoming s2s connection Feb 15 13:39:15 s2sin26aace0 debug Incoming s2s received <stream:stream xmlns='http://etherx.jabber.org/streams' version='1.0' to='dev.mijabber.es' from='tigase.im'> Feb 15 13:39:15 mod_s2s debug sending: <?xml version='1.0'?> Feb 15 13:39:15 mod_s2s debug sending: <stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='dev.mijabber.es' id='9038075d-4a55-430d-92fc-6e2d01f35e0e' to='tigase.im' xml:lang='en' xmlns='jabber:server'> Feb 15 13:39:15 mod_s2s debug Sending stream features: <stream:features><dialback xmlns='urn:xmpp:features:dialback'/><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls></stream:features> Feb 15 13:39:15 mod_s2s debug sending: <stream:features> Feb 15 13:39:15 s2sin26aace0 debug Received[s2sin_unauthed]: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> Feb 15 13:39:15 mod_s2s debug sending: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'> Feb 15 13:39:15 socket debug server.lua: we need to do tls, but delaying until send buffer empty Feb 15 13:39:15 s2sin26aace0 debug TLS negotiation started for s2sin_unauthed... Feb 15 13:39:15 socket debug server.lua: attempting to start tls on tcp{client}: 0x24907d8 Feb 15 13:39:15 socket debug server.lua: ssl handshake error: closed Feb 15 13:39:15 s2sin26aace0 debug s2s disconnected: tigase.im->dev.mijabber.es (ssl handshake failed) Feb 15 13:39:15 s2sin26aace0 debug Destroying incoming session tigase.im->dev.mijabber.es: ssl handshake failed Feb 15 13:39:15 socket debug server.lua: closed client handler and removed socket from list Feb 15 13:39:41 socket debug server.lua: client 188.165.230.189:clientport read error: closed Feb 15 13:39:41 s2sout2609220 debug s2s disconnected: dev.mijabber.es->tigase.im (closed) Feb 15 13:39:41 s2sout2609220 debug Destroying outgoing session dev.mijabber.es->tigase.im: closed Feb 15 13:39:41 s2sout2609220 info sending error replies for 1 queued stanzas because of failed outgoing connection to tigase.im
	Simon Tennant commented 1 decade ago This looks similar to our tests: Feb 15 13:39:15 s2sin26aace0 debug TLS negotiation started for s2sin_unauthed... Feb 15 13:39:15 socket debug server.lua: attempting to start tls on tcp{client}: 0x24907d8 Feb 15 13:39:15 socket debug server.lua: ssl handshake error: closed Feb 15 13:39:15 s2sin26aace0 debug s2s disconnected: tigase.im->dev.mijabber.es (ssl handshake failed) Feb 15 13:39:15 s2sin26aace0 debug Destroying incoming session tigase.im->dev.mijabber.es: ssl handshake failed Feb 15 13:39:15 socket debug server.lua: closed client handler and removed socket from list Feb 15 13:39:41 socket debug server.lua: client 188.165.230.189:clientport read error: closed When we looked closer it appeared that the Tigase server wasn't offering up a certificate.
	Luis G.F commented 1 decade ago Hi Simon: I See in my pcap capture that tigase was offer correctly a certificate, the problem arrive in the SSL handshake. After receive the "proceed" offered in STARTLS negotiation, the connection is dropped :-/
	Andrzej Wójcik (Tigase) commented 1 decade ago I think Simon is right about Tigase not sending client certificate as I've identified a code which I suppose is responsible for not sending client certificate when connection in client mode. I will work on solving this issue. Luis - In part of log you provided I see that Prosody was trying to connect to Tigase XMPP Server and when connection was establishing from dev.mijabber.es to tigase.im TLS was negotiated successfully but, to authenticate this connection Tigase wanted to confirm it by XMPP S2S dialback and when tigase.im was establishing connection to dev.mijabber.es then TLS negotiation failed as I suppose Tigase did not send client certificate. Thank you for bringing this issue to our attention
	Luis G.F commented 1 decade ago OK, problem found. I have my server configured with a DH param of 2048 key size, the problem is that Java doesn't support Diffie-Hellman Keys greather than 1024 bits, then tigase fails if the other side has a greather dhparam set. I test that in my dev server (disabling the dh key of 2048) and "voilá", tigase.im connection works now.
	Luis G.F commented 1 decade ago The problem is that i can't downgrade my cipher strengh to support legacy servers that don't support DH Keys >1024. If tigase.im don't fix the issue the connection between us should be impossible.
	Andrzej Wójcik (Tigase) commented 1 decade ago Issue with DH key > 1024 is more complicated as Tigase XMPP Server is using TLS mechanisms from Java which in Java 7 is limited to DH <= 1024. This is fixed in upcoming Java 8 from what I have read, but I suppose that we will need to wait some time before Java 8 will be released as Java 8 is planned to be released on 18 of march 2014.
	Simon Tennant commented 1 decade ago While large DH keys are a problem, JavaTM Cryptography Extension is supposed to fix this. At the same time, I'm running with Prosody's default DH params (less than 2048) but still see this.
	Andrzej Wójcik (Tigase) commented 1 decade ago Fixed sending client certificate on outgoing S2S connection when STARTTLS is used.
	Daniele Ricci commented 8 years ago I'm having issues (ssl handshake failed, unfortunately no other details on neither Tigase nor Prosody ends) with Prosody and Tigase in hardened mode (with 2048-bit DH parameters). You said: Fixed sending client certificate on outgoing S2S connection when STARTTLS is used. Does that need activation through a parameter? What certificate will it be using? The server one?
	Daniele Ricci commented 8 years ago Ok I just saw the commit, it's using the server certificate alright. Any advice on how to debug this? I'm getting crazy about this because I can't debug it in any way. My server is classified as "A" on the xmpp.net test: https://xmpp.net/result.php?id=484793
	Andrzej Wójcik (Tigase) commented 8 years ago Issue reported in this task was solved 2 years ago and confirmed fix works out of a box without any issues. I would suggest to enable debugging of `tigase.io` and `tigase.server` packages but it will generate a lot of logs. `--debug=server,io` Please use our forums if you need help with particular cases which are not yet confirmed to be bugs in Tigase and I would recommend not to reopen or comment on closed task.