Slashdot Mirror


New Attack Tool Exploits SSL Renegotiation Bug

Trailrunner7 writes "A group of researchers has released a tool that they say implements a denial-of-service attack against SSL servers by triggering a huge number of SSL renegotiations, eventually consuming all of the server's resources and making it unavailable. The tool exploits a widely known issue with the way that SSL connections work. The attack tool, released by a group called The Hacker's Choice, is meant to exploit the fact that it takes a lot of server resources to handle SSL handshakes at the beginning of a session, and that if a client or series of clients sends enough session requests to a given server, the server will at some point fail. The condition can be worsened when SSL renegotiation is enabled on a server. SSL renegotiation is used in a number of scenarios, but most commonly when there is a need for a client-side certificate. The authors of the tool say that the attack will work on servers without SSL renegotiation enabled, but with some modifications."

3 of 47 comments (clear)

  1. NON ISSUE by Anonymous Coward · · Score: 5, Informative

    This is like the 3rd or 4th SSL renegotation bug. The last one had only one fix: disable SSL renegotiation altogether. Firefox helped speed it along, but marking ssl servers that allowed renegotiation as insecure. And openssl released an updated version to drop support for it.

    So pretty much every SSL server has renegotiation disabled.

    IIRC it was this bug: CVE-2009-3555

  2. Apache Server Settings by triemer · · Score: 4, Informative

    #1 - this has been a topic of conversation for a while #2 - per documentation at apache (Yes, I dare say a majority of web servers are running apache) There is a flag that can turn renegotiation on/off http://httpd.apache.org/docs/2.0/mod/mod_ssl.html Available in httpd 2.0.64 and later, if using OpenSSL 0.9.8m or later The default setting is: SSLInsecureRenegotiation off #3 - which leads to the conclusion that this is overhyped.

  3. iptables by ls671 · · Score: 3, Informative

    INTIF2=vmnet1
    PORTFWIP2=192.168.4.38

    $IPTABLES -A rule_j14 -m limit --limit 120/minute --limit-burst 50 -j ACCEPT
    $IPTABLES -A rule_j14 -m limit --limit 1/minute -j LOG --log-prefix "wharf"
    $IPTABLES -A rule_j14 -j DROP

    let i=0
    while [ $i -lt $EXTIF_LIST_SIZE ]
    do
    for redirport in 25 587 995 21 113 22 563 119
    do

    $IPTABLES -A INPUT -i ${EXTIF_LIST[i]} -p tcp --dport ${redirport} \
    -m state --state NEW -m limit --limit 1/minute \
    -j LOG --log-prefix "wharf wharf"

    $IPTABLES -A INPUT -i ${EXTIF_LIST[i]} -p tcp --dport ${redirport} \
    -m state --state NEW -j DROP
    $IPTABLES -A FORWARD -i ${EXTIF_LIST[i]} -o $INTIF2 -d ${MAIL_FW_IP[i]} -p tcp \
    --dport $redirport -m state --state NEW -j rule_j14

    $IPTABLES -A FORWARD -i ${EXTIF_LIST[i]} -o $INTIF2 -d ${MAIL_FW_IP[i]} -p tcp \
    --dport $redirport -m state --state ESTABLISHED,RELATED -j ACCEPT

    $IPTABLES -A PREROUTING -t nat -p tcp -d ${EXTIP_LIST[i]} --dport $redirport \
    -m state --state NEW -m hashlimit --hashlimit 60/hour --hashlimit-burst 15 \
    --hashlimit-htable-expire 3600000 --hashlimit-mode srcip,dstport \
    --hashlimit-name j14-${redirport} \
    -j DNAT --to ${MAIL_FW_IP[i]}:$redirport

    done
    let i=$i+1
    done

    --
    Everything I write is lies, read between the lines.