Web Browser Developers Work Together on Security

JRiddell writes "Security developers for the four major browsers recently met together to discuss Web security. The meeting, hosted by Konqueror's George Staikos, looked at future plans to combat the security risks posed by phishing, ageing encryption ciphers and inconsistent SSL Certificate practise. IE 7 is one of the first browsers to implement some of the ideas discussed such as colour coding location bars and an anti-phishing database." From the article: "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."

Comments

Don't use self-signed certs.

[LostCluster]

I've seen several site operators let their sites sit with SSL warning boxes because they insist on using a self-issued SSL certificate instead of paying for a major brand name label.

Most of the time, this isn't exposed to customers, but employees of the organization are trained to ignore the "This certificate was not issued by a trusted authority," warnings, and I fear such people will take away that that box with all of its technobabble is one they should ignore at all times. That box is a last line of defense against an encrypted connection that isn't trustworthy... and I think this is a step forward to the point where browsers will refuse to give SSL encryption without SSL authentication succeeding.

Re:Don't use self-signed certs.

[smclean]

What would be nice, is to see browsers handle this the same way SSH does with host key checking; when you first connect to the site, you get the pop-up about the self-signed certificate, and you accept it permanently. Then you connect to what you think is the site the next day, but instead of the real site you get a malicious impersonator of the site, and its cert is different. Rather than getting a new pop-up about the new self-signed cert that looks identical to the pop-up of the old one, there should be a warning that the cert had unexpectedly changed, in a similar panic fashion to SSH's output when the host key changes, so it really gets some attention.

Re:Don't use self-signed certs.

[ajs]

The conflation of authentication and encryption is the bane of SSL and all SSL-based applications. The two really should be separate. Encryption buys you a certain set of guarantees and leaves you with a certain set of exposures that you already had.

In those cases where that is sufficient, the introduction of authentication only muddies the overall value and importance of clean authentication. For example, I use TLS for SMTP mail delivery, but with a self-signed cert. This is because I don't particularly care about being intercepted, only that the casual sniffer of traffic between us will get nothing. For anything more sensitive, I don't trust SMTP anyway, no matter how encrypted and authenticated it might be.

The same goes for LDAP. I tried to set up LDAP between my home and work for the purpose of sharing some contact info. I wanted to encrypt and filter traffic so that only I could access it, but didn't really care about it so strongly that I was willing to buy a cert. However, I still had to hack the client to accept the self-signed cert. Why? What possible value to the user (me) is there in that?

Replacement.

[jimmyhat3939]

In case anyone's curious, here is a description of the problems with SSLv2, including some info about the newer v3 stuff.

Plagarism?

[SteveM]

Copied from here?

SteveM

Re:SSLv2?

[smclean]

SSLv3, of course.

http://wp.netscape.com/eng/ssl3/ssl-toc.html

Re:Suggestion

[LostCluster]

The problem with your self-made whitelist situation is that you have no way to authenticate your bank's website the first time. Just because you're sure you've got the URL right is no proof that you don't have a rouge DNS entry or router somewhere between you and your bank. If you can get fooled into adding a spoof site to your list, your whole theory colapses.

Microsoft participation

[mustafap]

It's nice to see Microsoft participating in the event. I was surprised; I didn't think they sat round tables with open source developers. Does this happen in other areas of development?

confusing color shemes

[c_fel]

I see on the screenshots that IE7 is gonna use a yellow location bar to indicate a suspicious web site. Ironically, in Firefox, that same color indicates a secured site. I'm sure somebody will be fooled someday...

Re:confusing color shemes

[Ark42]

Firefox has had the yellow=secure for quite a while, and IE7 is not yet out. Obviously it is IE that needs to change then. The yellow color comes from the yellow/gold lock icon that almost all browsers display someplace unnoticable usually. Now the golden lock is displayed in the location bar on the right hand side in both Opera and Firefox, and the background color is yellow in both of them. Firefox has the entire location bar yellow, while Opera has a yellow outlined and yellow shaded box with the lock icon and the name the certificate is listed under.
Clearly yellow (gold) is the de facto standard for "secure" and IE7 is just plain wrong to use green instead, and make gold mean something bad.

Re:Suggestion

[Craig Davison]

I don't think you understand the assurance a certificate gives you. You don't need to be worried about being tricked or DNS being compromised because that's exactly what a cert protects you against. Look for the following two things:
A. Is the domain name on the address bar the one you want? (example: citibank.com)
B. Did the page come up without any errors from the web browser?

If your DNS server was compromised, B will not be true. If you're taken to some site that may or may not have been issued a valid cert by Verisign, but is definitely NOT citibank.com, A will not be true.

If A and B are true, you have successfully connected to citibank.com over an encrypted channel, end of story. Whether you want to trust the company on the other end is totally up to you, but now you know for sure who you're dealing with.

