[sr-dev] TLS docs

[Olle E. Johansson]

10 okt 2009 kl. 14.51 skrev Jan Janak:

> On Sat, Oct 10, 2009 at 2:21 PM, Andrei Pelinescu-Onciul
> <andrei at iptel.org> wrote:
>> On Oct 10, 2009 at 14:04, Jan Janak <jan at ryngle.com> wrote:
>>> On Sat, Oct 10, 2009 at 1:58 PM, Olle E. Johansson  
>>> <oej at 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