The Un-Official Proxomitron Forum

Full Version: Problem with Half-SSL...
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
i'm having problems with Half-SSL not working here - https://www.accountonline.com/cards/svc/Dashboard.do

i'm at wits-end trying to track down what's amiss...
there are four .js calls which i'm guessing the amiss is within -
1) https://www.accountonline.com/cards/svc/...and=dbug..
2) https://www.accountonline.com/svc/conten...and=dbug..
3) https://www.accountonline.com/cards/svc/...and=dbug..
4) https://www.accountonline.com/cards/svc/...and=dbug..

does anyone have any suggestions in assisting the track-down of why Half-SSL isn't working for the above site?
If you mean the empty page, i also get it with Proxomitron bypassed ("Full-SSL").
Maybe this document is intended to receive POST (vs. GET) requests.
how would i test POST vs. GET ?
Well, if you don't see the empty page, and if you pushed a button or similar, before getting to that page, it's probably a POST request.
So, you could post the link to the page with that button here.

Or you could select "View Posted data" in the log window. If you see something like:
Code:
Posting xxx bytes...
a=1
b=2

...you could append the data pairs as query string (defusing sensitive information), like:
https://www.accountonline.com/cards/svc/Dashboard.do?a=1&b=2

That often works, but not always.
ah yes, try this link - https://www.citibank.com/us/cards/index.jsp
or this one - https://www.citicards.com/cards/wv/home.do


yep, i do get "Posting xxx bytes"...
so that's a good thing, right?
it means my Half-SSL problems is not GET-related, right?



ps - to clarify more precisely, i "think" it logs in via Half-SSL, it just IMMEDIATELY logs right back out and gives a "your session has expired" tidbit... seems my only "fix" is to add a_cont_loc. to IncExc-U - but then i'm no longer using Half-SSL...
(Mar. 14, 2009 01:35 AM)ProxRocks Wrote: [ -> ]ah yes, try this link - https://www.citibank.com/us/cards/index.jsp
or this one - https://www.citicards.com/cards/wv/home.do

Both links work for me.


Quote:yep, i do get "Posting xxx bytes"...
so that's a good thing, right?
it means my Half-SSL problems is not GET-related, right?

I'd say it's neither good nor bad. I was just trying to get a link from you where i could reproduce the problem. Wink
But if you need to be logged in, it's not possible anyway...


Quote:ps - to clarify more precisely, i "think" it logs in via Half-SSL, it just IMMEDIATELY logs right back out and gives a "your session has expired" tidbit... seems my only "fix" is to add a_cont_loc. to IncExc-U - but then i'm no longer using Half-SSL...

In that case it could be the "secure" cookie field, which can't always be removed from cookie setting JS functions. Try activating the "Don't adjust JS Location" webfilter. If it works, the respective keyword is "i_loc_j:0".

Beyond that, i don't know either...
figures... in the middle of a "debug session", their site goes into shutdown-mode for "maintenance"... Banging Head Mad with Teeth Sad
hmmm... can't be .js-related after all... login functions even when disabling scripts...

all i can figure at this point is that it's something "server side"...
When logging in, the page is sending a lot of set-cookie headers with a "secure" field. But one header is special, it has all the supplemental fields duplicated:

Code:
Set-cookie: UAUTH=USERNAME:xxx..|SID:xxx; path=/; domain=.accountonline.com; SECURE; Path=/; Domain=.accountonline.com; Secure


The "Set-Cookie: 7 Strip "Secure" if Half-SSL" header filter was expecting just one "secure" field, thus left one in place. Consequently, the "UAUTH" cookie wasn't accepted by the browser.

Below test version loops through all existing "secure" instances.

Code:
[HTTP headers]
In = TRUE
Out = FALSE
Key = "Set-Cookie: 7 Strip "Secure" if Half-SSL     9.03.14 (cch!) [sd] (d.1) (In)"
URL = "$TST(keyword=*.i_ssl_h:[12].*)"
Match = "(\# ; secure(^$TST(uPort=*))(^(^ ;)& ?))+{1,*}\#&$LOG(wRESP $DTM(c) : Set-Cookie stripped: Secure)&($TST(volat=*.log:2*)$ADDLST(Log-Main,[$DTM(d T)]\tHDR_In Set-Cookie_Strip\t\Secure\t\u)|)"
Replace = "\@"

edit: 5a -> 7
edit2: "TEST" flag removed
Awesome!

Many Thanks, sidki...

i see that it's now at "position 5a", where the equivalent filter in the 2.13.09 release is at "position 7"... i've got the new filter in at "position 7" and works like a charm...


can't thank you enough...
that one's been bugging me off-and-on for months, lol...

thanks again...
Cool!
Oh right! I'll change "5a" to "7" in above post.
mmm the other day i was trying to write a general filter wich would look up for forbidden content in a cookie looking recursively in a block content list. I think your filter will help me a lot for doing that. Thanks Sidki!! :DDD
Hi Sidki, analizying your code i saw a ";" before the secure, i didn't test it but if i'm not wrong when secure is in first place it wouldn't match. Just to let you know, in other filters you used (\#(; )\0|)

edit 090323: or maybe secure will be never at first place?
Off-Topic :

Anyone else using Avira AntiVir getting a malware warning when opening this thread ?
malware warnings are becoming a bit of a "boy that cried wolf"...
Google has malware warnings on search links that seem more often than not to be just that, "wof! wolf!" and chuckle as everyone trips over each other as they seek shelter...


editing above links to remove half-ssl, does that fix the malware false-positive?
Pages: 1 2 3
Reference URL's