[Serusers] TLS configuration problem (was TLS comments)

[Klaus Darilion]

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 at pernau.at> wrote:
>>>
>>>> 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?
>>>>
>>>
>>> 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 at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
> 
>