Bogdan-Andrei Iancu wrote:
Nils Ohlmeier wrote:
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
As it is now, the current tls code does not really allow for flexibility, i would say. How about creating some kind of module that would allow in-depth access to tls functions, such as
- tls_verify_peer_cert()
- tls_check_from()
- tls_check_to()
I agree. We will need this functions. We should also document what the current implementation is validating (when authenticating a server certificate: which domain is checked against which part of the certificate?) ...
Just a note: your are thinking/discussing here about the connection layer. But when the script is processed the connection is already established. So the only thing which you can do in the script is verifying the client certificate. As the connection is already established you can only reject the request on the SIP layer. And client certificates usually work only in proxy-toproxy scenarios, but not for typical UA's. Server certificate verification can only be handled by a global policy.
basically, there are two cases:
- incoming TLS connections - you can check the connection properties
from script (based on the source IP, like if it's a proxy peer, check if a certificate was provided). You may reject the connection on SIP level
How? I do not want to check IP addresses (static configuration). I want to use TLS to avoid checking IP addresses. We would need functions like Cesc suggested (tls_check_to ...)
regards klaus
- outgoing connections - you can set before relaying the desired
parameters for the outgoing TLS connection (again, based on the destination IP, if it's peer or not). In this case the rejection will take place directly at connection layer.
based on this you can deal in a secure way with both UAC and proxy certificated.
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users