NOV
22
2005

Web Browser Developers Work Together on Security

Core KDE developer George Staikos recently hosted a meeting of the security developers from the leading web browsers. The aim was to come up with future plans to combat the security risks posed by phishing, ageing encryption ciphers and inconsistent SSL Certificate practise. Read on for George's report of the plans that will become part of KDE 4's Konqueror and future versions of other web browsers.

In the past few years the Internet has seen a rapid growth in phishing attacks.
There have been many attempts to mitigate these types of attack, but they
rarely get at the root of them problem: fundamental flaws in Internet
architecture and browser technology. Throughout this year I had the fortunate
opportunity to participate in discussions with members of the Internet Explorer,
Mozilla/FireFox, and Opera development teams with the goal of understanding and
addressing some of these issues in a co-operative manner.

Our initial and primary focus is, and continues to be, addressing issues in PKI
as implemented in our web browsers. This involves finding a way to make the
information presented to the user more meaningful, easier to recognise, easier
to understand, and perhaps most importantly, finding a way to make a distinction
for high-impact sites (banks, payment services, auction sites, etc) while
retaining the accessibility of SSL and identity for smaller organisations.

In Toronto on Thursday November 17, on behalf of KDE and sponsored by my company Staikos Computing Services, I hosted a meeting of some of these developers. We
shared the work we had done in recent months and discussed our approaches and
strengths and weaknesses. It was a great experience, and the response seems to
be that we all left feeling confident in our direction moving forward.
There was strong support for the ideas proposed and I think we'll see many of
them released in production browsers in the near future. I think we were
pleasantly surprised to see elements of our own designs in each other's
software, and it goes to show how powerful our co-operation can be.

The first topic and the easiest to agree upon is the weakening state of current
crypto standards. With the availability of bot nets and massively distributed
computing, current encryption standards are showing their age. Prompted by
Opera, we are moving towards the removal of SSLv2 from our browsers. IE will
disable SSLv2 in version 7 and it has been completely removed in the KDE 4
source tree already.

KDE will furthermore look to remove 40 and 56 bit ciphers, and we will
continually work toward preferring and enforcing stronger ciphers as testing
shows that site compatibility is not adversely affected. In addition, we will
encourage CAs to move toward 2048-bit or stronger keys for all new roots.

These stronger cryptography rules help to protect users from malicious cracking
attempts. From a non-technical perspective, we will aim to promote, encourage,
and eventually enforce much stricter procedures for certificate signing
authorities. Presently all CAs are considered equal in the user agent
interface, irrespective of their credentials and practices. That is to say,
they all simply get a padlock display when their issued certificate is
validated. We believe that with a definition of a new "strongly verified"
certificate with a special OID to distinguish it, we can give users a more
prominent indicator of authentic high-profile sites, in contrast to the
phishing sites that are becoming so prevalent today. This would be implemented
with a significant and prominent user-interface indicator in addition to the
present padlock. No existing certificates would see changes in the browser.

To explain what this will look like, I need to take a step back and explain the
history of the Konqueror security UI. It was initially modeled after Netscape
4, displaying a closed golden padlock in the toolbar when an SSL session was
initiated and the certificate verification project passed. The toolbar is an
awful place for this, but consistency is extremely important, and during the
original development phase of KDE 2.0, this was the only easy way to implement
what we needed. Eventually we added a mechanism to add icons to the status bar
and made the status bar a permanent fixture in browser windows, preventing
malicious sites from spoofing the browser chrome and making the security icon
more obvious to the user. In the past year a padlock and yellow highlight were
added to the location bar as an additional indication. This was primarily
based on FireFox and Opera.

I was initially resistant to the idea of using colour to indicate security -
especially the colour yellow! However the idea we have discussed have been implemented by Microsoft in their IE7 address bar, when I saw it in action I was sold. I think we should implement Konqueror the same way for KDE4. It involves the following steps:

  1. The location toolbar becomes a permanent UI fixture along with the status bar
  2. The padlock goes into the location combo-box permanently, is the only place
    it appears, and the location bar stays white by default
  3. When verification on a site fails, the location bar is filled in red
  4. When a high-assurance certificate is verified, the location bar is filled in
    green, the organisation name is displayed beside the padlock, and it rotates
    displaying the name of the CA

