Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 1160 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IE7 and TLS, timeout connecting to HTTPS, and IPS

marlier
I've spent the last few days debugging an issue with IE7 not being able to access HTTPS pages on my site; Firefox worked fine, as did older versions of IE.  We eventually discovered that IE7 would work as well if the option "Use TLS 1.0" was disabled in the Internet Options "Advanced" pane.

Walking the connection using tcpdump, I finally traced it to the firewall, and after a bunch of digging discovered that it was IPS rule 8428 (search for 'sid="8428"' in the IPS log).  

I'm not sure of exactly what the deal is, but it would seem that IE7 is sending packets that appear to be buffer overflow attempts from the perspective of the IPS.  

Disabling the rule via Network Security > Intrusion Protection > Advanced got everything back up and running.


This thread was automatically locked due to age.
  • 0 in reply to BarryG
    Yep, I've had to disable rule 8428 on just about every Astaro at my customer's sites...  that rule probably just needs to be removed from the set altogether.
  • 0 in reply to BrucekConvergent
    So, I'm not sure what changed about sid 8428 in the latest IDS up2date package, but something did.  

    We got a couple of hits a day on it, at most...until an up2date update on Friday morning, when suddenly users who were running IE7 with TLS 1.0 enabled couldn't get to secure pages any longer, because their post-handshake packets would trigger the rule.  We went from 3 or 4 hits a day to thousands and thousands.

    Damnably difficult to track down, too, on a complex network with lots of potential suspects.

    I'm not sure what the rule definition was prior to 10:18:03AM Eastern on Friday, but the current one is this:
    drop tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"D WEB-MISC SSLv2 openssl get shared ciphers overflow attempt"; flow:to_server,established; flowbits:isnotset,sslv2.server_hello.request; flowbits:isnotset,sslv3.client_hello.request; flowbits:isnotset,tlsv1.client_hello.request; content:"|01 00 02|"; depth:3; offset:2; byte_test:2, >, 256, 0, relative;  classtype:attempted-admin; sid:2118426[;)]

    If anyone feels like trying to track down why that rule is being triggered by a legit packet, I've got tcpdump captures of the whole transaction, including the packet that Snort dropped improperly.  I can't do much with them, but maybe someone else can...
  • 0 in reply to marlier
    We were just struggling with the same issue.  Your thread was a life saver.

    Thanks!