Confusion

[fishybell]

Maybe it's just me, but an even bigger problem arises out of color coding the address bar: Confusion.

Many users have significant problems when anything changes in their computer experience; my father for example. I tried moving him over to Firefox so that he could stay away from spyware et al, but he couldn't make the move because he couldn't navigate the user interface anymore. This man is no dullard either. He taught me to program when I was 8, has a PhD in (if I remember correctly) biology, pharmacology, or physics, teacheds microbiology, and is an associate dean at world-class university. For all of his smarts, he has had problems with computers ever since he was weened off of DOS and onto Windows 3.1. After many years of training he's finally to the point where he can work successfully in an evironment as long as nothing ever changes.

Skip ahead to Windows XP service pack 2. Automatic updates are now on. He's been trained to allow the updates to happen, but only after I get a phone call asking me if they're ok. Unfortunately, updating sometimes means that I have to spend an hour or so teaching how to burn cds, how to switch between home/work networks, how to play music, etc. at regular intervals. I rue Microsoft not for their lax security (well, not just for their lax security), but for their ever present desire to "upgrade" their interfaces to make them "easier."

At his work they upgrade computers relatively often. The day will come when he will have to call me each time he goes to a website with the "wrong" color.

Re:Confusion

[shis-ka-bob]

How can you not know what field his PhD is in? I can assure you that my kids know that mine is in Physics (and grandpa's is in Music). Pharmacology and Physics are quite seperate fields (although I guess that a French physicst is a physicien and all know that Pharmacologists and physicians work together.)

My kids are sick and tired about hearing about my stories from grad school. There are only so many things you can do with liquid nitrogen to stave of the bordom of collecting data. They know all my rubber nail in 2x4, frozen cricket (they really do stop chirping if they are cold enough) & exploding pop bottle stories (a 2 liter plastic bottle with a few tens of milliliters of LN will completely vaporize if you put on the cap and wait for the LN to evaporate. It leaves a cloud of frozen water vapor too.) By now, you probably understand why they are sick of my stories.

Re:Err....four?

[Bogtha]

There's four major rendering engines. Trident (Internet Explorer on Windows), Gecko (Mozilla, Firefox, etc), Presto (Opera), and KHTML (Konqueror, Safari, Omniweb, etc).

Konqueror is important because it's the original branch of the KHTML rendering engine, used in a number of browsers, throughout KDE, and sitting on the desktops of millions of Apple users as part of Safari.

So while it's slightly inaccurate to say that Konqueror is one of the four major web browsers, what was meant, and what is actual fact, is that Konqueror's rendering engine is one of the four major rendering engines.

Re:I guess thats correct

[Crimsane]

well at the very least I'm sure we can all agree that IE is definitely the best browser not on the market.

From what I can read here its undoubtably the best browser I've never tried, and (god willing) it will stay that way for many years.

Re:You know what would really help...

[cnettel]

We have to observe a few things:

1. There is a huge "backlog" of sloppy coding that is either exposed through changes in higher layers, or simply not discovered until now.

2. Many of the web browser vulnerabilities lately (and historically, in IE especially) have not been related to overflowing a buffer. They have more been along the lines of fooling the browser or the user of it that you are in a different security context than you really are. That is possible to do in any language. It just takes a single instance of a piece of code doing something "on behalf of" something with a lower security privilege, like just about anything done in a browser. There are techniques for sandboxing and walling this in, but enforcing something like the logic for when to allow scripting/DOM access between frames in a web browser is not something very well suited to the Java (or .NET, for that matter) security model. You simply have to do the hard work and do it right.

So, in the specific space of browsers, I think that the issue of the language used is not very relevant. What IS relevant is to use a sound design, where the security decisions are made by some components, not all over the place. Componentization, no matter if it's done by XUL/Javascript or by encapsulation into COM/ActiveX are both examples of this. In practice, the execution of the previous have been better than the latter.

Another point would be that moving towards Java or some other VM with interoperability issues, at least when you get into directly calling other code in-process, will force you to rewrite bad C/C++ code. I don't know if that's a bug or a feature. It would rule out buffer overflows, but it would also mean a gigantic, untested, new code base.

Re:Nice ideas, but...

[jaseuk]

I just posted a message on the blog, but I'll reiterate it here.

NOTHING has really changed for firefox if they go for YELLOW/GOLD for SSL sites with bad / unverified SSL certificates.

YELLOW is the current SSL state in firefox for ANY secure site.
GREEN is a new additional SSL state for sites with trusted CAs.

This is actually quite good as all users can be taught to treat the YELLOW ones with some caution. Either because they are using an older browser version that doesn't support the GREEN or the site is not properly verified.

I really don't see the problem. It seems like a sensible way to introduce the change.