The Un-Official Proxomitron Forum

Full Version: SSL logins not working
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi,

for some time, I've been working on a set of filters that implement an alternative to Half-SSL by using the URL command px/http://https.. with a Firefox extension called Redirector (which, you probably guessed it, simply redirects any URL starting with https:// to px/http://https..). The advantage of this approach is that there are no browser warnings like "This Connection is Untrusted" - apparently, there are no browser warnings at all. :-)

Everything is working fine - even Google search - but two things: startpage.com and SSL login pages do not work. More precisely, there's no error message but instead of showing the member page, the browser displays the search / login page again. I've spent hours watching Proxomitron's log window and finally noticed that all the green requests are GET requests. Looking at the page source code, for example at secure.diigo.com/sign-in, I can clearly see that login is a form that should be POSTed. But there's no POST in the log window.

None of my filters actually does a $RDIR or $JUMP, only simple substitutions of px/http://https.. with https:, both for the URL and the Referer.

What might I be overlooking?

Regards
i can't test in Firefox (hate it with a passion), but i have to wonder if it's the Redirector extension that may be possibly converting POST to GET - is there any way to test that as a theory?
(Oct. 26, 2012 06:00 PM)duebel13 Wrote: [ -> ]The advantage of this approach is that there are no browser warnings like "This Connection is Untrusted" - apparently, there are no browser warnings at all. :-)

undocumented (?) and not mentioned very often due to the Proxo community prefers NOT to let "newbies" filter too much SSL (i have personally **NEVER** had any issue and i filter a *TON* of SSL), but another method to remove browser warnings is to delete/rename Proxo's "certs.pem" file - i have to do that for ONE out of the *TON* (that one being Menards's Big Card)...
https://addons.mozilla.org/en-US/firefox/addon/redirector/ ,

So you have the extension change the url in the address bar from https:// to px/http://https..? The native Proxomitron URL command would look like "http://px.https..".

(Oct. 26, 2012 06:00 PM)duebel13 Wrote: [ -> ]What might I be overlooking?

I think the extension only alters the url in the address bar.

The browser may not send a cookie because it thinks the cookie belongs to "px", http://prxbx.com/forums/showthread.php?t...75#pid3775 .

You may need to strip the 'secure' attribute from the set-cookie header, http://en.wikipedia.org/wiki/HTTP_cookie...d_HttpOnly .

(Oct. 26, 2012 06:00 PM)duebel13 Wrote: [ -> ]None of my filters actually does a $RDIR or $JUMP, only simple substitutions of px/http://https.. with https:, both for the URL and the Referer.

What does the "URL" filter look like?
(Oct. 27, 2012 12:54 AM)ProxRocks Wrote: [ -> ]the Proxo community prefers NOT to let "newbies" filter too much SSL

I'd prefer if you didn't call me a newbie Not talking - actually I started using Proxomitron back in 2004 (link to my profile at the German Prox forums at buerschgens.de). For sure I'm not an expert but should easily qualify for the status of an advanced user, at least. Cheers.
(Oct. 27, 2012 03:03 AM)JJoe Wrote: [ -> ]https://addons.mozilla.org/en-US/firefox/addon/redirector/ ,

So you have the extension change the url in the address bar from https:// to px/http://https..? The native Proxomitron URL command would look like "http://px.https..".

Yep. This is a screeshot I've taken using the default prefix prox.serv/:

[Image: httpsredirect2012080608.jpg]

I'm actually using the prefix prx/ now.

Quote:I think the extension only alters the url in the address bar.

True. Under the covers, more work is needed in Proxomitron.

Quote:The browser may not send a cookie because it thinks the cookie belongs to "px", http://prxbx.com/forums/showthread.php?t...75#pid3775 .

Yes, indeed. This isn't obvious from the log window output but using another Firefox extension called Cookie Culler I could verify this.

[Image: 20121027071109log.jpg]

Quote:You may need to strip the 'secure' attribute from the set-cookie header, http://en.wikipedia.org/wiki/HTTP_cookie...d_HttpOnly .

Thanks. Actually I've "borrowed" that filter code from sidki's Half-SSL filter set. Now I see it's not sufficient to change just the URL and the Referer, I have to modify the cookies, too.

Quote:What does the "URL" filter look like?

