On Feb 03, 2006 at 16:02, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul wrote:
On Feb 03, 2006 at 15:48, Jan Janak jan@iptel.org wrote:
Andrei Pelinescu-Onciul wrote:
if (@tls.version == "SSLv2") { sl_send_reply("400", "Bad TLS protocol version"); break; }
I think we should not handle TLS errors from the script. A TLS client will expect the handshake phase to fail if it uses an unsupported SSL version or the wrong certificate. Accepting the ssl connection and then returning a SIP error or plainly dropping it, it's just wrong IMHO and not very TLS frienldy/conformant. That's what the handshake phase for.
This was just debugging tip for Klaus. I think that the only case when sending a SIP reply back is when the client presents a valid certificate but the common name (or any other field used for authentication) is invalid. That is if the client presented a valid certificate but incorrect one then we should reject politely, otherwise tls handshake just fails.
Moreover if you go to the trouble to accept the connection just to reject it immediately you will waste more resources. If you don't want to accept V2, then just change the method. For cetificates: you either verify them (you can have verify off, verify but don't check host name/ip, verify all) or not.
The verification process does not include checking of common name, subject alternative name and other certificate fields. This is what you should do in the script.
No, I think you should have a verify all option. You could use then the script to allow access to certain resources only to certain clients, but the certificate validity checks should be done at the tls level.
I think this is not possible in all cases. There are many SIP scenarios where you can not check the domains. For example in-dialog requests with forwarding scenarios. Orwhen the TLS connection has to reestablished for responses. Then which SIP domain do you use?
That's why you should set tls certificates/cas on an ip base (it would be easy to choose the correct certificate/ca). The tls "extended" certificate checks will just make sure that the certificate was issued for the ip or dns name of the peer.
This should be a configuration option (e.g tl_verify= off|on|extended). What I'm trying to say is that certificate validity checks don't make sense in the script, in the "normal scenarios". You could use them (with tls_verify=on), but not to deny access in general, just for some limited resources (e.g. allow local calls, but permit relaying only if <extra certificate checks>).
Andrei
regards klaus