#573 TLS: "failed to accept: rejected by client"

core (110)


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.


PS: Vlad, thx for fixing bug #3570495. It does not crash anymore.


  • Dragos Oancea

    Dragos Oancea - 2012-11-06


    If I run this against my opensips-1.8.2-tls it will stop relay-ing INIVITEs after less than 1 minute:


    while [[ $count -le 1000 ]]
    echo "$count"
    echo "giberish" | nc X.X.X.X 5061
    sleep 1
    (( count++ ))


    I have:

    It happens under VMWare with only two registered TLS clients on a test box.


  • Dragos Oancea

    Dragos Oancea - 2012-11-06


    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.


  • Dragos Oancea

    Dragos Oancea - 2012-11-08

    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.

  • saghul

    saghul - 2012-11-08

    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.

  • Christian Lahme

    Christian Lahme - 2013-04-26

    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.

  • Bogdan-Andrei Iancu

    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks