<title><varname>config</varname> (string)</title> <para> Sets the name of the TLS specific config file. </para> <para> If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. </para>
Is this still valid - that we only configure tls on IP?
/O
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson oej@edvina.net wrote:
<title><varname>config</varname> (string)</title> <para> Sets the name of the TLS specific config file. </para> <para> If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. </para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
Jan.
10 okt 2009 kl. 14.04 skrev Jan Janak:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson oej@edvina.net wrote:
<title><varname>config</varname> (string)</title> <para> Sets the name of the TLS specific config file. </para> ; <para> If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. </para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
And we're in code freeze...
<para> This documentation is incomplete. The select framework and rpc sections are completely missing. </para>
Is this also on someone's list? Documentation is still open although code is frozen... ;-)
/O
On Sat, Oct 10, 2009 at 2:05 PM, Olle E. Johansson oej@edvina.net wrote:
10 okt 2009 kl. 14.04 skrev Jan Janak:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson oej@edvina.net wrote:
<title><varname>config</varname> (string)</title> <para> Sets the name of the TLS specific config file. </para> ; <para> If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. </para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
And we're in code freeze...
<para> This documentation is incomplete. The select framework and rpc sections are completely missing. </para>
Is this also on someone's list? Documentation is still open although code is frozen... ;-)
It is not on mine, so probably not :-). Documenting selects and RPCs for TLS module would be very helpful if you have the time.
We have to RPC commands, tls.reload and tls.list. The command tls.reload can be used to reload the TLS configuration file at runtime. The command tls.list lists all active TLS connections, the output of tls.list contains the following fields: id, timeout, src_ip, src_port, dst_ip, dst_port, and tls (extra TLS information, such as ciphers used).
The module supports both Kamailio TLS PVs and SER selects. They are both implemented in file tls_select.c. That's where you can get the list of currently implemented PVs.
The list of implemented TLS selects is here:
http://sip-router.org/wiki/cookbooks/selects/devel
look for selects starting with @tls. Note that there are aliases, so @tls.peer.cn, @tls.peer.commonName, @tls.peer.common_name, and @tls.peer.name all implement the same thing. I think we should document just one variant, for example all names that use _ as delimiter.
Jan.
On Oct 10, 2009 at 14:04, Jan Janak jan@ryngle.com wrote:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson oej@edvina.net wrote:
??<title><varname>config</varname> (string)</title> ?? ?? ?? ??<para> ?? ?? ?? ?? ?? ?? ?? ??Sets the name of the TLS specific config file. ?? ?? ?? ??</para> ?? ?? ?? ??<para> ?? ?? ?? ?? ?? ?? ?? ??If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. ?? ?? ?? ??</para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
I think this is something that can wait. The server name extension is quite new in openssl (on by default since 1.0). I doubt there are many clients supporting it and unless all or most your clients support it is quite useless (it's used for virtual domains). As a matter of fact does anybody know any? (for testing)
Andrei
On Sat, Oct 10, 2009 at 2:21 PM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Oct 10, 2009 at 14:04, Jan Janak jan@ryngle.com wrote:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson oej@edvina.net wrote:
??<title><varname>config</varname> (string)</title> ?? ?? ?? ??<para> ?? ?? ?? ?? ?? ?? ?? ??Sets the name of the TLS specific config file. ?? ?? ?? ??</para> ?? ?? ?? ??<para> ?? ?? ?? ?? ?? ?? ?? ??If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. ?? ?? ?? ??</para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
I think this is something that can wait. The server name extension is quite new in openssl (on by default since 1.0). I doubt there are many clients supporting it and unless all or most your clients support it is
It is also useful for server-to-server connections, there it allows you to select and present the correct certificate. Even if you have no clients that support it, you might still want to use the server name extension for server-to-server connections.
Jan.
10 okt 2009 kl. 14.51 skrev Jan Janak:
On Sat, Oct 10, 2009 at 2:21 PM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Oct 10, 2009 at 14:04, Jan Janak jan@ryngle.com wrote:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson oej@edvina.net wrote:
??<title><varname>config</varname> (string)</title> ?? ?? ?? ??<para> ?? ?? ?? ?? ?? ?? ?? ??Sets the name of the TLS specific config file. ?? ?? ?? ??</para> ?? ?? ?? ??<para> ?? ?? ?? ?? ?? ?? ?? ??If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. ?? ?? ?? ??</para>
Is this still valid - that we only configure tls on IP?
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
I think this is something that can wait. The server name extension is quite new in openssl (on by default since 1.0). I doubt there are many clients supporting it and unless all or most your clients support it is
It is also useful for server-to-server connections, there it allows you to select and present the correct certificate. Even if you have no clients that support it, you might still want to use the server name extension for server-to-server connections.
Well, to support the current proposal we should have a security association on every TLS link between ourself and other servers, where we remember which domain we verified for this link. We can't reuse this connection for other links between ourself and the peer for other domains.
Now, I have a problem with the subj alt names, but that is something that I need to discuss on IETF mailing lists... I don't really like mixing verification of a server with hostname and authorization in the same certificate.
We did a lot of tests of TLS at SIPit, me and Nils Ohlmeier. We used the configuration script verification procedures, which (as we say in the documentation) is a bit late, but nevertheless is working.
/O
On Sat, Oct 10, 2009 at 3:39 PM, Olle E. Johansson oej@edvina.net wrote:
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
I think this is something that can wait. The server name extension is quite new in openssl (on by default since 1.0). I doubt there are many clients supporting it and unless all or most your clients support it is
It is also useful for server-to-server connections, there it allows you to select and present the correct certificate. Even if you have no clients that support it, you might still want to use the server name extension for server-to-server connections.
Well, to support the current proposal we should have a security association on every TLS link between ourself and other servers, where we remember which domain we verified for this link. We can't reuse this connection for other links between ourself and the peer for other domains.
Yes, exactly, there are issues like that with connection reuse. That's one of the reason why adding support for server name takes more than a trivial change of the TLS configuration file format.
Anyway, we have more issues in TLS related code to take care of, we won't be able to address them before the next release, but maybe we could make them priority for the over-next release.
Jan.
10 okt 2009 kl. 20.17 skrev Jan Janak:
On Sat, Oct 10, 2009 at 3:39 PM, Olle E. Johansson oej@edvina.net wrote:
Currently yes. It is on my todo list to extend the configuration file syntax to also support server names, but I am not there yet.
I think this is something that can wait. The server name extension is quite new in openssl (on by default since 1.0). I doubt there are many clients supporting it and unless all or most your clients support it is
It is also useful for server-to-server connections, there it allows you to select and present the correct certificate. Even if you have no clients that support it, you might still want to use the server name extension for server-to-server connections.
Well, to support the current proposal we should have a security association on every TLS link between ourself and other servers, where we remember which domain we verified for this link. We can't reuse this connection for other links between ourself and the peer for other domains.
Yes, exactly, there are issues like that with connection reuse. That's one of the reason why adding support for server name takes more than a trivial change of the TLS configuration file format.
Understood.
Anyway, we have more issues in TLS related code to take care of, we won't be able to address them before the next release, but maybe we could make them priority for the over-next release.
Yes, right now we gotta focus on bug-fixing and getting ready for release, which means fixing a LOT of documentation. There's tons of confusing old files that need to be evaluated. We gotta look at our product with the eyes of a new user as well as a current user that wants to upgrade, and fix documentation, make it easy, cool and productive to select a sip-router distribution.
This propably means some changes to our web sites as well.
/O
Olle E. Johansson wrote:
<title><varname>config</varname> (string)</title> <para> Sets the name of the TLS specific config file. </para> <para> If set the TLS module will load a special config file, in which different TLS parameters can be specified on a per role (server or client) and domain basis (for now only IPs). The corresponding module parameters will be ignored. </para>
Is this still valid - that we only configure tls on IP?
"name based" TLS "domains" were supported in Kamailio core, based on an AVP set in script.
regards klaus
Klaus,
On Tue, Oct 13, 2009 at 2:19 PM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...] Is this still valid - that we only configure tls on IP?
"name based" TLS "domains" were supported in Kamailio core, based on an AVP set in script.
But this only works for newly established connections, right? When a connection is already established (possibly with a different SSL context or when it is initiated from the other side), the code won't change the SSL context. Do I get it right?
-- Jan
Jan Janak wrote:
Klaus,
On Tue, Oct 13, 2009 at 2:19 PM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...] Is this still valid - that we only configure tls on IP?
"name based" TLS "domains" were supported in Kamailio core, based on an AVP set in script.
But this only works for newly established connections, right? When a connection is already established (possibly with a different SSL context or when it is initiated from the other side), the code won't change the SSL context. Do I get it right?
Hi Jan!
I can't remember anymore how I implemented it. IIRC, if the the "TLS_AVP" was set, the TLS "client" did not tried a matching "TLS domain" based on IP:port, but on the string in the AVP.
This could be used for example, to use a certain client certificate and CA-file depending on the called domain, regardless of the destination IP:port.
Yes, this worked only for outgoing connections. For incoming connections, I think the server_name extension can help a bit, but even better would be support for "trusted_ca_keys".
Regarding existing connections - I do not know, I can't remember anymore.
regards klaus
-
Andrei Pelinescu-Onciul -
Jan Janak -
Klaus Darilion -
Olle E. Johansson