Slashdot Mirror
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."
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.
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).
"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.
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.
"'Yrch!' said Legolas, falling into his own tongue."
...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.
The Army reading list
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.
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.
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.
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.
OCO is Loco
In the very near future the single most important attack vector for webspoofing will be subversion of the local system. Once you get access to the local system, you can manipulate DNS and the certificate store as well, so no offline or online spoof check has a fighting chance of working reliably. For this to change, users would have to stop browsing with full privileges. IOW, it's good that browser developers keep working on improving security, but the bigger security improvements lie elsewhere.
Also, please don't confuse users by using different location bar coloring schemes. Firefox already uses yellow for SSL secured sites. If Microsoft makes yellow to mean "potential spoof", nothing good will come of it. IMHO having the browser give you "green lights" is a stupid idea. The best you can do is recognize when a security sensitive operation is taking place and alert the user to that fact. More than that will only provide a false sense of security. Use red when you know that a site is a spoof or encryption is insufficient, use yellow when a site uses sufficiently strong SSL.
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?
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.
"'Yrch!' said Legolas, falling into his own tongue."
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?
There is in general no reason to use C strings at all in C++, except where legacy interfaces demand them. Use std::string instead.
The Tao of math: The numbers you can count are not the real numbers.
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.
Sig under construction since 1998.
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.
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.
Morphing Software
I'll go tell my town that they should change the traffic lights to use gold to mean "safe to go through" then.
Seriously, Red = Stop, Yellow = Warning, Green = OK. It's been that way for ages. That's the standard. Firefox is wrong.
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.
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?
Hands in my pocket
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.
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.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
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.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
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.where bet has not been bounds checked for a negative is stupid in *any* language and isn't specific to C/C++.
Sig under construction since 1998.