10 Oct
2009
10 Oct
'09
2:58 p.m.
<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
10 Oct
10 Oct
3:04 p.m.
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson <oej(a)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.
3:05 p.m.
10 okt 2009 kl. 14.04 skrev Jan Janak:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson
<oej(a)edvina.net>
wrote:
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
<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.
3:31 p.m.
On Sat, Oct 10, 2009 at 2:05 PM, Olle E. Johansson <oej(a)edvina.net> wrote:
10 okt 2009 kl. 14.04 skrev Jan Janak:
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 Sat, Oct 10, 2009 at 1:58 PM, Olle E.
Johansson <oej(a)edvina.net> wrote:
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... ;-)
<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. 
3:21 p.m.
On Oct 10, 2009 at 14:04, Jan Janak <jan(a)ryngle.com> wrote:
On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson
<oej(a)edvina.net> wrote:
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
??<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.
3:51 p.m.
On Sat, Oct 10, 2009 at 2:21 PM, Andrei Pelinescu-Onciul
<andrei(a)iptel.org> wrote:
On Oct 10, 2009 at 14:04, Jan Janak
<jan(a)ryngle.com> wrote:
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.
On Sat, Oct 10, 2009 at 1:58 PM, Olle E.
Johansson <oej(a)edvina.net> wrote:
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
??<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.
4:39 p.m.
10 okt 2009 kl. 14.51 skrev Jan Janak:
On Sat, Oct 10, 2009 at 2:21 PM, Andrei
Pelinescu-Onciul
<andrei(a)iptel.org> wrote:
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 Oct 10, 2009 at 14:04, Jan Janak
<jan(a)ryngle.com> wrote:
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. On Sat, Oct 10, 2009 at 1:58 PM, Olle E.
Johansson
<oej(a)edvina.net> wrote:
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
??<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.
9:17 p.m.
On Sat, Oct 10, 2009 at 3:39 PM, Olle E. Johansson <oej(a)edvina.net> wrote:
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.
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
10:15 p.m.
10 okt 2009 kl. 20.17 skrev Jan Janak:
On Sat, Oct 10, 2009 at 3:39 PM, Olle E. Johansson
<oej(a)edvina.net>
wrote:
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.
> 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.
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
13 Oct
13 Oct
3:19 p.m.
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
15 Oct
15 Oct
3:24 a.m.
Klaus,
On Tue, Oct 13, 2009 at 2:19 PM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
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
[...]
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.
3:05 a.m.
Jan Janak wrote:
Klaus,
On Tue, Oct 13, 2009 at 2:19 PM, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
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
[...]
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.
5522
days inactive
5527
days old
11 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Jan Janak -
Klaus Darilion -
Olle E. Johansson