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?
regards klaus