[Devel] TLS ...

[Klaus Darilion]

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?

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
>>