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.

[smclean]

True, but I'm not trying to say that using self-signed certs offers security to compare to certs signed by real CAs. I'm just pointing out that the behavoir of the self-signed cert popups in browsers is lacking, and could learn from SSH.

Self-signed certificates can be very useful for a situation where you want *more* security than plain unencrypted HTTP, but don't want to pay money for it. If you wanted to have SSL encryption on a LAN, but the server's hostname is not a real hostname on the internet, I don't think you even *could* get a real CA-signed cert for it. Self-signed certs fill a real void when it's not possible to simply use real CA-signed certs. We can't just ignore that.

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.

You know what would really help...

[Godeke]

Stop coding in C/C++ when the product will be exposed to external, uncontrolled inputs. Java, .NET, Parrot... I don't really care what gets used, but it has been clear that despite the constant "C++ using the proper string libraries is as secure as virtual machines and interpreters" cries that those who actually wield the language to make products like browsers are still failing to secure against the most basic and common flaw: the buffer overflow. Browsing web pages is *not* the kind of thing that requires "bare to the metal" coding. Yes, such a browser might be vulnerable to attacks on the virtual machine itself... but a quick look at the browsers security history verses virtual machine security histories makes it clear that is a tradeoff worth making.

Re:You know what would really help...

[KiltedKnight]

Yes, such a browser might be vulnerable to attacks on the virtual machine itself... but a quick look at the browsers security history verses virtual machine security histories makes it clear that is a tradeoff worth making.

Actually, the trade-off you'll be making is more like execution speed and resource usage for apparent safety in terms of lack of buffer overflows.

This is not a good trade-off to make. Experienced programmers working with C and C++ will know of the buffer overflow issues, especially if they've been bitten by it before. A similar one is failure to null out a string before using it, risking problems when the string you want to put in the variable is not null-terminated.

Basically, if you remember to do a few simple things (fgets() instead of gets(), strncpy() instead of strcpy(), memset(), just to name a few), you can actually avoid a lot of these issues. Make these things habits, and it will not become an issue.

Re:You know what would really help...

[Godeke]

This is not a good trade-off to make. Experienced programmers working with C and C++ will know of the buffer overflow issues, especially if they've been bitten by it before. A similar one is failure to null out a string before using it, risking problems when the string you want to put in the variable is not null-terminated.

Any explanation as to *why* this isn't actually being done then? Because, as I stated, people keep *saying* this as if repeating it makes it true. Yet the reality in the field is that buffer overflows from C/C++ code is the number one source of security flaws. This claim is like saying that "people would die of fewer heart attacks if they would eat healthy foods". Um, yeah... sadly not many actually eat healthy. Clearly, not many "experienced programmers" are putting your advice to practice either. So I will take code bloat and speed hits for the sake of not being a subscriber to the buffer overflow of the month club.

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.

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?

Re:Microsoft participation

[ichigo 2.0]

It does sound counterintuitive at first, but when you think about it, Microsoft doesn't make any money off IE, so working together with the other browser developers is a good way to ensure all Windows browsers get better security. Helping Linux browsers to improve doesn't really matter, because Linux already has an image of being extremely secure, so collaborating with open-source developers is a win-win situation from a PR and development perspective.

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

[Loconut1389]

to me, yellow is almost orange or on the way to red, whereas green to me says secure.. I think IE is on the right track and firefox is the one that needs to change.

Re:confusing color shemes

[LostCluster]

Which is why they held this meeting in the first place. Everybody's got to agree on little things like color schemes for there to be cross-browser compatibility.

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:confusing color shemes

[Klivian]

Firefox has had the yellow=secure for quite a while,

The same for Konqueror, but it does not really mater that much. In this case the IE7 approach makes more sense, so they agree to change it. Besides calling yellow the de-facto standard is not correct, as de-facto would be what IE5 and IE6 uses.

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.

Free market self-regulation

[dada21]

I'm happy to see that we're looking at an important part of a free competitive market: voluntary cooperation for better competitive products.

The security enhancements we'll see that come out of these (and future) discussions will help all users yet also increase competitiveness in other areas. We didn't need a Congress or government body to force regulations, they're occurring out of customer need.

Note that government could create regulations but we all know that those regulations come too late and can never adapt to current and future ever-changing needs.

I read a great article today about the historical growth of the Net because of the lack of regulations and taxes.

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.

Err....four?

[Anonymous Coward]

OK, raise your hand if you think there's a clearly identifiable "four major web browsers." As in, when you hear the phrase "representatives of the 4 major web browsers" you know exactly which 4 are being talked about.

OK, now how many of you had Konqueror as one of the 4?

C'mon--I like Konqueror as much as the next user, but beyond IE and Firefox there are a large number of minor browsers out there. Mozilla, obviously, unless you lump that with Firefox as I do. Then probably Opera. And then, what, Safari? Konqueror is maybe 6th or 7th. So how "cross browser" is this?

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: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.