[KDE Dot News]
 faq
 flatforty
 contribute
 subscribe
 configure
 search
 rdf

 main


  Web Browser Developers Work Together on Security
Konqueror Posted by George Staikos on Monday 21/Nov/2005, @16:26
from the all-together dept.
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.



<  |  >

 

  Related Links
 ·   Articles on Konqueror
 ·   Also by George Staikos
 ·   Contact author

Thread Threshold:

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Over 40 comments listed. Printing out index only.
IE
by MamiyaOtaru on Monday 21/Nov/2005, @17:22
Little surprised to see IE on board with a meeting like this, but it is good too see. For better or worse most people still use it. This way, those who migrate over will see things they are used to (colored address bar) and those who don't migrate will have that added security.

Congrats on bringing all those browser folks together!
[ Reply To This | View ]
cool
by bangert on Monday 21/Nov/2005, @17:36
nice initiative on the SSL front.

about the phishing prevention i am not so sure. we should come up with a better solution to the identity verification problem and if that requires better technology _that_ should be supported.

fx. could banks sign our keys and when going to a site a small notification would tell me: this is your bank! if thats missing, then i know its not my bank...

another problem is the location field: half (if not more) of the people surfing the net, don't have a clue what is going on in there. now how do we make that more simple?

anyway, trying to blacklist or whitelist stuff is really not a smart way to do this. also, this problem is not new and exists in the same way in the real world: credit fraud, fake notes, weird guys ringing your door bell trying to sell stuff etc.

the reason why phishing (on the internet) is so attractive are:
- easy to do
- difficult to track
- clueless users

AFAICT the proposed solution does not solve any of these problems... the way i see it, it gets even worse, because "now we can feel safe again"!

... and i don't feel confident about sending each and every URL i visit to some server for authorization (even if it is only SSL).

in conclusion i would claim that the clueless user is the biggest problem here and i tend to agree that technology should be simple enough for the clueless user also... but he has do to his part as well. so lets educate those guys...
[ Reply To This | View ]
konqueor...
by Ilovekonqueror on Tuesday 22/Nov/2005, @00:38
Konqueror browser web and konqueror browser file should be separated. Althought konqueror browser file can use khtml. This is the best. Less dificult, more open velocity, ...
[ Reply To This | View ]
White-listing vs black-listing
by Andrew Yeomans on Tuesday 22/Nov/2005, @01:25
The above improvements sound good. But can I make a further suggestion?

Like many people, I have a few sites that I want complete assurance about, such as my personal banking sites. I don't want to simply trust a third-part CA to vet them, even if it is capable of providing high-assurance. As well as concerns about the business model for that CA, it still will sign a very large number of web-site certificates. If any of those web sites were compromised or the CA was tricked into signing a certificate, it opens an opportunity for the browser to say "highly trusted" when it isn't - and may even be a different web site if DNS could be compromised. And I expect it would take a long time, if possible at all, to persuade all sites to get the signed by one of the "blessed" CAs.

I much prefer the model used by the Petnames extension of Firefox (http://www.waterken.com/user/PetnameTool/), which allows me to register the server digital certificate thumbprint, and to give the site a nick-name ("My bank"). If the certificate changes in any way, I'll get warned and can do the appropriate checks. Effectively I'm managing my own white-list of a handful of sites, so don't need to trust someone else's whitelist of tens of thousands; or even worse a blacklist of far more.

This can co-exist with the proposals above; for example by allowing the user to store their trust relationship which then displays (say) a blue address bar. Other sites will go through the green / red / white display.
[ Reply To This | View ]
Weak Ciphers
by Fizz on Tuesday 22/Nov/2005, @01:36
Please, please, please, please, please dont't remove support for weaker ciphers, just have them disabled by default. I often make use of weaker ciphers in my work and if you remove support for them you will force me to use another browser. If you disable them I will then be able to re-enable the support when I need it.

Fizz
[ Reply To This | View ]
Thank you
by Philippe Fremy on Tuesday 22/Nov/2005, @04:05
George, thank you for all the effort and work that you are putting in this. It will definitely help the world of browser to move toward more security and without somebody tackling the problem as you did, we could have seen many different and incompatible approaches. You are doing a great job !
[ Reply To This | View ]
Microsofts take
by Richard Moore on Tuesday 22/Nov/2005, @06:25
http://blogs.msdn.com/ie
[ Reply To This | View ]
Good idea! but...
by Luciano on Tuesday 22/Nov/2005, @07:43
please remember that there are color blind people out there.
Conveying information only by means of color is not so good from an accessibility point of view. But maybe using that in addition to distinct icons would be great.
[ Reply To This | View ]
Next time you get together....
by Tony on Tuesday 22/Nov/2005, @10:09
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.
[ Reply To This | View ]
Microsoft did not invent this idea (color url bar)
by Jason Keirstead on Tuesday 22/Nov/2005, @11:30
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.
[ Reply To This | View ]
Permanat Location Toolbar?
by AlfredNilknarf on Tuesday 22/Nov/2005, @12:07
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???
[ Reply To This | View ]
Self Signed Certs
by Brandon on Tuesday 22/Nov/2005, @12:56
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!
[ Reply To This | View ]
Remember the colorblind
by concerned on Tuesday 22/Nov/2005, @13:46
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.
[ Reply To This | View ]
IRI / I18N warnings too
by jang on Tuesday 22/Nov/2005, @13:48
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.
[ Reply To This | View ]
Leading web browsers
by Rib on Tuesday 22/Nov/2005, @14:35
Which "leading web browsers" had developers at the meeting?
[ Reply To This | View ]
Kmail also uses green, yellow, red
by Felix on Wednesday 23/Nov/2005, @06:51
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.
[ Reply To This | View ]
co-operation
by Gerard Earley on Wednesday 23/Nov/2005, @06:56
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
[ Reply To This | View ]
Good start, but only that!
by Iang on Wednesday 23/Nov/2005, @12:02
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
[ Reply To This | View ]
Pointless to have high assurance certificates
by James A. Donald on Wednesday 23/Nov/2005, @19:35
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 <http://blog.jim.com/?postid=48>, 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.
[ Reply To This | View ]
Names?
by Soyapi on Wednesday 23/Nov/2005, @21:12
Do the other "security developers from the leading web browsers" have names?
[ Reply To This | View ]
TrustBar - a FF extension implementing these ideas
by Amir Herzberg on Thursday 24/Nov/2005, @00:38
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
[ Reply To This | View ]
Don't use popups, require user to initiate action?
by Olaf van der Spek on Thursday 24/Nov/2005, @03:07
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.
[ Reply To This | View ]
SuSe
by Brian Woods on Sunday 18/Dec/2005, @21:51
Is there anything close to DreamWeaver on Linux for ease of use to build a websites with flash and fireworks.
[ Reply To This | View ]
such a perfect spying tool!
by Arioch on Saturday 24/Dec/2005, @20:47
>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 ?
[ Reply To This | View ]
The Fine Print: The previous comments are owned by whomever posted them.
( Reply )

  "Ok guys, I'll implement focus-follows-mind next time and ship a magic patch." -- Matthias Ettrich
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.
[ home | post article | flat forty | subscribe | search | rdf ]