[OpenSIPS-Devel] [ opensips-Bugs-3581600 ] TLS: "failed to accept: rejected by client"
SourceForge.net
noreply at sourceforge.net
Fri Apr 26 11:16:12 CEST 2013
Bugs item #3581600, was opened at 2012-10-29 04:56
Message generated for change (Comment added) made by chris-secusmart
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.8.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dragos Oancea (dragosoancea)
Assigned to: Nobody/Anonymous (nobody)
Summary: TLS: "failed to accept: rejected by client"
Initial Comment:
Hi
There is a weird behaviour in opensips-tls. It happened to me a 4 or 5 times in the last 3 months.
Sometimes I get a lot of messages like this in the logs:
"ERROR:core:tls_accept: New TLS connection from ip:port failed to accept: rejected by client"
This usually means that some TLS client which is not under my control is hammering on the SSL port, never completing a full SSL/TLS handshake.
But whithin few minutes after these appear, nothing works on opensips anymore, you send an INVITE and it does not get relay-ed, nothing hapends , it's just stuck. Then I firewall the IP from where the connection requests come from, and everything starts to work fine again.
Regards,
Dragos
PS: Vlad, thx for fixing bug #3570495. It does not crash anymore.
----------------------------------------------------------------------
Comment By: Christian Lahme (chris-secusmart)
Date: 2013-04-26 02:16
Message:
Okay, lets get back to the Bug again. We have got a fix from Bogdan, which
stops the crashes. But now there is another behavior.
The client doesn't send a TCP FIN to release the connection. Therefor the
server awaits with his worker thread another handshake and doesn't close
the connection or freeing up the working thread.
That means in fact, that an attacker may send a few TCP SYN-Flood attacks
to the server, not finishing the connection, and the server will wait for
further action till TCP-Timeout. If your connecting clients are behind a
NAT-Firewall, you'll need idleing TCP/TLS connections with long TCP
timeouts.
The server will need to close this connection after a client rejected
message. And he will need to free his working thread.
----------------------------------------------------------------------
Comment By: saghul (saghul)
Date: 2012-11-08 06:15
Message:
Hi Dragos,
FWIW, we have also seen this when running the sip2sip.info service and had
to turn it off because even if it doesn't crash, if a single client sends
bogus data the proxy just stops working (on TLS) as you described.
----------------------------------------------------------------------
Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-08 05:53
Message:
anyone else experiencing this bad DoS ?
I only have TLS phones, and some of them are under development, so a single
TLS phone that goes crazy and cannot perform the SSL handshake for some
reason can put down the whole SIP proxy.
----------------------------------------------------------------------
Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 08:48
Message:
some info from /proc (not sure if it helps) :
http://pastebin.com/KULvTY8x
----------------------------------------------------------------------
Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 06:21
Message:
Hi
Some more info:
After opening 10 ssl connections and sending junk instead of an SSL
handshake, things start to go wrong.
A legitimate TLS client (already REGISTERed) would try to send an INVITE.
This is what opensips shows in the logs instead of just relay-ing the
INVITE :
Nov 6 15:05:10 [25062] DBG:core:send2child: to tcp child 0 0(25030),
0x7f39127846c0
Nov 6 15:05:10 [25030] DBG:core:handle_io: received n=8
con=0x7f39127846c0, fd=27
Nov 6 15:05:10 [25030] DBG:core:io_watch_add: io_watch_add(0x74a0a0, 27,
2, 0x7f39127846c0), fd_no=1
Nov 6 15:05:10 [25030] DBG:core:tls_update_fd: New fd is 27
Nov 6 15:05:10 [25030] ERROR:core:_tls_read: TLS connection to
80.187.x.x:39337 read failed
Nov 6 15:05:10 [25030] ERROR:core:_tls_read: TLS read error: 1
Nov 6 15:05:10 [25030] ERROR:core:tls_print_errstack: TLS errstack:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Nov 6 15:05:10 [25030] ERROR:core:tcp_read_req: failed to read
Nov 6 15:05:10 [25030] DBG:core:io_watch_del: io_watch_del (0x74a0a0, 27,
-1, 0x10) fd_no=2 called
Nov 6 15:05:10 [25030] DBG:core:release_tcpconn: releasing con
0x7f39127846c0, state -2, fd=27, id=1343
Nov 6 15:05:10 [25030] DBG:core:release_tcpconn: extra_data
0x7f39127f0010
Nov 6 15:05:10 [25062] DBG:core:handle_tcp_child: reader response=
7f39127846c0, -2 from 0
Nov 6 15:05:10 [25062] DBG:core:tcpconn_destroy: destroying connection
0x7f39127846c0, flags 0002
Nov 6 15:05:10 [25062] DBG:core:tls_close: closing TLS connection
Nov 6 15:05:10 [25062] DBG:core:tls_update_fd: New fd is 83
Nov 6 15:05:10 [25062] DBG:core:tls_shutdown: first phase of 2-way
handshake completed succesfuly
Nov 6 15:05:10 [25062] DBG:core:tls_tcpconn_clean: entered
Looks like the TCP/TLS connection gets closed. Why ? It's the same client
that completed the SSL handshake and it was registered just before this
"attack" . The problem is easily reproduce-able with the small bash script
in my previous comment.
Regards,
Dragos
----------------------------------------------------------------------
Comment By: Dragos Oancea (dragosoancea)
Date: 2012-11-06 05:36
Message:
Hi
If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs
after less than 1 minute:
-------
#!/bin/bash
count=1
while [[ $count -le 1000 ]]
do
echo "$count"
echo "giberish" | nc X.X.X.X 5061
sleep 1
(( count++ ))
done
-------
I have:
open_files_limit=81920
tcp_max_connections=40960
It happens under VMWare with only two registered TLS clients on a test box.
Regards,
Dragos
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3581600&group_id=232389
More information about the Devel
mailing list