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.

[LostCluster]

But how do you know that you didn't get the hacker site on day 1 and the real site on day 2? Without some authentication protocol being followed, you're not secure. Sure, there's no way you're being intercepted when you're talking to the site, but you don't know what's on the other end of the line.

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?

Re:Don't use self-signed certs.

[pthisis]

The same way you do with SSH or PGP. You verify the fingerprint, which you received by some other channel secure enough for your purposes. That could be simply over the phone from someone whose CallerID and voice you recognize or could be a trusted courier with a locked case. It could even be IM if you're just testing how to set up SSL certs and don't really care if this one is secure or not since you're going to wipe it for a real one later.

People have been doing it for years.

It's not a good general purpose solution for the uneducated, but forcing people who know what they're doing to outsource key management is equally poor. Ideally the browser messages would be along the lines of SSH.

1. Warn you when the key is unknown and ask you to verify the fingerprint. Perhaps require you to enter the print (type it in) to use a self-signed key.
2. Refuse to connect if the key has changed.

Other scenarios (expired key, etc) require some thought and local policy decisions.

Re:Don't use self-signed certs.

[BitterOak]

The conflation of authentication and encryption is the bane of SSL and all SSL-based applications. The two really should be separate.

The problem is that encryption without authentication is really not secure as you'd be vulnerable to a man in the middle attack. Even in the examples you described, a man in the middle could present you with a self-signed certificate, and if you just click "yes" to accept a self-signed cert all the time, you possibly wouldn't notice, unless you routinely check the key fingerprints, which most people don't do.

SSLv2?

[goofyheadedpunk]

Would someone mind explaining the removal/disabling of SSLv2? More importantly, what's slated to be used in place of it?

Re:SSLv2?

[smclean]

SSLv3, of course.

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

Re:SSLv2?

[capmblade]

SSL2 has some serious security defects, including the inability to detect man-in-the-middle attacks against its handshake. TLS is the replacement.

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

[maxwell demon]

There is in general no reason to use C strings at all in C++, except where legacy interfaces demand them. Use std::string instead.

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.

Re:You know what would really help...

[Dan_Bercell]

As the speed of computers and VMs grow the resource issue will fade away.

I am not saying this will happen soon, but when you purchase a home PC from Dell and it comes with a base configuraton of a 64bit processor and a 2gig mem chip I doubt the cost of even the slow Java VM would make much of a difference to the avg user.

C will probably never die though, what else are we susposed to write those OSs and VMs with? :)

Plagarism?

[SteveM]

Copied from here?

SteveM

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.

One real simple way to start.

[Skiron]