I am afraid that the missing yellow will confuse our users, but at the same time
I think it was misguided to add the yellow when it was added, and I think this
is the price we must pay. Hopefully users will be able to adjust quickly, and
KDE4 is the right time to do it. The existence of the padlock and extended
identity information makes it safe even for those who have difficulty
distinguishing colours.

One more key item that Microsoft is implementing is their anti-phishing
plug-in
. I hope that Microsoft will be open with this system and allow us
to write our own Konqueror plug-in, allowing our users to contribute to their
database and take advantage of it. I think this is in everyone's best interest.
Microsoft says that they are not evangelising the anti-phishing service to other
clients at this time but they are "working with the community on the issue
through many avenues and groups, such as the Anti-Phishing Working Group and
Digital PhishNet". They didn't rule out the potential to open up their client
technology in the future. They suggested that others interested in offering
similar technologies could take their own approaches and work with the same
industry data providers that they use.

I'm very optimistic about the future of co-operation among browser developers
and I hope this recent work signals a new trend of good relations. Together we
can really create some amazing new technology and make it possible to solve some
of the major problems we face today.

Comments

What he meant was to use the ordering of colors in the US-style traffic light as a supplement to colors - ie, red on top, green on the bottom. He didn't know if this was a worldwide standard or US-specific, however.


By kundor at Fri, 2005/12/02 - 6:00am

As far as I know, red on top, yellow in the middle, green at the bottom is pretty international.

(The only difference that I know is that Swizterland does not use round lights, due to colour blindness, but a square for red, a triangle for yellow and a disk for green.)

Have a nice day!


By Nicolas Goutte at Fri, 2005/12/02 - 6:00am

I do not know how the traffic lights work in the US.
In Italy you cannot get a driving license if you are color blind.

However, as the following message shows, the icons are not going to be removed, so this is probably not a big problem.


By Luciano at Wed, 2005/11/23 - 6:00am

About 10% of the population is red-green color-blind to some degree or other.

Color-blindness to yellow, however, is extremely rare. Perhaps that's why FireFox chose yellow to begin with?

Others on this thread are right, however. Something in addition to the color needs to be unambiguously shown in the UI to indicate what the browser has determined the site's authenticity to be.


By Chuck Somerville at Wed, 2005/11/23 - 6:00am

Might be a good idea to read up on accessibility first:

http://www.w3.org/WAI/wcag-curric/chk3-0.htm


By Tom Potts at Wed, 2005/11/23 - 6:00am

As said before, colorblindness differs from person to person.
I may distinguish red from green sometimes, depending on the brightness, saturation and darkness of colors.

The idea to use icons is good.

Let the user modify his preferred colors is another idea, you might add.
Thanks.


By Stefan Wagner at Wed, 2005/11/23 - 6:00am

There are icons... read back through the writeup. It's even specifically addressed in the third to last paragraph: "The existence of the padlock and extended identity information makes it safe even for those who have difficulty distinguishing colours."


By Evan "JabberWok... at Tue, 2005/11/22 - 6:00am

Next time you get the developers together, can't you agree on a common bookmarks file ~/Bookmarks or something that all Linux browsers would use. It doesn't make any sense for every browser to have their own bookmarks.


By Tony at Tue, 2005/11/22 - 6:00am

Firefox has been doing this for over a year now.

Not that it matters much who invented it first, but I am really surprised that you have never seen this before until you saw an IE7 demo.


By Jason Keirstead at Tue, 2005/11/22 - 6:00am

I don't know where you get that "invented it first" stuff from since it's not in the article. What's in the article however is following impression of Mr. Staikos:

"I was initially resistant to the idea of using colour to indicate security - especially the colour yellow! However the idea we have discussed have been implemented by Microsoft in their IE7 address bar, when I saw it in action I was sold. I think we should implement Konqueror the same way for KDE4."

