Food for thought: safe browsing and blocking scripts

The Building Your Own Privacy Package thread contains quite a bit of info on Proxomitron, its filters and the files it will need. This was posted before they released the hex edits for making it compatible with the current OpenSSL libraries.

 

If you're willing to wait, there will be a patch for Proxomitron released that will do the editing for you. See the last few posts of this thread.

 

Haven't used ProxBlox with Proxomitron before. I would like to remove NoScript and keep Request Policy.
I had to create another sandbox to run Proxomitron because of restrictions I had in place. Still have to figure
out how to use my defaultbox without opening to many holes in Sandboxie. Adding more filters to Proxomitron
is also what I'm looking into.

 

You might consider just disabling NoScript for now instead of removing it. This way, if Proxomitron isn't to your liking, you don't lose the NoScript permissions and settings you already have. You could also switch between NoScript and Proxomitron by changing the browser proxy settings.

I don't know if there's much to gain by sandboxing Proxomitron. Compared to a browser, Proxomitron needs very few permissions and little access to system components. An attacker wouldn't gain much by exploiting it, especially with such a small user base. Myself, I'd run it outside of the sandbox with as limited permissions as possible. The ProxBlox configuration saves the permission settings in a couple of text files in the lists folder, which would be lost every time you empty the sandbox. You might consider using a batch file that copies the configuration file and lists from the sandbox and writes them to the Proxomitron directory. If the batch file is executed from outside the sandbox, you shouldn't need to set any special permissions. On the 3X versions of SandBoxie, you could call an external erasing program to overwrite the sandbox. It might be possible to call the batch file from there, have it recover those files, then wipe the sandbox.

 

NoScript is set up so I don't lose permissions I've already set even if I remove it. There also is way you can lock permissions especially if one decides to do updates to browser and extensions.

There may be a misunderstanding . Although you can install certain programs inside Sandboxie I did my testing
with Proxomitron by running the whole program outside of the sandbox. Browser is set as DefaultBox in
Sandboxie, but with many restriction applied.
I had to create another sandbox with less restrictions in order to get Proxomitron to work.
The DefaultBox is setup with CCleaner to overwrite when deleting the sandbox. A message pops up to notify
when this action takes place. Of course each sandbox can be set differently.

 

I took this to mean that you created a separate sandbox for Proxomitron. If Proxomitron is installed and running outside of the sandbox, I'm at a loss as to why the sandbox would interfere with it or affect its ability to save settings.

 

Having to resolve connections using Proxomitron which is set to startup with browser.
There is setting(s) in Sandboxie causing Internet connection to fail as screenshot indicates.
Trying to isolate which one. Browser is set http and https localhost & port 8080 for Proxomitron.
Connection works without sandboxing the browser so I know it has to do with Sandboxie setting(s).

 

I'm still not clear on a couple of points.
1, Are you sandboxing Proxomitron?
2, How exactly are you starting it with the browser?

 

Question 1. No, just sandboxing the browser.
Question 2. In Proxomitron setting startup tab I select path of browser executable. When I click on
Proxomitron.exe it starts the browser.

 

I'm assuming that the browser is forced to start sandboxed. Apparently sandboxie has a restriction on localhost/loopback connections to non-sandboxed applications. I'm not familiar with the 4X versions and don't know how to configure it to make that allowance. The 3X versions don't seem to have that restriction.

 

Try starting Proxomitron in the sandbox and see if that eliminates the problem. I'd have to set up another virtual XP to experiment with the 4X versions of SandBoxie. ATM, I'm low on disk space.

 

Browser is forced to start sandboxed. Even if I'm able to connect I did test to see if Proxomitron filter to disable JavaScript would work, but no go.
Saved the setting and Sandboxie is also given full access to Proxomitron folder. Will continue to work this out.
Last time (many years ago) using Proxomitron I wasn't IIRC using Sandboxie so now I have to make changes
to hopefully make it work.

 

Time to sign off. Will do some more testing probably tomorrow. Thanks for the help.

 

I think that is cuz most criminals are driven by money. If you want to get money by XSS, you have to find vulnerable banking or shopping site, but usually those sites are better implemented (BTW, actually XSS is easy to prevent. Proper input check and escape/sanitizing should prevent most XSS). If a site is vulnerable but you can't make money from attacking them, why you attack with risk of arrest? If this is RCE, you can still make money but if XSS it's not.

 

Didn't read all posts there (sorry, too long) but it's good they adopt latest OpenSSL and OCSP stapling. Still I doubt it covers all concerns about TLS security.

I admit https is currently far from ideal, but my way of thinking is as it is imperfect, we have to enhance it as much as possible. W/out CA, such transparent and easy encryption is very hard, as you see in S/MIME for example. But surely CA is Achiles' heel of https, but I think, so for this reason we have to strengthen it, not weaken it by less reliable programs. OCSP enforcing is one way (I don't think Proxomitron support it, correct me if I'm wrong), and ofc you should disable/remove any cert you don't trust even a bit. And DANE is quite promissing I think, tho currently not much useful thanks to law adoption of DNSSEC, and need addon. There're many more hardnings in TLS as I mentioned in other thread, and using MITM proxy means at least you loose some of them, but more importantly you can't directly see original cert (and some useful info) with your eyes.