Probably I do not have expressed myself correctly. Of course, it's Proxomitron that switches the protocol - I just have to remove the prefix and URL command from the URL.

In sidki's filter set, one has to explicitly enable Half-SSL by activating a header filter. One major difference between sidki's and my approach is that you don't have to (better: must not) redirect the HTTPS protocol to Proxomitron - just let the browser send HTTPS directly to the Internet. This means, in Proxomitron every HTTPS request seen must stem from an URL command. The first filter just acknowledges that by setting some flags:

Code:
In = TRUE
Out = FALSE
Key = ".URL: (Out) 01 SSL Flag setzen [dbl]"
URL = "$URL(https://)$SET(ScfModify=$TST(ScfModify=(^*hdr.halfssl)(\1))\1,hdr.halfssl)$SET(uSSLCmd=https://)$SET(uSSLCmdPrefix=\xhttp://https..)$LOG(VHMatch $DTM(c): URL: (Out) SSL Flag setzen <URL: \u>)"

I have not translated the German words, it should be easy to understand. This is the filter that cleans the URL:

Code:
In = FALSE
Out = TRUE
Key = "Referer: (Out) 04 Prox: Präfix und URL-Kommandos entfernen [dbl] v1.1"
Match = "($SET(1=http://)|\1)($TST(uPrefix)(\1https..$SET(1=https://))+([a-z]+{1,9}..)+)\2(\3)$SET(HdrReferer=\1\3)"
Replace = "\1\3$LOG(VHMatch $DTM(c): Referer: Präfix und URL-Kommando(s) entfernt: \2)"

You may have noticed that I'm using the URL Parser from sidki's filter set, too. The variable uPrefix equals \x and is set in the very first header filter from Michael Buerschgen's filter set.

Now I'm going to check the cookie issue. Thanks for your help so far, I really appreciate it.
(Oct. 27, 2012 05:02 AM)duebel13 Wrote: [ -> ]I'd prefer if you didn't call me a newbie Not talking

i wasn't, actually...
i advocate that EVERYBODY, new and old, should filter EVERYTHING, ssl or non-ssl...
but i am in the minority in that opinion, i get "flogged" every once in a while for "suggesting" that 'newbies' (not you) FILTER their ssl...

the irony, NOT ONCE has any "flogger" been able to document a case where filtering ssl resulted in any ounce of unintended consequence...


ps - your post count would indicate 'newbie', but the nature of your question clearly indicates otherwise Smile!
Thank you for the clarification, ProxRocks.
(Oct. 27, 2012 03:03 AM)JJoe Wrote: [ -> ]The browser may not send a cookie because it thinks the cookie belongs to "px", http://prxbx.com/forums/showthread.php?t...75#pid3775 .

Hail Hail to JJoe - that saved my day :-)

Just after I added the filter "Set-Cookie: Fix cookies when using URL commands (in)" to my configuration, the pages mentioned above are now working as they should:
- startpage.com search works both directly from the page and through the search bar extension
- I can login to both diigo.com and gmx.net

There are two other issues remaining but those are not related to the initial topic and I'll create new threads for them. Thanks again, JJoe.
(Oct. 27, 2012 09:15 AM)duebel13 Wrote: [ -> ]Just after I added the filter "Set-Cookie: Fix cookies when using URL commands (in)" to my configuration, the pages mentioned above are now working as they should:

Don't overlook sidki's warning.

sidki Wrote:Say you log in to that.site.com and your personal data are stored in a cookie, which is restricted to that very host - sometimes for a reason. Now, if you go to this.that.site.com with that filter - as posted - activated, the data cookie would be sent to this host as well.

Filtering https may expose data that should be protected.

ProxRocks Wrote:i advocate that EVERYBODY, new and old, should filter EVERYTHING, ssl or non-ssl...
but i am in the minority in that opinion, i get "flogged" every once in a while for "suggesting" that 'newbies' (not you) FILTER their ssl...

Not to be mean but we win. Wink
Old or new, we want people to educate themselves first. I don't think I've "flogged" anybody but...

ProxRocks Wrote:NOT ONCE has any "flogger" been able to document a case where filtering ssl resulted in any ounce of unintended consequence...

