[Devel] TLS ...

[Daniel-Constantin Mierla]

On 02/22/06 17:58, Klaus Darilion wrote:
> Daniel-Constantin Mierla wrote:
>> On 02/22/06 16:52, Klaus Darilion wrote:
>>> I just got another idea/question: How should the certificate 
>>> parameters be exported?
>>>
>>> ° via AVPs during a dedicated call
>>>   tls_get_cert_subject("s:cert_subject");
>>>
>>> ° via pre-defined AVPs
>>>    tls_get_cert_params(); # copy parameters into
>>>                           # predefined AVPs
>>>
>>> ° via pseude variables
>>>   $cs    # certificate subject
>>>   $cc    # certificate common name
>>>   $cin    # certificate issuer name
>>>   $cif    # certificate issuer fingerprint
>>>   ...
>>>
>>> any comments?
>> They should be pure pseudo-variables (non-avp) since they are read 
>> only. It is in the plan of the development version to add support for 
>> longer names for pseudo-variables under a $(pseudo-variable-name) 
>> format and allow the modules to register custom pseudo-variables at 
>> runtime. I will start working on it after the 1.0.1 release.
>
> I've studied the pseudo variables parser and as far as I see they just 
> reference to existing buffers, e.g.:
>
>         res->rs.s = msg->callid->body.s;
>         res->rs.len = msg->callid->body.len;
>
>
> In the case of certificate parameters, there are no existing buffers. 
> Thus, when e.g. using $cs (certificate subject), a new buffer must be 
> created for the ASCII version of the subject.
>
> How can be ensured, that this is buffer is freed after message 
> processing?
there could be some static buffers, some pseudo-variables are using such 
buffers - like time, or all conversion from int to str are using a 
static buffer all over the openser/ser.

Cheers,
Daniel

>
> regards
> klaus
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> Cheers,
>> Daniel
>>
>>>
>>> regards
>>> klaus
>>>
>>>
>>> Klaus Darilion wrote:
>>>> Hi!
>>>>
>>>> I've written a small tlsops module with the function 
>>>> is_peer_verified() which allows to check if the request was 
>>>> received via validated TLS connection.
>>>>
>>>> This is done via:
>>>> 1. get tcp connection of received msg
>>>> 2. get extra data (= SSL)
>>>> 3. SSL_get_verify_result(ssl);
>>>>
>>>> This can be easily extended to fetch certificate parameters.
>>>>
>>>> Consider a scenario where a TLS connection is setup and stays open 
>>>> for a long time and there are lots of messages received via this 
>>>> connection.
>>>>
>>>> Then, using the above steps might be a little bit complicated. 
>>>> Maybe it might perform better to retrieve interesting parameters 
>>>> (common name, issuer, ...) only once during tls_accept/tcp_connect 
>>>> and store them together with the tcp connection (e.g. 
>>>> tcp_connection->extra_data2).
>>>>
>>>> Thus, retrieving TLS parameters does not require to retrieve the 
>>>> parameters from the openssl stack, but from the tcp_connection 
>>>> structure. I do not know if this is really a performance gain - 
>>>> depends on the handling inside of openssl.
>>>>
>>>> Further: tcp_connection->extra_data
>>>> Is this used only for storing SSL? If yes, maybe we should rename 
>>>> it to
>>>> tcp_connection->ssl ?
>>>>
>>>> regards
>>>> klaus
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>
>
>