Comments

JJJ • March 7, 2013 9:04 AM

I’ve been using Convergence for a while, but with only two notaries, I simply have to turn it off for a lot of sites (securitywise, this feels similar to accepting self-signed signatures…). Fortunately, I still haven’t had to turn it off when banking 🙂

But until notaries come along, I can understand why browser vendors are loath to include Convergence (chicken and egg there, I guess).

OTOH, one thing they could do is at least give an easy-to-dismiss warning when the notary-score is low.

Regarding incentives for being a notary, I would think most governments would have some incentive for increasing net security, as well as major banks (they definitely have incentive not to let people get scammed, since they might have to pay out some times) and, well, major sites that have something to lose from people getting their accounts phished.

Scott • March 7, 2013 3:54 PM

Here is a link to Moxie Marlinspike’s keynote on the broken CA model and Convergence from the OWASP AppSec 2011 conference in Minneapolis:

http://vimeo.com/32912604

It is a crystal clear and entertaining explanation of our current predicament. One of my all time favorite presentations.

Clive Robinson • March 7, 2013 10:17 PM

For long time readers there is nothing realy new in these articles as we’ve discussed it several years if not mäaaaaaaaaaaaaaaaaaaaaaaaaaaaago.

Way back I argued that Apps (especialy browsers) needed the same if not more security engineering than OS’s. I pointed out how a browser using shared resources such as memory etc could be used to short circuit OS security seperation. This was long befor Google Anounced or even hinted at chrome. But as some University students know back in the mid 90’s I was telling them to be carefull of “state information” in developing browser applications and how it was a security threat. And like many others I tell people to not just run seperate browsers for critical web apps I tell them to run them as seperate users or as I do for some as entirely seperate VM’s with heavily modified OS files which is almost but not quite like running from a custom CD.

I would encorage more technicaly savey users to consider using proper VM’s with just one app in them and specialy tailored OS and network files to match just the app along with locked down app files as this can stop quite a few nasties but it takes time and effort for the extra security.

As Bruce once pointed out about tents with vault doors you sometimes have to stand back to see the bigger picture,

Currently our OS security is moderate and can be considerably harded in many well documented ways, which is usefull in improving security. BUT various applications are the tents we hang of the back of the OS vault door browsers being the current main offenders. Because the apps are general purpose in nature we weaken our vault door to the level that alows all commers to walk in do their business and walk out again without let or hinderance.

As a general rule banks don’t let more than one customer into the security deposit box vault at any one time and they are accompanied by a bank employee to get the box and then to a secure private room to open the box in private.

We should adopt a similar position to banks with regards apps and VM’s amongst other technologies (think thin client techniques) to do this even as home users.

Kansas • March 8, 2013 9:10 AM

Monitor mode on phones coupled with reaver, aircrack, ssl proxies, systems not properly checking ssl certs, apps like dsploit, interceptor-ng, even the os backtrack all being easy to install…

And the new special security headers being easy to reverse if you are mitm.

While wifi usage increases and increases, yet the old problems largely remain unfixed.

Add to that spear phishing getting tamped down on.

That is another storm brewing which is related.

Nick P • March 9, 2013 10:55 AM

@ Natanael L

Glad you noticed it. I’ve posted it and other formal verification stuff here before. Personally, I think that strategy is a nice addition to browser security, but not a way to secure them. Most attacks on browsers try to subvert code execution, trick users into running things with their privileges, etc. These things just do an end run around the high level claims made by formal methods.

Now, if I were to apply formal methods, here’s what I’d do. I’d design a high performance virtual machine close to the bare metal. I’d ensure it had safe memory management, concurrency and foreign function interfaces. I’d also make it easy to contain with OS security primitives. I’d formally specify it, the interfaces, the error states, integrity, concurrency, etc. I’d prove correspondence between spec, security claims and implementation. Preferably, I’d extract an implementation or do a typesafe implementation.

Then, I’d just build the browser in a typesafe language, compile it, and run it in the VM. That would protect the browser with quite a bit of assurance. We already have pieces of this scheme. Just have to put it together in a way that addresses things like HTML5 or Flash.

If you like Quark or Chrome, you should also look up these papers:

The OP Web Browser
– inspired Chrome, I think. I coinvented a design like this, although mine used a microkernel & plugins weren’t formally verified.

Native Client paper (chrome architecture)

DARPAbrowser (capability security)

JINJA -> formally specified (verified?) java-like language, vm and compiler.

Dis and Lua virtual machines are good references for what I mean by close to metal & high performance.

Oh yeah, once implementation integrity is achieved, we can use an approach like Quark for browser security. 😉 The remaining problems, which are actually more important, are design choices in protocols and browser functionality that hurt security, like HTML5.

Clive Robinson • March 11, 2013 8:30 AM

@ AlanS,

Qubes OS?

I’ve not looked into it in sufficient depth to comment on that aspect of it.

But it has a problem…

It used to be known as the “IBM excuse” or the “Big Blue stratagem” and was once summed up as “Nobody ever got fired for buying IBM” (with the unsaid sub text of “even though they should have been” 😉

MS is “King” and *nix is “Queen” when it comes to operating systems and you have all the little princes and princesses in the applications world.

Thus even though some combination of MS&Adobe product even when running in a VM is less secure than some other arangment, guess which is going to get chosen for a whole host of reasons.

My suggestion is a workable halfway house, that can be done with the minimum of pain for users and the IT Dept’s systems architects and admins etc.

It might not be nice, it might not be pretty, and I’m fairly certain there are more secure ways to do it, but I have to live in the (supposed) real world which is ugly and vicious…

The reality is security is many layered and a proper solution needs to start at the real physical layer of the front door, and work upwards through the wiring.

Anyway like Nick P, QubeOS is on my todo list, but it’s in the “major project” catagory not the “that’s interesting” catagory so needs to be planed in not gap filled.

AlanS • March 11, 2013 9:32 AM

@Clive

Well, that’s always the problem isn’t it? There’s always a trade-off between security and convenience or something. If we’re going to live in the real world, how many people are really going to run their browser in a VM on Windows, never mind run something like QubesOS? I suspect not many. For most people even a minimal-pain trade-off is too great.

qmc • March 11, 2013 8:37 PM

The rfc1918 “problem” is a wealth of poorly designed embedded webservers which don’t require any sort of form token to make changes, at one of about 6-8 well-known locations..

Why are we patching this in the browser?

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.