Also note, from all the evidence we currently have, even NSA couldn't directly penetrate TLS itself. So what they did were penetrate service provider, install malware or backdoor, or side-channel attack. Or they might stole or extorted server key, by intrusion, extortion, or bugs like Heartbleed. They are not the matter of TLS itself, other secure communication also suffer such attacks, as there's no bullet proof secure communication in this universe (Tor itself was good enough, but bug in TBB/Fx allowed FBI to gather IPs, you know). Or FREAK might be used in certain situaton, but it actually reinforce my claim that you have to control your TLS (disable any weak cipher!). All other TLS attacks are not practically useful. Well, also do not conduct any important communication if it doesn't support PFS, that is actually viable now.

So if I use Proxomitron again, I will use it only for plain http combined with addons for TLS. Actually that is not the only reason I stopped using proxomitron, as it affects all http traffic on PC sometimes it causes trouble in other application if it doesn't have individual proxy setting, for example. But rather than such double standard I settled down pure addon apporach.
One fortunate thing is, we share the idea that security is all up to your threat model and security policies. I know not many ppl here share this fundamental idea. So we at least can admit you and I have different models and priority.

 

Hmmm...if that is the case, maybe has sth to do with known IE protected mode bypass which leverages localhost?
Since SBIE 4.x mainly uses OS based security including integrity level...

 

I don't understand many of the details of HTTPS, especially some of the alphabet soup features. I don't know how much of it is being updated in Proxomitron. Judging from what I see in the thread, they have implemented:
TLS1.2.
Forward secrecy is listed for many of the ciphers in the listing.
Wildcard certificates checking.
SNI extension.
SubjectAltName extension.

I don't share your trust in HTTPS. IMO, the "improvements" are just building on a broken foundation. The primary reason I choose to filter HTTPS is that sites are forcing its use. I don't trust it for anything that I consider sensitive, financial, or private.

Regarding the NSA, breaking encryption is one of the primary purposes for their Utah data center. They didn't build that monster for breaking TrueCrypt or PGP. I'm convinced that they can and are reading HTTPS in near real time. It doesn't matter if they've actually broken TLS or if they've stolen, coerced, or used NSLs to obtain the certificates. They've got them. IMO, this push to HTTPS is little more than a "feel good" response that accomplishes nothing.

This was one of the incentives behind the Building Your Own Privacy Package thread. Proxomitron would have defeated that attack. So would a firewall with localhost traffic control and proper rules. IMO, the browsers themselves have to be regarded as hostile to privacy and secrecy by design.

That's another reason that I emphasize localhost traffic control. Most browsers request localhost connections but will still function without them. As for IE, that's one of many reasons that I completely remove it. It's a gaping hole, especially on the older systems.

 

Well after doing some more testing with Proxomitron I was unsuccessful to make it work. That's okay as I can
filter through extensions and the APC. Could go back to using a Hosts file which can be updated.

 

Did you try running Proxomitron in the same sandbox as the browser?

 

That was where I originally started, but that sandbox is the most restricted and used most often. I tried running
a different sandbox setup with more of default settings and was able to connect out, but couldn't get filtering to
work. If I try to disable JavaScript in Proxomitron it doesn't show as being changed in Pale Moon.

 

My sentiments exactly, Yuki. Yes, XSS is easy to prevent, and some years ago (I lose track of time!) I contacted the Security of the web sites where I regularly do financial transactions, asking if they regularly tested their sites for this type of vulnerability.

Three responded that they did.

----
rich

 

Palemoon won't give you a direct indication that javascript is disabled by Proxomitron. Many of Proxomitrons filters use javascript. It needs to remain enabled in the browser. If the page you're testing with is HTTPS, is Proxomitron configured to filter it? Are the SSL libraries it needs present in its folder? The easy way to see if Proxmitron is filtering traffic is with its log window. Open it, then load/reload the page. A quick way is to have the Proxomitron interface visible while the page is loading and look where it shows the number of active connections. If the quantity fluctuates while the page loads, it should be filtering as long as the header and web page filters are enabled. Many of the filtersets, including the default filters don't add any obvious indicators to what the browser displays. The Sidki filterset and ProxBlox are exceptions. See this thread for info regarding them.

 

You're braver than I am. I won't use the internet for finances or purchases. How well you've secured your end doesn't matter if the business you're dealing with hasn't taken equal precautions. The steady stream of hacks and breaches shows that they're not.

 

@noone_particular

Okay back to testing. You mentioned importing the proxcert.pem file to the browser certificate manager. Do I need a password?
Also here is screenshot when logging into seach engine. How do I update these certs? SSL filtering is
checked in Proxomitron and downloaded all zip files and extracted everything including .dll files to Proxomitron folder. Still having issues with Sandboxie settings so had to create another sandbox.

 

Not really. Cash only/no bank has less security and is insanely inconvenient (lose it, it's gone). Using online banking/online purchase mostly holds zero liability and your online account exists regardless of you actually using it. So you've reduced exposure nil and upped inconvenience greatly by avoiding online portals. Now worse, most credit card hacks are done at POS, so using amazon with a virtual credit number is a lot safer than hitting up a brick and mortar store.

Use a dedicated banking and VCC generator...you're safe as can be and hold little liability. Ultimate convenience and savings.

By using dedicated computers for secure details allows you to run security like script blockers and firewalls in a totally locked down whitelist fashion.