1 Feb
2006
1 Feb
'06
1:52 p.m.
On Feb 01, 2006 at 14:43, Jan Janak <jan(a)iptel.org> wrote:
Cesc wrote:
No, he is right, this is a bug.
A normal TLSv1 server will accept only TLS hello messages (version =
3.1) and since sip is supposed to work only with TLS, this should be the
default (tls_method=TLS_USE_TLSv1).
The SSLv23 stuff will accept any type of hello. A client
with the SSLv23 method will send a hello v2 message, indicating in it
also tls and ssl 3.0 support (they will include tls specific ciphers
a.s.o). The client sending v2 hellos is not exactly standard behaviour
for TLS. It is a hack for backward compatibility, but a TLS only server
will not accept it.
One of the clients that used a SSLv23 equivalent was Windows Messenger
(it was doing this in 2003 when I wrote my ser tls code).
The tls method should be configurable to allow older/strange clients
support, but it should default to TLSv1 (btw: this is how you can reject
v2 clients without SSL_OP_NO_SSLv2).
On 2/1/06, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
Yes, I think this is correct. The protocol version should be set to
TLSv1 afterwards, you can test this with @tls.version: Hi!
I've tried the new TLS module:
1. It breaks compatibility with old TLS stack: Even when configured to
use TLSv1, it sends an SSLv2 compatible HELLO:
server2:~# ssldump
New TCP connection #1: 10.10.0.41(33107) <-> 10.10.0.42(5063)
1 1 0.0088 (0.0088) C>S SSLv2 compatible client hello
Version 3.1
I do not know if this is a problem with the new or the old stack.
Further I do not know what other TLS enabled SIP products use. Do they
accept SSL compatible HELLOs?
Klaus, i don't think this is a bug ... i think that the hello is
always v2 and then (with the server hello message) the handshake is
upgraded to v3 or tlsv1. This way, you can have an sslv2-only client
try connecting to any server, but the server will send back sslv3 or
tlsv1 server hello, thus disconnecting the client.
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. If you need special
verify on only for some clients, either make it per ip, or use another
tls port on which you have verify turned on.
Andrei