I don't remember anyone telling me that they got hurt. Most people wouldn't be able to figure out why they got burnt. Https may not have been involved in the troubles that I am aware of. I saw my mistake before it bit me, so I guess that experience doesn't count... Wink

For all:

Filtering https may modify data that should not be changed. Half-SSL adds the potential liability of the unencrypted data stream from the Proxomitron to the browser, cookie and routing issues. The data could be account number, password, purchase quantity, etc. Severity of the problem depends on the user and use but, I think, it does exist.

Please be careful.
re: filtering ssl -

not disagreeing, for the most part...
it should however be noted that there is a growing trend for "secure sites" to NOT EVEN USE SSL...
the LOGIN "passes thru" an httpS site, but then EVERYTHING beyond the "login" is http, without the S...

the whole SSL "crap" is fundamentally FLAWED and EASILY exploited (ANYBODY can "buy" an SSL 'certificate' and CLAIM to be WHOEVER THEY WANT TO BE!)...

Google, Yahoo, Skype, Microsoft, and Mozilla (and Twitter?) are "hit" with FAKE ssl certificates "constantly"... the system is FLAWED...

Flawed so greatly that Google's CHROME is, last i heard, ABANDONING the practice of 'revocation'...

Citibank and Bank of America are in the news every six months for "hacked data" - 'secure' my arse, the S in httpS stands for *hit if you want my "opinion" Smile!

Apple has had several "man-in-the-middle" iOS ssl certificate breaches...


the system is FLAWED...
but YES, i grant that "a system" is better than "no system"...
purely as a commentary side note...

i've been an Intuit Quicken user since '02 '99 (maybe even longer, i know '02 '99 'cause the install CD is still in my stack of CDs)...

(ie, pretty much inline with my years of running Proxo... i think i've ran Quicken LONGER than Proxo, not sure...)

the first several years, i didn't update "every" year, but every two or three or so...

with annual tax code changes, i've updated every year for the last four...


here's the "observation" - only *ONE* of my Quicken versions pulled in a .crl "certificate" every third or fourth time i opened Quicken (Proxo shows the download)...

two of them, actually -
csc3-2010-crl.verisign.com/CSC3-2010.crl
crl.verisign.com/pca3-g5.crl

that *ONE* version being LAST YEAR'S version, Quicken 2012...

i just updated, about two weeks ago or so, to Quicken 2013 - and it has NOT downloaded ANY .crl's yet...

so i have to wonder if Intuit is "abondoning" 'revocation' due to the FLAWED SYSTEM...


just an "observation" Smile!
not to beat a dead horse, it's just a topic that "gets under my skin", lol...
I think you should look past the "FLAWED SYSTEM". Even if implimentation were perfect, filtering SSL would still require caution.

Quote:Filtering https may modify data that should not be changed. Half-SSL adds the potential liability of the unencrypted data stream from the Proxomitron to the browser, cookie and routing issues. The data could be account number, password, purchase quantity, etc. Severity of the problem depends on the user and use but, I think, it does exist.

Please be careful.

wouldn't change.
the key word in there rests between the two commas, I THINK...
the theoretical possibility does exist, i'm not denying, though i have YET to see it "in the wild" for the decade and a half or so that i've been running Proxo and filtering SSL the whole time

don't give me "theoreticals", show me something IN THE WILD Smile!

we simply agree to disagree on this one...
(Oct. 31, 2012 08:08 PM)ProxRocks Wrote: [ -> ]show me something IN THE WILD Smile!

How could there be something "IN THE WILD"...

There are opportunistic criminally minded people who sniff or inspect data streams. While these people are not just after Proxomitron users, mistakes made while using the Proxomitron can make it easier for them.

Also, I think Wink , you are only considering the 'somebody is out to get me' part of the problem. You can 'get' yourself.

We all know and have seen that filtering can have unintended consequences. Filtering important things allows you to hurt yourself. Typically, important things have been done via https. So it follows that, filtering https is more dangerous than filtering http.

My fingerprints are all over SSL filtering. Use at you own risk. Please be careful.



(Oct. 31, 2012 08:08 PM)ProxRocks Wrote: [ -> ]the key word in there rests between the two commas, I THINK...

I'm told that "I think" is one of my annoying habits. Wink The problem does exist.

Edit: spelling
Pages: 1 2
Reference URL's