[dot] Web Browser Developers Work Together on Security

[Dot Stories]

URL: http://dot.kde.org/1132619164/

From: George Staikos <>
Dept: all-together
Date: Monday 21/Nov/2005, @18:26

Web Browser Developers Work Together on Security
================================================

   Core KDE developer George Staikos [http://www.staikos.net/] 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
[http://blogs.msdn.com/ie/archive/2005/11/21/495507.aspx], 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:

 The location toolbar becomes a permanent UI fixture along with the
status bar The padlock goes into the location combo-box permanently, is
the only place it appears, and the location bar stays white by default
When verification on a site fails, the location bar is filled in red
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
[http://blogs.msdn.com/ie/archive/2005/11/17/494040.aspx].  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.