To make that clearer, Firefox started with coloring the URL bar yellow when an encrypted connection is used. The approach by the IE developers was to make use of that URL widget coloring to not only display whether the connection is encrypted, but also whether it's signed and whether the URL string may be pishing related.


By ac at Wed, 2005/11/23 - 6:00am

I'm not sure if the Microsoft developers were aware of this or not, but I had this very idea (of different colours for different states of encryption) when the proposal was first floated to colour Firefox's url over a year and a half ago.

https://bugzilla.mozilla.org/show_bug.cgi?id=244025#c1

Still, if IE implements this idea and the other browsers follow, this will be one example where Microsoft takes the lead for once.


By David P James at Wed, 2005/11/23 - 6:00am

On the desktop for my kids I remove the location bar from konqueror because everything that they access is already bookmarked. This has the added benefit of simplyfing the browser window for them. Would this change make that impossible - the location toolbar has to be part of the window???


By AlfredNilknarf at Tue, 2005/11/22 - 6:00am

Removing it manually, using the menus, may still be allowed.

However, allowing webpages to turn the location bar off using JavaScript may be impeded in the future.


By Thiago Macieira at Tue, 2005/11/22 - 6:00am

I would like a better handling of self signed certificates. It is so annoying that when using a perfectly valid and effective self signed certificate to secure internal pages (MRTG / webmail, etc) that we have to deal with the inherent warnings on most browsers.

I'd like to see a color code and location/status bar indicator, that the sie in encrypted, just not verified or something to that effect. I have had clients insist on wasting money on a certficate for internal only use!


By Brandon at Tue, 2005/11/22 - 6:00am

This may make your life a little easier, but it will also be of tremendous benefit to phishing scammers if all those annoying warnings went away, if they could be casually dismissed permanently for all sites. As it is (at least in Mozilla & Firefox), you can permanently accept the certificate for that one site.


By Paul at Wed, 2005/11/23 - 6:00am

You should find some way of installing those certificates in the browsers that need to use them, or for more flexibility run an internal CA (it's not that hard) and install its certificate, or just not bother with SSL. As it is, you're just getting a false sense of security, because your browser can't tell the difference between the certificate you created and another one presented by an attacker who spoofed the DNS response for the web server you're trying to use.


By Ben Hutchings at Wed, 2005/11/23 - 6:00am

Today you have much better and free alternative, which will be supported by most web browsers: http://cert.startcom.org
This will make the problem of self-signed certificates disapear, but as well expensive validated / verified certificates too...


By Eddy at Sun, 2006/01/08 - 6:00am

A color coding based on security is all well and good. However, it does 1/20th of the population no good if it is based on Gree, Red, and Yellow. Make sure that those who can't actually distinguish between two disparate colors can actually determine them in your implementation. Writing the color RED in white above a red background works wonders.


By concerned at Tue, 2005/11/22 - 6:00am

Just what i was thinking!


By Rob at Wed, 2005/11/23 - 6:00am

to both of you: read. just read the article and the link(s) in it. this has already been discussed, and adressed. apart from the color indication, there will always be some other form of indication for the visually impaired.


By superstoned at Wed, 2005/11/23 - 6:00am

IRIs and internationalised domain names and URLs are also a problem: particularly where a "foreign" codepoint has the same or a similar glyph as a "native" one. I'd like to see some kind of visual cue for:

- any characters in a URI that don't belong to my configured locale;
- any characters in a URI that don't belong to the locale of the displayed document.


By jang at Tue, 2005/11/22 - 6:00am

Which "leading web browsers" had developers at the meeting?


By Rib at Tue, 2005/11/22 - 6:00am

It said so in the article: Konqueror, Opera, Mozilla/Firefox and IE developers were present.


By Thiago Macieira at Wed, 2005/11/23 - 6:00am

I can't believe what I read. The community is fighting M$'s monopoly, and the developers of the "leading" browsers sat together to help them bugging out the flaws of their software. Thank you very much.


By Hugh at Wed, 2005/11/23 - 6:00am

Or to put it a completely different way: The developers of the leading web browsers were for once not keeping their users hostage in their fight for dominance, but had a meeting to agree on a consistent user interface for some security features.


By Herman Robak at Wed, 2005/11/23 - 6:00am

when it comes to certain things, data formats in particular, cooperation on standards is vital.


By Aaron J. Seigo at Thu, 2005/11/24 - 6:00am

were you people born stupid, or we're you cloned that way?

it's about user experience and unerversal understanding of the way browers tell you something isn't right with the page you are looking at, as it goes (if you bothered to find out) you'd know that ie 7 actually has features like that anyways, the meeting was about a common standard.

just because some people still live in caves, doesn't mean ideas can't be shared with the likes of microsoft, as long as it's not all give.


By streaky at Wed, 2005/11/23 - 6:00am

Kmail also uses green for verified gpg signatures, yellow for signatures which are unknown (but exists) and red for signatures which are not ok.

In general I don't think that it is a good idea to say to the user: Green, the web site is secure, because that is just wrong as: I have a firewall that says 100 Attacks blocked this day, I am save.

I would keep saying that people should not enter passwords in web forms and live is so great without a credit card, at least in germany ;)
A company will never ask for such things in a email, it is just that simple, they will send a mail, not a email and is they do, go to the site, login and follow the navigation. Don't klick on link in cool html mails.

