Hi!
I've tried the new TLS module:
1. It breaks compatibility with old TLS stack: Even when configured to use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
2. If there is an error during the TLS handshake (like above), ser keeps hanging without doing anything. IMO it shoud respond with error message (like it does when it can't establish a TCP connection):
ser other proxy --INVITE--> <-100 ----- <-----TCP handshake----> --------TLS HELLO------> <---TCP RST ------------ ..... nothing happens ..... Instead I would expect: <-477 TLS error---
00:21:41 server1 ser[3792]: ERROR: tls_server.c:275: IO error: (104) Connection reset by peer 00:21:41 server1 ser[3792]: ERROR: tcp_send: failed to send
regards Klaus
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client. Have not checked this ... but i think it is the way it is supposed to work.
Cesc
Hi!
I guess the problem is caused by wrong configuration. I want ser to use just the same certificate in all cases. I've configured ser:
modparam("tls", "tls_log", 3) modparam("tls", "method", "TLSv1") modparam("tls", "verify_certificate", "0") modparam("tls", "require_certificate", "0") modparam("tls", "certificate", "/etc/proxyCert2/cert.pem") modparam("tls", "private_key", "/etc/proxyCert2/privkey.pem") modparam("tls", "ca_list", "/etc/demoCA/cacert.pem") modparam("tls", "send_timeout", 15) modparam("tls", "handshake_timeout", 15) modparam("tls", "connection_timeout", 120)
But this does not work: INFO: tls_domain.c:228: TLSs<default>: Cipher list not configured, using default value (null) INFO: tls_domain.c:210: TLSc<default>: No certificate configured, using default '(null)' INFO: tls_domain.c:216: TLSc<default>: No CA list configured, using default '(null)' INFO: tls_domain.c:228: TLSc<default>: Cipher list not configured, using default value (null) INFO: tls_domain.c:234: TLSc<default>: No private key configured, using default '(null)'
Viewing the code I found: if (*s.s == '@') { *type |= TLS_DOMAIN_CLI;
Thus it tried adding '@' in front of the value but this does not work too. modparam("tls", "private_key", "@/etc/proxyCert2/privkey.pem")
ERROR: tls_init.c:253: TLSc<default>: Unable to load certificate file '@/etc/proxyCert1/cert.pem'
Maybe I'm to stupid, but I can't figure out how to set the default TLS domains. How is it done correct?
regards klaus
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client. Have not checked this ... but i think it is the way it is supposed to work.
Cesc
Is there a bug in the tls configuration part? Using this patch ser accpets also paramters for the client domains when using '@' as first character of the parameter value.
Index: tls_mod.c =================================================================== RCS file: /cvsroot/ser/sip_router/modules/tls/tls_mod.c,v retrieving revision 1.1 diff -u -r1.1 tls_mod.c --- tls_mod.c 28 Jan 2006 12:34:31 -0000 1.1 +++ tls_mod.c 1 Feb 2006 18:57:08 -0000 @@ -206,7 +206,7 @@
if (!strchr(s.s, '=')) { DBG("No TLS domain specifier found\n"); - *text = val; + *text = s.s; *type |= TLS_DOMAIN_DEF; return 0; }
regards klaus
Klaus Darilion wrote:
Hi!
I guess the problem is caused by wrong configuration. I want ser to use just the same certificate in all cases. I've configured ser:
modparam("tls", "tls_log", 3) modparam("tls", "method", "TLSv1") modparam("tls", "verify_certificate", "0") modparam("tls", "require_certificate", "0") modparam("tls", "certificate", "/etc/proxyCert2/cert.pem") modparam("tls", "private_key", "/etc/proxyCert2/privkey.pem") modparam("tls", "ca_list", "/etc/demoCA/cacert.pem") modparam("tls", "send_timeout", 15) modparam("tls", "handshake_timeout", 15) modparam("tls", "connection_timeout", 120)
But this does not work: INFO: tls_domain.c:228: TLSs<default>: Cipher list not configured, using default value (null) INFO: tls_domain.c:210: TLSc<default>: No certificate configured, using default '(null)' INFO: tls_domain.c:216: TLSc<default>: No CA list configured, using default '(null)' INFO: tls_domain.c:228: TLSc<default>: Cipher list not configured, using default value (null) INFO: tls_domain.c:234: TLSc<default>: No private key configured, using default '(null)'
Viewing the code I found: if (*s.s == '@') { *type |= TLS_DOMAIN_CLI;
Thus it tried adding '@' in front of the value but this does not work too. modparam("tls", "private_key", "@/etc/proxyCert2/privkey.pem")
ERROR: tls_init.c:253: TLSc<default>: Unable to load certificate file '@/etc/proxyCert1/cert.pem'
Maybe I'm to stupid, but I can't figure out how to set the default TLS domains. How is it done correct?
regards klaus
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client. Have not checked this ... but i think it is the way it is supposed to work.
Cesc
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi all!
I wonder if this TLS module if even working. First, I had to patch ser to allow settings for the default client TLS domain, but still I can't connect. Not even ser<-->ser works.
I always get the following error on the client side:
ser[2559]: ERROR: tls_server.c:281: SSL error:error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable
I've tried setting the cipher manually but I still get the same error. Is this TLS module really wokring for you?
I'm using openssl 0.9.7e-3sarge1 (debian stable)
regards klaus
Klaus Darilion wrote:
Is there a bug in the tls configuration part? Using this patch ser accpets also paramters for the client domains when using '@' as first character of the parameter value.
Index: tls_mod.c
RCS file: /cvsroot/ser/sip_router/modules/tls/tls_mod.c,v retrieving revision 1.1 diff -u -r1.1 tls_mod.c --- tls_mod.c 28 Jan 2006 12:34:31 -0000 1.1 +++ tls_mod.c 1 Feb 2006 18:57:08 -0000 @@ -206,7 +206,7 @@
if (!strchr(s.s, '=')) { DBG("No TLS domain specifier found\n");
*text = val;
*text = s.s; *type |= TLS_DOMAIN_DEF; return 0; }regards klaus
Klaus Darilion wrote:
Hi!
I guess the problem is caused by wrong configuration. I want ser to use just the same certificate in all cases. I've configured ser:
modparam("tls", "tls_log", 3) modparam("tls", "method", "TLSv1") modparam("tls", "verify_certificate", "0") modparam("tls", "require_certificate", "0") modparam("tls", "certificate", "/etc/proxyCert2/cert.pem") modparam("tls", "private_key", "/etc/proxyCert2/privkey.pem") modparam("tls", "ca_list", "/etc/demoCA/cacert.pem") modparam("tls", "send_timeout", 15) modparam("tls", "handshake_timeout", 15) modparam("tls", "connection_timeout", 120)
But this does not work: INFO: tls_domain.c:228: TLSs<default>: Cipher list not configured, using default value (null) INFO: tls_domain.c:210: TLSc<default>: No certificate configured, using default '(null)' INFO: tls_domain.c:216: TLSc<default>: No CA list configured, using default '(null)' INFO: tls_domain.c:228: TLSc<default>: Cipher list not configured, using default value (null) INFO: tls_domain.c:234: TLSc<default>: No private key configured, using default '(null)'
Viewing the code I found: if (*s.s == '@') { *type |= TLS_DOMAIN_CLI;
Thus it tried adding '@' in front of the value but this does not work too. modparam("tls", "private_key", "@/etc/proxyCert2/privkey.pem")
ERROR: tls_init.c:253: TLSc<default>: Unable to load certificate file '@/etc/proxyCert1/cert.pem'
Maybe I'm to stupid, but I can't figure out how to set the default TLS domains. How is it done correct?
regards klaus
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client. Have not checked this ... but i think it is the way it is supposed to work.
Cesc
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Klaus,
Klaus Darilion wrote:
Hi all!
I wonder if this TLS module if even working. First, I had to patch ser to allow settings for the default client TLS domain, but still I can't connect. Not even ser<-->ser works.
Yes, it works. Configuration of the client part was not done yet(see my email on serdev, it was mentioned there), I fixed that already and will commit it shortly. But this is not a problem as long as you only use the default client domain, because in that case you can just put the certificate in the default path and it will work.
I always get the following error on the client side:
ser[2559]: ERROR: tls_server.c:281: SSL error:error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable
I've tried setting the cipher manually but I still get the same error. Is this TLS module really wokring for you?
I have tested this several times and it working for me. Could you send me your tls configuration, so that I can retry it ?
Jan.
Jan Janak wrote:
Hi Klaus,
Klaus Darilion wrote:
Hi all!
I wonder if this TLS module if even working. First, I had to patch ser to allow settings for the default client TLS domain, but still I can't connect. Not even ser<-->ser works.
Yes, it works. Configuration of the client part was not done yet(see my email on serdev, it was mentioned there), I fixed that already and will commit it shortly. But this is not a problem as long as you only use the default client domain, because in that case you can just put the certificate in the default path and it will work.
I always get the following error on the client side:
ser[2559]: ERROR: tls_server.c:281: SSL error:error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable
I've tried setting the cipher manually but I still get the same error. Is this TLS module really wokring for you?
I have tested this several times and it working for me. Could you send me your tls configuration, so that I can retry it ?
modparam("tls", "tls_log", 3) modparam("tls", "send_timeout", 15) modparam("tls", "handshake_timeout", 15) modparam("tls", "connection_timeout", 120) # default incoming (server) domain modparam("tls", "method", "TLSv1") modparam("tls", "verify_certificate", "0") modparam("tls", "require_certificate", "0") modparam("tls", "certificate", "/etc/proxyCert1/cert.pem") modparam("tls", "private_key", "/etc/proxyCert1/privkey.pem") modparam("tls", "ca_list", "/etc/demoCA/cacert.pem") # default outgoing (client) domain # # add patch to support "@" for client configuration # modparam("tls", "method", "@TLSv1") modparam("tls", "verify_certificate", "@0") modparam("tls", "require_certificate", "@0") modparam("tls", "certificate", "@/etc/proxyCert1/cert.pem") modparam("tls", "private_key", "@/etc/proxyCert1/privkey.pem") modparam("tls", "ca_list", "@/etc/demoCA/cacert.pem")
Note that I'm using my patch to configure the default client domain.
regarding "LS1_SETUP_KEY_BLOCK:cipher or hash unavailable": Which openssl version do you use?
regards klaus
Klaus Darilion wrote:
regarding "LS1_SETUP_KEY_BLOCK:cipher or hash unavailable": Which openssl version do you use?
Currently 0.9.8a-6, but I was using the version from debian/stable before without problems.
Jan.
Jan Janak wrote:
Klaus Darilion wrote:
regarding "LS1_SETUP_KEY_BLOCK:cipher or hash unavailable": Which openssl version do you use?
Currently 0.9.8a-6, but I was using the version from debian/stable before without problems.
I've also tested now 0.9.8a-6 and still get the same error. Very strange. Googling for this problem reveals several threads and several applications which sometimes has this problem but they never find a reason :-(
regards klaus
Jan Janak wrote:
Hi Klaus,
Klaus Darilion wrote:
Hi all!
I wonder if this TLS module if even working. First, I had to patch ser to allow settings for the default client TLS domain, but still I can't connect. Not even ser<-->ser works.
Yes, it works. Configuration of the client part was not done yet(see my email on serdev, it was mentioned there), I fixed that already and will commit it shortly. But this is not a problem as long as you only use the default client domain, because in that case you can just put the certificate in the default path and it will work.
Hi Jan!
The more I reveiw the code the more I come to the conslusion that the TLS code you are using is different to the TLS code released.
e.g. the default settings in config.h are wrong: #define TLS_PKEY_FILE CFG_DIR "cert.pem" #define TLS_CERT_FILE CFG_DIR "cert.pem" ^^^^^^^^
You said it should work fine as long as I use the default client domain. But in the default client domain the keys are set to 0:
/* Default client domain */ d->cert_file = 0; d->pkey_file = 0; d->verify_cert = 1; d->verify_depth = 3; d->ca_file = 0; d->require_cert = 1; d->method = TLS_USE_SSLv23; tls_def_cli = d;
So, are we talking about the same TLS code?
regards klaus
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client.
Yes, I think this is correct. The protocol version should be set to TLSv1 afterwards, you can test this with @tls.version:
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
Jan.
On Feb 01, 2006 at 14:43, Jan Janak jan@iptel.org wrote:
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client.
Yes, I think this is correct. The protocol version should be set to TLSv1 afterwards, you can test this with @tls.version:
No, he is right, this is a bug.
A normal TLSv1 server will accept only TLS hello messages (version = 3.1) and since sip is supposed to work only with TLS, this should be the default (tls_method=TLS_USE_TLSv1). The SSLv23 stuff will accept any type of hello. A client with the SSLv23 method will send a hello v2 message, indicating in it also tls and ssl 3.0 support (they will include tls specific ciphers a.s.o). The client sending v2 hellos is not exactly standard behaviour for TLS. It is a hack for backward compatibility, but a TLS only server will not accept it. One of the clients that used a SSLv23 equivalent was Windows Messenger (it was doing this in 2003 when I wrote my ser tls code).
The tls method should be configurable to allow older/strange clients support, but it should default to TLSv1 (btw: this is how you can reject v2 clients without SSL_OP_NO_SSLv2).
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for. Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not. If you need special verify on only for some clients, either make it per ip, or use another tls port on which you have verify turned on.
Andrei
Andrei Pelinescu-Onciul wrote:
On Feb 01, 2006 at 14:43, Jan Janak jan@iptel.org wrote:
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client.
Yes, I think this is correct. The protocol version should be set to TLSv1 afterwards, you can test this with @tls.version:
No, he is right, this is a bug.
There was a problem in the configuration, since the protocol version was not set correctly (this is now separated), so in fact the TLS client in tls module was configured with SSLv23. Only tls server was configured for TLSv1.
A normal TLSv1 server will accept only TLS hello messages (version = 3.1) and since sip is supposed to work only with TLS, this should be the default (tls_method=TLS_USE_TLSv1). The SSLv23 stuff will accept any type of hello. A client with the SSLv23 method will send a hello v2 message, indicating in it also tls and ssl 3.0 support (they will include tls specific ciphers a.s.o). The client sending v2 hellos is not exactly standard behaviour for TLS. It is a hack for backward compatibility, but a TLS only server will not accept it. One of the clients that used a SSLv23 equivalent was Windows Messenger (it was doing this in 2003 when I wrote my ser tls code).
The tls method should be configurable to allow older/strange clients support, but it should default to TLSv1 (btw: this is how you can reject v2 clients without SSL_OP_NO_SSLv2).
Right now it defaults to SSLv23, should we change the defaults ?
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for.
This was just debugging tip for Klaus. I think that the only case when sending a SIP reply back is when the client presents a valid certificate but the common name (or any other field used for authentication) is invalid. That is if the client presented a valid certificate but incorrect one then we should reject politely, otherwise tls handshake just fails.
Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not.
The verification process does not include checking of common name, subject alternative name and other certificate fields. This is what you should do in the script.
Jan.
On Feb 03, 2006 at 15:48, Jan Janak jan@iptel.org wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 01, 2006 at 14:43, Jan Janak jan@iptel.org wrote:
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client.
Yes, I think this is correct. The protocol version should be set to TLSv1 afterwards, you can test this with @tls.version:
No, he is right, this is a bug.
There was a problem in the configuration, since the protocol version was not set correctly (this is now separated), so in fact the TLS client in tls module was configured with SSLv23. Only tls server was configured for TLSv1.
A normal TLSv1 server will accept only TLS hello messages (version = 3.1) and since sip is supposed to work only with TLS, this should be the default (tls_method=TLS_USE_TLSv1). The SSLv23 stuff will accept any type of hello. A client with the SSLv23 method will send a hello v2 message, indicating in it also tls and ssl 3.0 support (they will include tls specific ciphers a.s.o). The client sending v2 hellos is not exactly standard behaviour for TLS. It is a hack for backward compatibility, but a TLS only server will not accept it. One of the clients that used a SSLv23 equivalent was Windows Messenger (it was doing this in 2003 when I wrote my ser tls code).
The tls method should be configurable to allow older/strange clients support, but it should default to TLSv1 (btw: this is how you can reject v2 clients without SSL_OP_NO_SSLv2).
Right now it defaults to SSLv23, should we change the defaults ?
Yes, I think so, a normal SIP implementation should speak TLSv1.
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for.
This was just debugging tip for Klaus. I think that the only case when sending a SIP reply back is when the client presents a valid certificate but the common name (or any other field used for authentication) is invalid. That is if the client presented a valid certificate but incorrect one then we should reject politely, otherwise tls handshake just fails.
Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not.
The verification process does not include checking of common name, subject alternative name and other certificate fields. This is what you should do in the script.
No, I think you should have a verify all option. You could use then the script to allow access to certain resources only to certain clients, but the certificate validity checks should be done at the tls level.
BTW: the above example should use exit -1 instead of break (to force close the tls connection, which otherwise would remain open until it timeouts or the remote side closes).
Andrei
Andrei Pelinescu-Onciul wrote:
On Feb 03, 2006 at 15:48, Jan Janak jan@iptel.org wrote:
Andrei Pelinescu-Onciul wrote:
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for.
This was just debugging tip for Klaus. I think that the only case when sending a SIP reply back is when the client presents a valid certificate but the common name (or any other field used for authentication) is invalid. That is if the client presented a valid certificate but incorrect one then we should reject politely, otherwise tls handshake just fails.
Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not.
The verification process does not include checking of common name, subject alternative name and other certificate fields. This is what you should do in the script.
No, I think you should have a verify all option. You could use then the script to allow access to certain resources only to certain clients, but the certificate validity checks should be done at the tls level.
I think this is not possible in all cases. There are many SIP scenarios where you can not check the domains. For example in-dialog requests with forwarding scenarios. Orwhen the TLS connection has to reestablished for responses. Then which SIP domain do you use?
regards klaus
On Feb 03, 2006 at 16:02, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 03, 2006 at 15:48, Jan Janak jan@iptel.org wrote:
Andrei Pelinescu-Onciul wrote:
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for.
This was just debugging tip for Klaus. I think that the only case when sending a SIP reply back is when the client presents a valid certificate but the common name (or any other field used for authentication) is invalid. That is if the client presented a valid certificate but incorrect one then we should reject politely, otherwise tls handshake just fails.
Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not.
The verification process does not include checking of common name, subject alternative name and other certificate fields. This is what you should do in the script.
No, I think you should have a verify all option. You could use then the script to allow access to certain resources only to certain clients, but the certificate validity checks should be done at the tls level.
I think this is not possible in all cases. There are many SIP scenarios where you can not check the domains. For example in-dialog requests with forwarding scenarios. Orwhen the TLS connection has to reestablished for responses. Then which SIP domain do you use?
That's why you should set tls certificates/cas on an ip base (it would be easy to choose the correct certificate/ca). The tls "extended" certificate checks will just make sure that the certificate was issued for the ip or dns name of the peer.
This should be a configuration option (e.g tl_verify= off|on|extended). What I'm trying to say is that certificate validity checks don't make sense in the script, in the "normal scenarios". You could use them (with tls_verify=on), but not to deny access in general, just for some limited resources (e.g. allow local calls, but permit relaying only if <extra certificate checks>).
Andrei
regards klaus
Andrei Pelinescu-Onciul wrote:
On Feb 03, 2006 at 15:48, Jan Janak jan@iptel.org wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 01, 2006 at 14:43, Jan Janak jan@iptel.org wrote:
Cesc wrote:
On 2/1/06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I've tried the new TLS module:
- It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063) 1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello Version 3.1
I do not know if this is a problem with the new or the old stack. Further I do not know what other TLS enabled SIP products use. Do they accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is always v2 and then (with the server hello message) the handshake is upgraded to v3 or tlsv1. This way, you can have an sslv2-only client try connecting to any server, but the server will send back sslv3 or tlsv1 server hello, thus disconnecting the client.
Yes, I think this is correct. The protocol version should be set to TLSv1 afterwards, you can test this with @tls.version:
No, he is right, this is a bug.
There was a problem in the configuration, since the protocol version was not set correctly (this is now separated), so in fact the TLS client in tls module was configured with SSLv23. Only tls server was configured for TLSv1.
A normal TLSv1 server will accept only TLS hello messages (version = 3.1) and since sip is supposed to work only with TLS, this should be the default (tls_method=TLS_USE_TLSv1). The SSLv23 stuff will accept any type of hello. A client with the SSLv23 method will send a hello v2 message, indicating in it also tls and ssl 3.0 support (they will include tls specific ciphers a.s.o). The client sending v2 hellos is not exactly standard behaviour for TLS. It is a hack for backward compatibility, but a TLS only server will not accept it. One of the clients that used a SSLv23 equivalent was Windows Messenger (it was doing this in 2003 when I wrote my ser tls code).
The tls method should be configurable to allow older/strange clients support, but it should default to TLSv1 (btw: this is how you can reject v2 clients without SSL_OP_NO_SSLv2).
Right now it defaults to SSLv23, should we change the defaults ?
Yes, I think so, a normal SIP implementation should speak TLSv1.
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for.
This was just debugging tip for Klaus. I think that the only case when sending a SIP reply back is when the client presents a valid certificate but the common name (or any other field used for authentication) is invalid. That is if the client presented a valid certificate but incorrect one then we should reject politely, otherwise tls handshake just fails.
Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not.
The verification process does not include checking of common name, subject alternative name and other certificate fields. This is what you should do in the script.
No, I think you should have a verify all option. You could use then the script to allow access to certain resources only to certain clients, but the certificate validity checks should be done at the tls level.
But what do you want to verify at TLS level ? We cannot verify the source IP address because of NATs. Without the recent openssl extension we do not know the server the client is trying to reach. We can probably verify the fingerprint of the certificate against a list of certificate fingerprints, but that is better done in the script too, because otherwise we would need to hardcoded this functionality in tls module.
What else can we verify without seeing the SIP message and knowing the hostname of the virtual server ?
BTW: the above example should use exit -1 instead of break (to force close the tls connection, which otherwise would remain open until it timeouts or the remote side closes).
Yes, you are right, this is better approach.
Jan.
-
Andrei Pelinescu-Onciul -
Cesc -
Jan Janak -
Klaus Darilion