Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
What do you think? I volunteer to do this if nobody objects.
Jan.
Hello,
On 02/23/2009 11:02 PM, Jan Janak wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
What do you think?
yes, tls has to be merged and keeping it as module is fine for me.
Does the ser core (sip router) still needs to be compiled with some TLS define in order to get the TLS support, or it is implicit and just loading the module will do it?
I volunteer to do this if nobody objects.
I do not object, thanks!
Cheers, Daniel
On Feb 23, 2009 at 23:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/23/2009 11:02 PM, Jan Janak wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
What do you think?
yes, tls has to be merged and keeping it as module is fine for me.
Does the ser core (sip router) still needs to be compiled with some TLS define in order to get the TLS support, or it is implicit and just loading the module will do it?
No, it's implicit. You have to set enable_tls in .cfg and load the tls module (if you don't load it and have enable_tls=yes you'll get a warning). There is also a define: TLS_HOOKS but's it's set by default.
Andrei
[...]
On 24-02 11:15, Andrei Pelinescu-Onciul wrote:
On Feb 23, 2009 at 23:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/23/2009 11:02 PM, Jan Janak wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
What do you think?
yes, tls has to be merged and keeping it as module is fine for me.
Does the ser core (sip router) still needs to be compiled with some TLS define in order to get the TLS support, or it is implicit and just loading the module will do it?
No, it's implicit. You have to set enable_tls in .cfg and load the tls module (if you don't load it and have enable_tls=yes you'll get a warning). There is also a define: TLS_HOOKS but's it's set by default.
Is the variable enable_tls really needed? Can't we get rid of it? Or maybe set it automatically when the tls module is loaded?
Jan.
On Feb 24, 2009 at 11:20, Jan Janak jan@iptel.org wrote:
On 24-02 11:15, Andrei Pelinescu-Onciul wrote:
On Feb 23, 2009 at 23:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/23/2009 11:02 PM, Jan Janak wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
What do you think?
yes, tls has to be merged and keeping it as module is fine for me.
Does the ser core (sip router) still needs to be compiled with some TLS define in order to get the TLS support, or it is implicit and just loading the module will do it?
No, it's implicit. You have to set enable_tls in .cfg and load the tls module (if you don't load it and have enable_tls=yes you'll get a warning). There is also a define: TLS_HOOKS but's it's set by default.
Is the variable enable_tls really needed? Can't we get rid of it? Or maybe set it automatically when the tls module is loaded?
Actually it's there because of the possibility to use tls in the core instead of the tls module and also to have a similar way of disabling/enabling tls with tcp and sctp. If you want auto-setting, change the default to 0 (tls_disable) and remove the LOG(L_WARN...) in main.c if (!tls_loaded()). While that would work, I think we need 3 state for tls enable/disable: auto (depends on tls module), force disable and force enable (if tls module is not loaded => warning or error).
Andrei
On 02/24/2009 12:15 PM, Andrei Pelinescu-Onciul wrote:
On Feb 23, 2009 at 23:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/23/2009 11:02 PM, Jan Janak wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
What do you think?
yes, tls has to be merged and keeping it as module is fine for me.
Does the ser core (sip router) still needs to be compiled with some TLS define in order to get the TLS support, or it is implicit and just loading the module will do it?
No, it's implicit.
great, it was a PITA to recompile everything for TLS. Packaging becomes more trivial, as well.
As we are here, other modules that are linked to ssl library are still affected by changes in the ssl lib (e.g., memory manager), right? IIRC, there were some issues related to the modules linked with curl library...
Cheers, Daniel
You have to set enable_tls in .cfg and load the tls module (if you don't load it and have enable_tls=yes you'll get a warning). There is also a define: TLS_HOOKS but's it's set by default.
Andrei
[...]
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Feb 24, 2009 at 15:10, Daniel-Constantin Mierla miconda@gmail.com wrote:
[...]
Does the ser core (sip router) still needs to be compiled with some TLS define in order to get the TLS support, or it is implicit and just loading the module will do it?
No, it's implicit.
great, it was a PITA to recompile everything for TLS. Packaging becomes more trivial, as well.
As we are here, other modules that are linked to ssl library are still affected by changes in the ssl lib (e.g., memory manager), right? IIRC, there were some issues related to the modules linked with curl library...
Yes, there is still a problem with them (e.g. auth_identity from ser). One of the way to work around it is to link openssl staticaly for all the modules that require different initialisation. Another possible way would be to have a common way of ssl initialization that would have to be used by all the openssl based modules.
Andrei [...]
On Feb 23, 2009 at 22:02, Jan Janak jan@iptel.org wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
I don't think there is anything to merge from kamailio tls core. It's just basic tls which is fully supported by ser tls module (they have a common ancestry anyway). Moreover ser tls has lots of workarounds in place for various bugs in openssl.
Regarding tlsops: we already have extensive ser select support in tls and as far as I understood from Daniel selects are/will be accessible via psedo-vars too. So does it make sense to port the pseudo vars from tlsops? Is that something extra supported by them?
What do you think? I volunteer to do this if nobody objects.
I would concentrate on tlsops and see if there are any "extras".
BTW: for anybody trying to use tls with sip-router: the tls module doesn't yet support the tcp async mode, so if you try to use it make sure tcp_buf_write=no (there are still some changes at the tcp level required for tls async and I haven't finished them yet).
Andrei
Andrei Pelinescu-Onciul wrote:
On Feb 23, 2009 at 22:02, Jan Janak jan@iptel.org wrote:
Hello,
If we want to make the sip-router core usable in both projects, we would also need to merge both tls implementations. In SER we moved the the TLS implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in the core and then there is tlsops module which contains pseudovariables used to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls implementation from kamailio core into ser tls module. In addition to that we could merge the implementation of tls related pseudovariables from tlsops into the tls module and then put the tls module into the sip-router repository.
I don't think there is anything to merge from kamailio tls core. It's just basic tls which is fully supported by ser tls module (they have a common ancestry anyway). Moreover ser tls has lots of workarounds in place for various bugs in openssl.
I think that's not true. K's TLS also supports name-based TLS domains (the TLS domain can be selected by setting an AVP) and it also supports the servername extension (multiple TLS domains use the same socket). AFAIK these features are not available in ser.
Regarding tlsops: we already have extensive ser select support in tls and as far as I understood from Daniel selects are/will be accessible via psedo-vars too. So does it make sense to port the pseudo vars from tlsops? Is that something extra supported by them?
IIRC the tlsops module is basically just the "select" ported from ser to Kamailio. Of course the servername pseudo variable is not available in the select.
Otherwise, if there is a generic mechanism to access "selects" via PV then the tlsops could be removed (with servername added to select).
regards klaus
Hi Andrei et al.
BTW: for anybody trying to use tls with sip-router: the tls module doesn't yet support the tcp async mode, so if you try to use it make sure tcp_buf_write=no (there are still some changes at the tcp level required for tls async and I haven't finished them yet).
Andrei
May i ask from You about Your plan "Async TLS" ? Are You, or any of You working on Async TLS currently? Are any plan to continue and finish the implementation this feature?
Regards, Misi
On Aug 12, 2009 at 21:13, M?SZ?ROS Mih?ly misi@niif.hu wrote:
Hi Andrei et al.
BTW: for anybody trying to use tls with sip-router: the tls module doesn't yet support the tcp async mode, so if you try to use it make sure tcp_buf_write=no (there are still some changes at the tcp level required for tls async and I haven't finished them yet).
Andrei
May i ask from You about Your plan "Async TLS" ? Are You, or any of You working on Async TLS currently?
No, I'm not working on it right now. I'll probably do it later in the autumn (after the September release) if there's enough interest in it and something more important won't come up.
I was planning to do it this summer, but lots of merge fixes + holidays kept me from working on it so far.
Are any plan to continue and finish the implementation this feature?
Yes, is just that more urgent things keep comming up :-)
Andrei
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
Klaus Darilion -
MÉSZÁROS Mihály