3 Feb
2006
3 Feb
'06
6:02 p.m.
Andrei Pelinescu-Onciul wrote:
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.
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
On Feb 03, 2006 at 15:48, Jan Janak
<jan(a)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. 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.