Blocking insecure log-in page

Hey Joel,

 

 

If I understand your set up now, none of those would really work. If the traffic for both HTTPs and HTTP arrives at the same port 80 VS on the ASM, there is little way to tell them apart. Truly any trace of which protocol it arrived on will be absent by the time it arrives there, then.

 

 

I think you will have to engage the LTM in front to be able to distinguish between them, but understanding the set up better now, there are some more graceful solutions. The LTM could perform header insertion on the individual VIPs, i.e. the port 443 VIP could insert "X-HTTPS-PROTO: Huzzah!" and the port 80, "X-HTTP-PROTO: Wheee!". Then your ASM could use HTTP Classes to look for these and sort out the traffic as above.

 

 

It may be slightly more invasive, but you could also configure two VSs on your ASM and configure the LTMs to send to them differently on the ASM, so the traffic arrived at the ASM as it would were it getting it direct form the client.

 

 

The trouble is that with only the HTTP headers there is nothing to really denote whether HTTPS or HTTP was used in most cases. Try watching a few clicks around with Live HTTP Headers, HTTP Watch, or even Paros/Scarab/Burp sometime and try to spot anything in these that denotes whether the connection was sent HTTP or HTTPs. (Note that some of these might show the full address in the request string: GET http://abc.com, but this is not what is actually sent) Even taking a tcpdump on the ASM and trying to sort out the difference between the requests that *were* HTTP and HTTPS would help indicate the difficulty. =]

 

 

The header insertion on the LTM seems like the least invasive and cleanest solution I can think of now. I will ponder it over the weekend, however, to see if anything else leaps out at me. Cheers for now!

 

 

// Ben