Web Browser Developers Work Together on Security

[Jason Holt]

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

  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.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com