Felix

P.S. After all, people need to learn companies are wrong if they say, everybody can use computers without thinking/learning. It is hard, but also a driver needs a driver lizense.


By Felix at Wed, 2005/11/23 - 6:00am

I'm glad to see the Internet has matures over the last 9 year (which is now long I have been working on the web). Back in '96 it was such an adversarial place with all those competing technologies.

Bravo to everyone who took part in the conference and making all our lives in the net easier.

Gerard


By Gerard Earley at Wed, 2005/11/23 - 6:00am

It's really great that the browser manufacturers have decided to take this one on the chin and recognise that phishing is a browser problem. It's also really fantastic that you are all now moving to get rid of SSL v2. As you must realise, this clears the way for proper sharing of TLS over single IP numbers which promises to make available low cost service. More SSL (v3 or TLS) can dramatically help the anti-phishing tools and this one of the few ways to get more TLS.

However, I urge caution in getting into bed with the other browsers. Browser manufacturers have come late to this party, and already they've done the worst possible thing for innovation: start a cartel. The people who really know about phishing weren't at your event, and your post and the posts of the other manufacturers are already evidencing group-think.

If the innovators had been there, they would have explained the real security thinking behind such innovations as Trustbar and Petname. Compared to these ideas, and the security and UI thought that went into them, the debate over URL bar colours is just a funny distraction. Also, the "strongly-verified cert" idea won't work, for much the same reasons that phishing broke the browser security model in the first place - it's an institutional and technical implausibility that is akin to asking the UN to organise World Peace. If it was going to work, we wouldn't have phishing in the first place, because the browser security model already said that it would stop MITMs like phishing (and, the original Netscape alphas even would have!).

https://www.financialcryptography.com/
http://wiki.cacert.org/wiki/AntiFraudCoffeeRoom


By Iang at Wed, 2005/11/23 - 6:00am

Has anyone ever been phished because of a low assurance certificate?

Why then have high assurance certificates - seems that it is just a way for certificate issuers to make more money.

Further, there is no evidence that the procedures for high assurance certificates will be any different - only the price.

Phishing is possible because:

1. Users are bewildered by the multiplicity of names, which makes proving the true name rather pointless.

2. Website software of major companies frequently has major errors, allowing phishers to make phishing content appear to come from the official web site and appear to be certified by the official certificate supposedly proving the true name.

The solution to phishing, as I say in my post , is for browsers to support SRP-TLS-OpenSSL, where both parties prove knowledge of the shared secret without revealing the shared secret, thereby proving a relationship, not a name.


By James A. Donald at Thu, 2005/11/24 - 6:00am

Do the other "security developers from the leading web browsers" have names?


By Soyapi at Thu, 2005/11/24 - 6:00am

yes


By Melchior FRANZ at Fri, 2005/11/25 - 6:00am