Is to not have the[a[ web browser interfaced with kernel/operating system. A stand-alone application browser (a la K-Meleon, Firefox, etc.) will immediately stop the devs having to worry about other security overheads (reference IE that is built in (badly) to handle all sorts of stuff that it shouldn't even touch).

I guess thats correct

[Crimsane]

"IE 7 is one of the first browsers to implement some of the ideas discussed such as colour coding location bars"

I like how this person uses "one of the first" in a positive sense.

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.

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

[kryten_nl]

Yes, just like the terror alert system. Now, one question should I start being really worried at magenta or can I wait until crimson?

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.

On the other end....

[tcopeland]

...developers need to be aware of how to write secure server-side code. Joseph Hemler's book Network Security Tools has a chapter about finding security flaws with static analysis tools like PMD.

Phishing

[Anonymous Coward]

Can we find a better name then phishing? Most people don't get it, and wave it off as just another over complicated word that people who think they are smart use. They will ignoring an anti-phishing filter because they just don't know it is.

We need a none geek term for this, something that is clear and easily understandable. "Malicious Websites" or an "Identity Theft Filter" just not phishing.

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.

Not new ideas.

[StrawberryFrog]

Ideas such as colour coding location bars and an anti-phishing database.

Do they mean like in the Netcraft anti-phishing toolbar?

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.

Encryption is not the problem

[Agelmar]

I've seen a number of posts about encryption being the problem. It's not. Yes, it is possible to crack some older algorithms with distributed botnets, yes, self-signed certificates pose a problem, but no, these are not the real problems. The real problems facing users (by this I mean the problems causing financial damage to consumers and companies) come from attacking the user and his/her environment, not attacking the encryption. When was the last time you saw someone brute-forcing the decryption of a session, with the purpose of obtaining the user's information? This makes great stuff for movies where we're tyring to crack into an Evil Foreign Government or an ultra-sophisticated criminal, but in real life this is not the threat.

The threats that browsers need to address is the fact that their *users* and their user's *environments* are being attacked. Phishing attacks don't target weak encryption protocols. Heck, most don't even bother setting up an SSL-enabled phishing site, because people don't look for encrypted sessions in general. Phishing attacks target the user by attempting to fool the person into believing that they are at the actual site. Ask yourself - would your mother know that chase-online-banking.com is not the real address for Chase's online system? (Phishing trends show that phishers are increasingly using name-based attacks, as opposed to an IP-based URL).

As for attacking the environment, keyloggers and malware in general are exploding in popularity. Again, this is not a problem with the encryption protocols used for securing sessions, rather it's the user's environment being attacked. One must remember that browsers don't run in a vacuum - they have a user and an environment. Using 256-bit AES encryption is great, nifty, and cool, but if my mother's computer has a keylogger installed and I decide to do some e-banking while visiting for the holidays, well then I've got a problem.

People need to re-evaluate security in the context of which these applications are run, and stop thinking that simply increasing keylength or swapping cipher algorithms will solve the problem. It won't. Our problem is that security isn't usable, it isn't intuitave, and untill we make it so we will continue to have these problems.

Re:Suggestion

[Anonymous Coward]

If A and B are true, you have successfully connected to citibank.com over an encrypted channel, end of story.

Not quite. If A and B are true, you have successfully connected to a computer claiming to be citibank's website at citibank.com using a certificate issued by someone to "prove" it. Of course, https://web.da-us.citibank.com/ (the site I get when I hit login) has a certificate issued by VeriSign, and we know how well they verify the identify of people requesting certificates.

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.

Re:Suggestion

[Craig Davison]

The organization name is not important to HTTPS because it never gets compared against anything. If Verisign issued another cert with a CN of citibank.com to another company, then yeah, the system has broken down.
If you get a self-issued cert, how do you know it's the right cert? Do they mail it to you pgp-encrypted? Read the fingerprint over the phone?

Phishing database really efficient?

[Misagon]

I read a study recently that most phishing web sites don't live longer than a week...
A database of unimportant entries is not going to do any good.
I figure that Microsoft will have to keep a staff of around a dozen people day and night checking out each one of these flagged URLs as soon as the URLs come in, or otherwise it is not going to be very effective.

Re:Phishing database really efficient?

[Agelmar]

You're actually a bit off in your timeline, in that 'average' is really a poor [misleading] statistic to use for this. The data is extremely bimodal. For phishing sites hosted by ISPs in the U.S. that are reported on a weekday other than Friday during business hours and/or name-based attacks (registering a domain that looks like a legitimate domain), the average turnaround is around 40 hours. For phishing sites first reported and/or launched on a Friday afternoon, and hosted in China, Singapore, or certain other countries, and/or name-based attacks with domains registered through small, sometimes less-than-responsive registrars, you can easily be talking five days or more.

With that said, if you are proactive and/or are paying people to watch out for your corporate identity, you may be able to spot phishing attacks on the 30-minute timeframe. The difference in being able to respond in 30 minutes by calling MS and having them add a site to a blacklist is significant when compared to waiting 2-5 days. You are essentially reducing the survivability of sites with respect to a very large number of users by orders of magnitude.

And yes, Microsoft will have a staff of people (they wouldn't tell me exactly how many) that are monitoring this blacklist. They also have a set of heuristics that they use, but I think the blacklist may be the most effective. Remember, for a company the size of Microsoft, hiring (as you estimate) about 12 people (who do not need to be extremely savvy, and can therefore be minimally paid) is not at all infeasible.

Re:Suggestion

[rainman_bc]

These problems can also occur in real life. People who create false fronts for bank machines.

You know you are at the bank machine at the right location, so you trust that it's correct and isn't going to screw you, when in fact, you just passed your card through a card reader, and there's a camera watching you type in your PIN.

IMO, it's a real life phishing attack. The security implications are almost identical.

Re:A bad programmer

[Godeke]

A bad programmer can be equally incompetant in any language.

And you think these guys would have done *better* in C/C++? Surely a bad coder can wreck any project. However, Java or C# allow a *competent* programmer to avoid *by default* many pitfalls that a C/C++ programmer must remain on guard for. C/C++ has its use, but I believe it is selected for projects where it isn't a requirement to have low level access to the OS and memory management.

if (loser) { credits -= bet }

where bet has not been bounds checked for a negative is stupid in *any* language and isn't specific to C/C++.