11 Oct
2005
11 Oct
'05
11:44 a.m.
Nils Ohlmeier wrote:
On Monday 10 October 2005 19:54, Klaus Darilion wrote:
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:
1) 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
2) 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
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?) ...