TrustBar is a FireFox extension that already (and for a while already) implements several of these ideas, and others. In particular, it supports both `petnaming` of a site, i.e. to assign a name (or, with TrustBar, a logo) to a site, and also display `Identified by` and the logo (or name) of the organization and of the CA, like IE 7. You can install it via http://AmirHerzberg.com/TrustBar.

TrustBar is the result of secure usability study by Ahmad Jbara and myself, and has some other mechanisms, including random `exercise training attacks` to help users stay trained to watch for the name/logo of the site. (I must admit that this mechanism is now set for too frequent `exercise attacks`, we will improve this in our next release very soon, but you can also reduce or eliminate this using the user interface of course).

We are very happy to see some of this research adopted by browsers. We have some more ideas we are investigating, and would love to cooperate with any browser developers to help improve security indicators. TrustBar is an `open source`, public domain project.

Best, Amir Herzberg

Assoc. Prof., Dept. of Computer Science, Bar Ilan University
http://AmirHerzberg.com


By Amir Herzberg at Thu, 2005/11/24 - 6:00am

I've been wondering about the use of popups to accept a (self-signed) certificate and to ask for user authentication.
Wouldn't it be much more secure to refuse the certificate/authentication request by default and show an (error) icon in the status bar?
Then the user has to initiate action and is far less likely to just 'click yes'.
I'd prefer this as an advanced user but I think it's also much better for 'simple' users.


By Olaf van der Spek at Thu, 2005/11/24 - 6:00am

It would be safer, but less usable. To many users, this would be a showstopper ("the site doesn't work!") and if only some browsers did this, the users would blame the browser.

If self-signed, expired, or wrong-name certificates were really rare, then your suggested approach could be viable. But, alas, they are not all that rare. Only MSIE could start refusing access unilaterally. If MSIE doesn't work, the webmaster will take the heat. If one of the other browsers doesn't work, the browser's vendor will take the heat.

Sure, sites with broken certificates shouldn't work, in ANY browser. To make that happen, the browser vendors have to cooperate.


By Herman Robak at Fri, 2005/11/25 - 6:00am

MSIE already replaced a (download) popup by a yellow bar below the address bar.
I think that's quite usable and a lot safer than a popup with Yes as default button.

It would be nice if browsers at least provide this as an option.


By Olaf van der Spek at Fri, 2005/11/25 - 6:00am

I don't think this is really good. For me, ssl provides two different things.
1. It supports encryption of the data transmited
2. It can give you the information that well known companies are trusting this site.

A self signed cert only supports the first one, because nobody knows if the private ca key is public or not.

But a self signed cert supports encryption, and often, this is enought. E.g. I don't like to buy a really expensive cert only for the external download server, bug tracker and mail gateway. I like to be sure that nobody can read what I transmit. I cannot be sure that the server is really my server.


By Felix at Mon, 2005/11/28 - 6:00am

> I don't think this is really good. For me, ssl provides two different things.

I don't see how this relates to my proposal. SSL/TLS continues to provide these things.


By Olaf van der Spek at Mon, 2005/11/28 - 6:00am

I think you should use form for security!


By james at Thu, 2008/08/07 - 5:00am

In addition, you can post it through the action property.


By james at Thu, 2008/08/07 - 5:00am

Is there anything close to DreamWeaver on Linux for ease of use to build a websites with flash and fireworks.


By Brian Woods at Mon, 2005/12/19 - 6:00am

>One more key item that Microsoft is implementing is their anti-phishing plug-in. I hope that Microsoft will be open with this system and allow us to write our own Konqueror plug-in, allowing our users to contribute to their database and take advantage of it.

---------

...and now Microsoft will have the list of webpages (and perhaps their referers too) each IP (or even each user) is surfing through.
That would greately help them in targeting the advertisements of Windows Live.
But i heard where do i surf, and what links do i follow was always considered private information and those companies like DoubleClick was punished for such spying ?


By Arioch at Sun, 2005/12/25 - 6:00am


By IVR at Thu, 2008/08/07 - 5:00am

Pages