Mozilla SSL Policy Considered Bad For the Web

Chandon Seldon writes "The issue of digital certificates for SSL and the policies surrounding them comes up repeatedly. I've written an article criticizing the behavior in Firefox 3, which includes a serious comparison of the current Mozilla policy — restricting encrypted HTTP to paying customers — to a violation of net neutrality."

Comments

Seconded.

[Anonymous Coward]

I second this complaint.

Re:Seconded.

[Adult film producer]

I second post your complaint.

Re:Seconded.

[lukas84]

This is bullshit.

It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.

Now, who uses self signed certificates or certificates signed by an internal CA?

* Test environments (not an end user scenario)
* Unprofessional webhosters (good riddance)
* Companies with their own CA (they can preload the certificate)
* Hobbyist systems (they can reconfigure their browser)

In the end, the only ones hurt by this are unprofessional webhosters - and i don't think anyone should care about them.

Re:Seconded.

[Hes Nikke]

On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.

Re:Seconded.

[Anonymous Coward]

Now, who uses self signed certificates or certificates signed by an internal CA?

I do for our extranet which we allow a handful of clients access to. Why should we pay some external company for their certificates when all we need is encryption?

Re:Seconded.

[Thiez]

Except that there is nothing compulsory about ff. You are free to trust any certificate you want, the browser merely warns you that it could be a bad idea to do so.

Re:Seconded.

[SnT2k]

Our school uses a self-signed certificate for the courseware. We won't get freaked out because we're CS students (but it's really, really, REALLY annoying, especially if you access public terminals) but I bet the rest of the student population will.

The most ideal interface would probably be the one in IE7 but personally, I'll go for Opera... it's the least intrusive.

As for hobbyist systems, they (the site owners) usually tell their less-than-techy friends to access their sites which is installed with self-signed certificates... (can be due to various reasons from hosting a Trac+SVN server to HTTP authentication over SSL, etc) aside from waving your hand to get them to visit your site, you also have to play tech support for them to get past the esoteric error message.

As for unprofessional webhosters, they usually hand out shared certs to keep the cost down but of course, they also give you an option to get a personal cert... at a price... it's not very convenient for people living at other parts of the world (particularly in developing countries). You don't want (or do you?) to shut them out from online business opportunities just because all they can afford is a shared cert.

Re:Seconded.

[Goaway]

Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks.

Re:Seconded.

[Anonymous Coward]

On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.

They don't call it "auto insurance" for nothing!

Re:Seconded.

[Anonymous Coward]

But you only have a handful of clients, who know that you're trustworthy, so it's a non-issue for you.

Re:Seconded.

[j79zlr]

On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.

Driving is a privilege not a right. Unless you have the money to cover any damages you may cause, it is absolutely necessary to have insurance. The cost of barebones liability coverage is not that high assuming you have a relatively clean record and if not, you probably shouldn't be driving. It seems that today the idea of personal responsibility is falling out of favor.

Re:Seconded.

[Hes Nikke]

Thats what they said about IE6 - you don't HAVE to write your web pages twice (once for standards and once for microsoft) but if you don't, you're cutting out a huge portion of your audience ;)

Re:Seconded.

[user24]

It's hardly a "mere" warning; it's a gigantic stop sign.

If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different. Instead they interrupt the browsing experience with a very unfriendly message that non-tech people will not have a chance of understanding.

This is bad because, as the article says, some sites will end up having to buy certificates when in fact they don't need one, and others will end up not using encryption when in fact they should be.

Bear in mind the three levels of security:
1) no-ssl: offers neither encryption nor authenication
2) SSL(self-signed): offers encryption
3) SSL(3rd party signed): offers both

why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?

Re:Seconded.

[lukas84]

Our school uses a self-signed certificate for the courseware.

Than tell the admins to fix it. School environments are hard to do, because you have a lot of non-standard clients. So a public cert would probably be better for a school than an internal CA (which would make sense for a company).

Again: Firefox and IE both give a very stern warning that what you're going to do is potentially risky. This is the *RIGHT* thing to do - if that wasn't the case, with the recent DNS issues it would be easily possible to spoof https://www.yourbank.com./

Basically, don't blame Firefox if your cost-cutting measures break on you - it's your own fault.

Re:Seconded.

[JoeKilner]

I've seen quite a lot of academic institutions use self-signed certificates.

And I have to admit, the first time I saw the self-signed certificate error, I didn't actually read it and assumed it was a dead server / bad link and went to a different site...

Re:Seconded.

[Z00L00K]

If you run a self-signed certificate you still can get the man in the middle protection.

There is no difference there, the only difference is that you don't have to pay for a certificate from a well-known root CA. The "insecurity" of not using a well-known CA is only a commercial stunt.

As a web admin you will of course also have to maintain the certificate store, but that may be very easy if you only have a handful of clients. And if you have a handful of clients you may install the root certificate in a controlled situation on the clients, so not even there you have a big problem with insecurity.

Re:Seconded.

[bickerdyke]

mod up. Thats the fallacy in TFA.

Re:Seconded.

[redscare2k4]

I really hate that FF3 behavior. At my job they have a proxy+fw that acts like a man-in-the-middle. It connects to the webs you want to see, and you connect to the proxy.

The outcome is that every dammed web that uses https gives me that f*ing warning with sec_error_unknown_issuer, cos of course the issuer is the proxy at my job, and the web domain does not match the issuer.

I have reduced the number of clicks required to add the exception to just 3 instead of 4 by editing the config file so it pre-loads the certificate when you click on the "add exception" link. But it's still a PITA.

I wouldn't mind if it was the default behavior but you could change the setting to a less paranoid one. But the fact there's no way to override this setting makes me angry. I want to be able to decide what do I want to trust or not.

Re:Seconded.

[wasabii]

This is a well known attack vendor: Make a web page that looks like a real bank site and trick people into visiting it. This prevents those sites from using HTTPS, as it makes entering them pretty hard and obvious. Mission solved. The collateral damage is admins who don't want to spend the time to properly set up their CAs. Nothing to see here, move along. As to subsidizing the industry, if you feel you can do a better job being a default CA, please contact the Mozilla foundation and prove it.

Re:Seconded.

[dasmoo]

You mean Verisign right? Since they own over 70% of the market. Oh and crazy frog. Seems like they have a monopoly on being annoying.

Re:Seconded.

[kiehlster]

I really don't support anyone that says paying through the roof for a trusted certificate is better than a self-signed certificate. With exception of business validation (which often comes as a joke) trusted certs are really no better than saying this person paid money for a brand name. It's like A&F jeans versus Walmart jeans.

The problem with FF3 is that it denies you access to websites with self-signed certificates until you explicitly install the certificate (as an "exception"). Odds are you're only visiting such a site once in your life, so installing the cert is by far a larger security risk than allowing the user to temporarily accept. This is up there with Vista's annoying security policy.

I can see more businesses paying for certificates from Verisign and the like, but it's a punch in the face of net neutrality when you see how this is hurting small business owners. They end up charging more to their customers and the customers leave for a cheaper big-box solution which kills little guy and eventually the local economy.

This also makes rush/trial/beta setups very annoying where the client has not shelled out their cash for a trusted cert. They want their website out there immediately but they've only paid for part of the package. If you give them a temporary self-signed cert, it gets put on the FF3 exceptions list and then it sits wasted on the machine once the trusted cert comes around. And you also have to waste time explaining to them how to install the cert.

You probably won't, but I'd support a net-wide protest against trusted certs and see what Mozilla does about their stupid policy after everyone spends half an hour of their day configuring exceptions in their browser. At least IE lets you temporarily accept, but I hate IE.

Re:Seconded.

[Bert64]

A self signed certificate is potentially more secure, since you haven't disclosed your private key to a third party...
A lot of certificate authorities will quite happily email your cert in the clear.

Re:Seconded.

[loopkin]

Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.
With SSL, the real 3 options you have are:
1- no ssl
2- "1 way authentication" SSL (usually only the server has a certificate: this ensures the client it is reaching the right server, but the server cannot trust the client)
3- mutual authentification SSL (aka "strong authentication": server and client have a certificate)

I think TFA is completely out of topic and blatantly ignorant: what would you think if SSH wouldn't warn you when the host you're trying to connect to has changed ?

The problem about SSL isn't to warn or not about self signed certificate (you HAVE to be warned about self-signed, and strongly, else anybody can easily get "average user's" bank account info, for instance). What is at stake is the lack of competition among public SSL Certification Authorities.

In general, don't try to solve a political/competition problem through technical/IT means, this won't work. Solve such problems through political/competition means (such as laws, regulators or open standards).

Re:Seconded.

[hedrick]

Driving is a privilege not a right.

This is unconstitutional statist propaganda. According to the Declaration of Independence and the Constitution, the people create a government and give it limited powers necessary to maintain order and do other important common tasks. Regulating driving is surely one of those tasks. I have no objection to requiring insurance. But the government does not confer privileges on its citizens. It's the other way around.

Re:Seconded.

[lukas84]

Is the proxy transparent or not?

If transparent:

Does the proxy generate a certificate on the fly with a matching hostname? If yes, just import the proxy root certificate.

If not:

Then you shouldn't have the problem you're experiencing. Could be something completely broken with the proxy.

Re:Seconded.

[IkeTo]

> If you run a self-signed certificate you still
> can get the man in the middle protection.

> There is no difference there, the only difference
> is that you don't have to pay for a certificate
> from a well-known root CA.

I assume the CA must somehow verify (no matter how minimally) that the one applying for the certificate has the name written on the certificate. This is the only difference. If you visit a site and it has self-signed certificate, you know you are talking to somebody, and that somebody can keep the message secret if he choose to. But you don't know who that somebody is. If you are talking to somebody who poisoned the DNS cache, masquerade the site you want to talk to, using a different self-signed certificate, you are absolutely ignorant about it: your experience will be exactly the same.

That is, unless you have some alternate way to verify that the certificate you see is coming from the one you want to speak to. If you can contact that guy by phone and take the time to have that guy read out loud the MD5 of the certificate and you carefully check every digit in it, no problem. But most people would rather have a CA do the job. Even if the CA are somewhat lousy.

Re:Seconded.

[LurkerXXX]

It's "attack vector", not vendor.

Re:Seconded.

[Migity]

Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption 3) SSL(3rd party signed): offers both

why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?

Well...no. 2 also offers authentication if you consider that you signed it yourself (and it's assumed that you trust yourself because, after all, if you don't trust yourself you can you trust)? However, it seems to make sense that since there are no 3rd parties involved why does there need to be a warning? Perhaps people should just install the public certificate of their site into their browser.

Re:Seconded.

[Bert64]

While I agree about the need for insurance, handing a market like this to private companies is a bad thing...
You leave companies with the ability to create huge profits from a captive market.

What we really need is non profit insurance, so those of us who don't make claims are not having to subsidise those who do. Despite being a young male with a powerful car, I have not made a single insurance claim (or caused anyone else to do so) despite driving heavily over the last 8 years. And yet i still have to pay ridiculous amounts for the insurance, to generate profits for the insurance companies and subsidise people who drive far more recklessly than me.

Re:Seconded.

[beyondkaoru]

number 2 is _not_ a significant improvement over number 1, simply because from a security standpoint, you have gained almost no security by encrypting if you don't know whether you're communicating between the person you want to or perhaps some fake site that looks similar, or a man-in-the-middle attack.

the only improvement is in the case of a purely-passive eavesdropper -- not much of an improvement at all. For eavesdropping purposes, if you can passively eavesdrop, you can probably actively eavesdrop and interrupt or manipulate the connections, because you've got physical access to some wires or routers or just have a laptop running airsnort software in a cafe.

furthermore, having people get used to using self-signed certificates is bad, because it lends man-in-the-middle attacks more apparent legitimacy. so of course eve couldn't fake the signature of the real key, but if any signature will do...

i don't like the existing certificate authorities ($50-$100 per year for a row in a table? sheesh!) much either, but they're needed to have trust between people who have not met before.

Re:Seconded.

[KritonK]

* Unprofessional webhosters (good riddance)

The "unprofessional web hoster", that we use at work here in Greece, offers a full spectrum of services (just about anything you can think of, including personal service--you have a problem, you call them and they fix it while you talk, not some person at a help desk who may or may not forward your request) at a rock bottom price. Their competitors have much higher prices and will charge you for anything beyond the basic web hosting package. You want more than the default few MBytes? That's extra. You want a database or php? That's extra, too. You want to park a domain? You need to buy the domain parking package. You want it now? Sorry, it's going to take 24 hours!

If the cost for all this is that we have to connect to the web site's control panel (which the other providers don't, well, provide), using a self-signed certificate, it's good riddance to those other providers!

Re:Seconded.

[Hal_Porter]

Thats what they said about IE6

I think comparisons to IE6 count as Godwinning the thread.

Re:Seconded.

[ftobin]

I think you point out clearly the point. Ideally, every webserver should be providing SSL access, but it's certainly not necessary for every one of them to buy a certificate. Most of the time, an ssh-style system of simply accepting the first presented certificate and caching the server's public key is sufficient.

I would suggest that a browser not display the warning you are showing always, but only if the user is being prompted for data. That, or we need to make the three levels of security more clear to the end user. However, I'm not a big fan of putting more requirements on the user.

In my opinion, the problem is the strict hierarchical nature of the SSL certificate system. It needs to make use of existing information contained in social networks. I think some of the information Google holds could be of great use here.

Re:Seconded.

[Antibozo]

A self signed certificate is potentially more secure, since you haven't disclosed your private key to a third party...

Sigh. You don't disclose your private key to a third party when you request a certificate. You provide the public key, and the third party signs that with the private key corresponding to a CA certificate. Neither party reveals a private key to the other, or to anyone else.

Re:Seconded.

[MrSnivvel]

Driving is a privilege not a right. Unless you have the money to cover any damages you may cause, it is absolutely necessary to have insurance. The cost of barebones liability coverage is not that high assuming you have a relatively clean record and if not, you probably shouldn't be driving. It seems that today the idea of personal responsibility is falling out of favor.

Actually you're both correct and incorrect. Most people are not driving, they're traveling. And that activity is codified in common law as a right, movement by people by any means. Those who make money from either hauling freight or passengers are driving, and that is the legal definition of transportation as noted in "Black's Law Dictionary".

If you desire further examples, check out your state's (I assume you are in the US since your first statement is a commonly stated incorrect mantra) transportation statues/codes/laws and use a legal dictionary for any term not explicitly defined in such.

I responding to your post because that outright lie needs to be squelched.

Re:Seconded.

[hvm2hvm]

"It seems that today the idea of personal responsibility is falling out of favor."
Exactly but it's the other way around. If they would really let us be responsible for our own actions they would let us choose wether we want to pay for insurance or not. Being obligated to buy it means they don't trust you in the first place.

Just like the regulations for 'safe-driving': They should just let people do whatever they wish. If you can talk on your cellphone while driving OK, if you create an accident you should suffer the consequences and that's all (the problem is with the people that escape punishment because of the fucked up judicial system).

Re:Seconded.

[jrp2]

"If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different. Instead they interrupt the browsing experience with a very unfriendly message that non-tech people will not have a chance of understanding."

I agree. I think it is appropriate to warn the user, and it should be made clear this is unnacceptable on a site where banking or credit card info is involved. But completely alarming the user is overboard.

I use self-signed certs every now and again where I am trying to protect passwords, but there is not a big security risk.

That said, a godaddy cert is pretty darn cheap these days, so I do it fairly rarely now.

Re:Seconded.

[dasmoo]

I use a shitty $10 certificate brand for my servers, however the dedicated server customers have no CA signed certificate, because everyone is tight. They're tight for a reason, as it's tough to compete in the Australian market. The company I work for has a lot of dedicated servers, and I'm not going back to update them all to a self signed certificate with the common name of *. It's too much hassle. I'd rather just use FF2 or Safari until someone creates a version of FF3 without this bullshit in it. It's just not worth my time. They should have an option to disable this with about 5 warning signs: Warning this is dangerous! Only enable if you know what you're doing! GIANT BAT BALLS WILL FLY OUT OF THE SKY AND INTO YOUR MOUTH!

This is also wasting IP addresses.

Re:Seconded.

[Anonymous Coward]

"But the government does not confer privileges on its citizens. It's the other way around."

They teach you this but it doesn't work that way. People of the USA have an illusion of freedom

Re:Seconded.

[Anonymous Coward]

SSL detecting a man-in-the-middle is a feature, not a bug.

Re:Seconded.

[funaho]

Hmm now Microsoft, they're a well-known attack vendor. :-)

Re:Seconded.

[undercanopy]

No: if you train your users to ignore "[this certificate isn't signed by a know authority]" warnings, then you makes them substantially MORE vulnerable to man-in-the-middle attacks and, indeed, increases their susceptibility to phishing across the board.

As a web admin you will of course also have to maintain the certificate store, but that may be very easy if you only have a handful of clients. And if you have a handful of clients you may install the root certificate in a controlled situation on the clients, so not even there you have a big problem with insecurity.

didn't you just defeat your own protest to this 'feature?' If you're going to install the cert/root on your clients, then they won't encounter this message, and there's no problem.

Where i DO see a problem is making it very very cheap and and easy for people to register believable certs for

cittibank.com

citibnak.com

citybank.com

citibanc.com

Cost of entry keeps attacks like these targeted, removing that would open things up immeasurably... or do you think the phishing problem is overblown and just a commercial stunt too?

Re:Seconded.

[robertss]

And certificate authorities email your certificate "in the clear" because that is exactly what you do when you put it on your site. It is called a "public" key for a reason. It can't be used without the private key so it doesn't matter if everyone in the world has it.

Re:Seconded.

[MrNaz]

How about
* All sites for whom authenticity is a non-issue and data security is the only concern?

This policy adds an unnecessary and arbitrary cost to sites for whom the risk profile does not match the protections offered by authoritative CAs, forcing them to buy a product that they do not need.

Oh, and don't bother retorting that "they're not forced", let me preemptively shoot down that silliness right now.

Re:Seconded.

[Talennor]

Problem is that "2" doesn't happen.

Think of this example: I "encrypt" some confidential data. However, I've encrypted it so that I don't know who will be able to decrypt it. Does that make any sense?

Why was I encrypting it? So a criminal couldn't steal my credit card number? What if I had just encrypted it directly to that criminal? Oops! This encryption didn't help me at all.

If I want to send someone secured data I first have to define clearly and be sure of who I am sending that confidential data to.

With a little thinking you'll find that not authenticating the end users of an encrypted channel is just moving some bits around and is only as secure as your network. Meaning you might as well be sending clear text and save some processor cycles.

Now you can accept self-signed certificates, but you had better have a different way of authenticating the cert than the rest of us use. An example of this would be something from an internal corporate network.

Re:Seconded.

[nmx]

If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different.

Yes, it would be completely different. Joe User would ignore it.

Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption

I don't think you understand how SSL works. Guaranteeing data confidentiality without a valid certificate is impossible.

3) SSL(3rd party signed): offers both

why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?

There is no such thing as no.2. In fact, it's worse than no encryption at all, because even someone as (seemingly) technically minded as yourself is fooled into thinking that it exists. Without certificate validation you can be subject to a man-in-the-middle attack without being aware of it. You might as well be using ROT13. Sure, it's "encryption," but what's the point?

Re:Seconded.

[galoise]

you are missing two critical points:

1.- saying that it is a privilege is not the same as saying that the state concedes privileges, as this is actually tautological. Given the state is an organization built by society to ensure some form of regulation that makes it possible to enjoy certain privileges to all, the existence of the state is a material necessity to the existence of those privileges, and saying that the state is the origin of those privileges is the same as saying that some tool is the origin of the product, when it's the other way around: the tool exists only in the extent in which it is useful to getting the product done. The same thing happens with the state: it exists solely to make the availability of privileges to all.

2.- you have to take into account the rather obvious material considerations that render all this libertarian rants senseless. To enjoy driving, you need a lot of social resources that enable you to do all things related to driving, from getting a car, to using roads, etc. to provide for this resources, we the people have decided to give some other authority to accomplish that which we need to "drive" and that we can not accomplish by ourselves, e g the state. Does this materiallity that makes the state necessary for the enjoying of some (you would say natural, i'm sure) privileges make the state the _origin_ of this privileges?

you have three choices here: 1.- no 2.- yes and the correct one: who fucking cares? this disctintion between the genealogical role of the state and the material role of the state is just a pile of idealistic, liberal (in the proper sense, go look it up), primitive and naive crap.

both points are very similar, but they are two distinct points, nevertheless.

(and don't even get me started on the idiocy of 'granting' privileges to the state. that's like saying that corporate personas have rights!)

---
"america: the only place in the world where 'liberal' means statist, and 'libertarian' means letting the poor die in the streets".

Re:Seconded.

[Matthieu Araman]

You can give your cert to as many people as you like.
You should NOT give your private key.
Public and private key works together and there's no way to find a private ley from a public key and the reverse (If you find a method, you'll break all the crypto !)

Some CA can generate the private ley for you but it's not a good idea.

Best way is :

- generate a private/public key on your server
- generate a certificate demand (signed with your private key)
- send the certificate to the ca (you can use a safe way as you already know the ca cert)
- the ca check this is you
- the ca sign your certificate demand with it's private key (and I think your public key)
- the ca send you the certificate
- you install the certificate (only you can decrypt with your private key)

Re:Seconded.

[Mistshadow2k4]

Except that there is nothing compulsory about ff. You are free to trust any certificate you want, the browser merely warns you that it could be a bad idea to do so.

I can confirm that myself too. I ran into that yesterday when trying to visit a site that came up as a search result. It definitely had the option for me to click to get me to the site. It just warned me about the site's certificate, that's all.

Re:Seconded.

[galoise]

but i'm affraid that you are making two different points as it were one:

1.- profit
2.- distributive risk assesment (to call it somehow, IANAIA*)

and your gripe is with neither: your problem is that the insurance company does not have a good enough method to distribute the amount of risk to you, and in your particular case, you are personally less riskier than your category. since you are below average than your group, you're SOL. but this is not a gripe with profit or risk subsidies, it's a gripe with the bluntness of the statistical system used to build tiers of risk.

neither profit nor distributive risk assessment have anything to do (necessarily) with crappy calculations.

but i agree that we should have non-profit insurance, but for other reasons.

* insurance agent?

Re:Seconded.

[Mistshadow2k4]

Not that high? Either you have waaaay too much money, represent an auto insurance company or you live in another world. If you're young and don't have kids, the cost of insurance is going to be well over $100 a month, no matter how clean your record is. My husband and I are both over 35 -- he's 46 actually -- but since we don't have kids, the lady across the street with a DUI on her record pays no more than we do. And the excuses they come up with to charge you more! You will pay more if your car is red or purple, did you know that? Crap like that is just a scam, legal or not.

Re:Seconded.

[MrNaz]

I tihnrd this complaint.

CAs are total ripoffs. Either we only allow trustworth CAs in the list, or we allow them all. Here are the results:

a) A small, highly cliqueish cabal of "trusted" operators who, by necessity, must prevent new entrants into the market for CA services, lest the web of trust be broken. RESULT: Webmasters are all screwed by the ridiculous prices for certs that will inevitably result from the monopoly or cartel, ultimately meaning fewer web sites can afford security at all and either stop operating or just don't use security.
b) A highly diffuse CA industry that has no trust anyway, thus serving no purpose but to annoy web masters and users who must register with some two bit shitty company for a perfunctory cert that they could sign themselves.

Both options suck if you ask me.

Down with CAs. They are not necessary. Customers should just learn not to buy from www.amaz0n.com

Why is there a need for a whole business around this? Where's the whole industry preventing me from walking into a dark warehouse in a nasty part of town with a large sheet of carboard and a target logo drawn on it in crayon? It's called common sense. If you're going somewhere to spend money, exercise caution.

Caveat emptor. Just because it's in Latin doesn't mean it's irrelevant in the modern world.

Re:Seconded.

[hummassa]

I disagree that the message is one "that non-tech people will not have a chance of understanding." The message says: "The certificate can't be trusted because it's self-signed." Things do not get much simpler than that. Remember that self-signed certificates are the basis for man-in-the-middle attacks in https:/// sites.

Won't anyone think of the children?? :-)

Re:Seconded.

[bconway]

It sounds like Mozilla did you a favor by highlighting your egregiously broken firewall.

Re:Seconded.

[Endo13]

Just like the regulations for 'safe-driving': They should just let people do whatever they wish. If you can talk on your cellphone while driving OK, if you create an accident you should suffer the consequences and that's all (the problem is with the people that escape punishment because of the fucked up judicial system).

Wow. Just wow. Do you really not see the huge gaping flaw in that argument?? There's a reason why operating a motor vehicle on a public thoroughfare has to be considered a privilege, not a right. So let's say I'm talking on my cellphone while driving. Let's also say that I'm not a rich guy. In this little story, I have about $20 in my pocket, none in my bank account, no assets to speak of, and I live from paycheck to paycheck. And since I'm in these circumstances, my car is also not exactly in top shape. So I'm driving along talking on my cellphone, don't see the red light, and slam into the passenger side of your car as you're driving through the intersection in front of me. Bam, your wife/husband/significant other just died, you just landed in the hospital for 3 months, and all that happens to me is I get sent to jail for at most a few years. Or more likely, I died in the accident as well and you don't even get that much. Worst part is, I also didn't have insurance. My policy lapsed because I couldn't afford it.

When you're operating equipment that has a huge potential to be fatal to other persons, it absolutely has to be a privilege instead of a right. Everyone has the right to use the public road, no one has the right to operate a death machine on it.

Or perhaps I should also exercise my right to bear arms and start firing high-powered rifle shots randomly around the city? I'm sure there's no chance at all I'll ever hit someone.

Re:Seconded.

[ZorinLynx]

That proxy at your job is misconfigured.

SSL traffic needs to be passed untouched from the remote server to the client workstation. You can proxy SSL, but the bytes CANNOT be changed.

By accepting that incorrect certificate, you are opening your SSL connection to all sorts of potential attacks. The proxy server could be collecting usernames and passwords, for instance, or modifying pages. Even if you trust your employer (which is usually a bad idea), the proxy might be compromised.

I'd suggest talking to your IT department about having this fixed. It's a serious security issue.

Re:Seconded.

[Anonymous Coward]

do you fully understand the sheer stupidity of what you just said?

do you realize that the point of regulation is not to instill fear in people up to the point that they will choose freely not to drunk drive, but instead, giving the state the power to remove those drunken drivers from the road?

do you realize that the point is not punishment for skipping some rule, but *avoiding the murdering of little girls*?

god damn it. you Americans are really fucked up in the head.

Re:Seconded.

[great_snoopy]

Yes, but for a public user there is no difference between your self signed certificate and Harry Hacker's self signed certificate. If your application is to be used just by a finite number of user on which computers you took care of also installing your self signed certificate, then this is ok. But for a publicly accessible site, like your webmail, or your bank's internet banking application, you need a CA signed certificate, otherwise a certificate self signed by the bank looks exactly like one that a middle man can create on himself to impersonate the bank.

Re:Seconded.

[lukas84]

You can't have data security without data authenticity.

Re:Seconded.

[tha_mink]

RESULT: Webmasters are all screwed by the ridiculous prices for certs that will inevitably result from the monopoly or cartel, ultimately meaning fewer web sites can afford security at all and either stop operating or just don't use security.

$14.99 is a "ridiculous" price? Really?

They are not necessary. Customers should just learn not to buy from www.amaz0n.com

While I agree about common sense, encrypted information is kinda nice I think.

Re:Seconded.

[JerkBoB]

...like compulsory auto insurance subsidizes the auto insurance industry.

Boo Hoo. OK, how about this: Driving is restricted to those individuals who A. have auto insurance or B. have $100,000 in escrow to cover medical costs for the mother and children they plow into while fiddling with the radio.

There ya go... Now you can stick it to those stupid insurance companies like the rebel you are.

Re:Seconded.

[MrNaz]

If you look up, you will see my point hanging from the ceiling above you. Take it down, and have a second attempt at not missing it.

CAs prevent "phishing" attacks, and other attacks where a site impersonates another site. I'm saying that this risk profile does not apply to everyone, and forcing those to whom it does not apply is unfair.

And that's assuming that a CA system is even effective at this risk profile, which I also contest.

Re:Seconded.

[SanityInAnarchy]

If you run a self-signed certificate you still can get the man in the middle protection.

That is true, if and only if you have your users verify the certificate before accepting it. Which means you have to do things like, have them check the fingerprint of the certificate with you over the phone, or help them install a certificate authority, again verifying the CA's cert with a fingerprint, probably over the phone.

If your users are that savvy, they shouldn't be so frightened by the Firefox warning, and/or you should be able to walk them through disabling it.

And if you have a handful of clients you may install the root certificate in a controlled situation on the clients

In which case, Firefox 3 won't give you that warning, and this is a non-issue.

The "insecurity" of not using a well-known CA is only a commercial stunt.

The fact that you can say this tells me that you have no idea how SSL works.

Sigh...

Let's walk through this one more time, shall we?

  - Your user types https://yoursite.com/
  - A man in the middle intercepts, and sends back his own self-signed certificate, made out to look like yours.
  - Your user clicks "Accept", because you've convinced him that the warning is only a "commercial stunt."
  - A secure session is opened between your user and the man in the middle.
  - The man in the middle intercepts and decrypts all traffic, then opens a session to you, using your real self-signed certificate, this time -- and forwards it along.
  - You're now significantly less secure than plaintext HTTP, as the user will now get a nasty warning when the MITM stops intercepting their traffic.
  - Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."

Re:Seconded.

[MrNaz]

How long do you think the price will stay at $14.99 when there is an industry that knows that there can be no further entrants?

One round of consolidation will give you a small cartel of companies that will take turns raising the price, just as any other high barrier to entry industry (oil is a good example, as is banking in many countries such as Australia).

Re:Seconded.

[DavidTC]

Except, honestly, people are so damn stupid that most 'attacks' are just done without any SSL at all.

Re:Seconded.

[swilver]

Let's assume for a second that every website in existance used self-signed certificates.

Let's further assume Firefox stores them automatically and keeps track of them for you.

Let's also assume Firefox will give you a big red warning when one of these self-signed certificates suddenly changes.

How do you propose to start monitoring this user's internet without him/her knowing about it? Keep in mind that your man-in-the-middle attack will immediately cause several big red warnings to pop up because suddenly every website you visit has had their certificate changed (coincidence?).

Man-in-the-middle attacks are something to be wary off, but assuming you aren't ALREADY being monitored, even self-signed certificates will give you instant warning when they DO start monitoring you.

Re:Seconded.

[Anonymous Coward]

Because no.2 only provides encryption to the server that is serving that page...which could be any server that can con you into thinking that it is the correct server.

Let's say that Alice has an account at Matilda's bank. Mallory wants Alice's money. There are several attack vectors he could use.

1) Mallory spams Alice with a phishing email that convinces Alice to login to www.mati1dasbank.com (Read carefully!) to update her information. www.mati1dasbank.com resolves to Mallory's website that contains a convincing spoof of www.matildasbank.com, but with the login scripts replaced with scripts that capture and record usernames and passwords.

2) Mallory determines that Alice's ISP Ivan isn't very prompt with DNS patches and hasn't patched the recent caching-resolver vulnerability. He exploits that and convinces Ivan's DNS system that www.matildasbank.com really resolves to Mallory's webserver IP address.

Both of these vectors result in Alice talking to Mallory. If Mallory encrypts this session with a self-signed cert, Alice gets a warning and has an opportunity to detect and prevent the attack. If Mallory wants to encrypts this session with a CA provided cert (to prevent that detection) then he has to find a way to buy a certificate in an untraceable way which is non-trivial.

An encrypted conversation with Mallory is no better than an unencrypted conversation with Mallory.

Re:Seconded.

[SanityInAnarchy]

I really don't support anyone that says paying through the roof for a trusted certificate is better than a self-signed certificate.

$10/year is not "through the roof" by any stretch.

This also makes rush/trial/beta setups very annoying

It's possible to route a beta to example.com/beta, but I realize most developers aren't competent enough to do that. (Relative URLs, people!)

So, next best thing, why not beta.example.com? Or staging.example.com? Or tell them not to put anything secure into it, and disable the SSL.

This isn't rocket surgery, people.

Re:Seconded.

[DavidTC]

Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.

Um, dude. Perhaps you should pay a little more attention. SSH operates via '2'. There's not even such a thing as a signed SSH key. Granted, you can use PPK to keep someone from forwarding the connection, but good luck getting the PPK on without logging in with the password once.

With SSH, the trick is to make the first connection over an internet connection that you trust, and it stores the fingerprint for future reference.

SSL sites that didn't need authentication, that just wanted password protection against cleartext sniffing on login, could trivially operate the same way.

Like it or not, there actually is a very wide range of websites that, right now, use no encryption at all, but would use SSL if it was free, and there is absolutely no way that could make them more insecure. Likewise, there are a variety of circumstances where it is easy to sniff on a user but difficult to intercept and replace their transmission.

Almost all cars can be broken into in about 60 seconds, using a slim jim on the door. However, people still lock their doors. Basically, you're arguing that it shouldn't be possible to lock a car unless it has a full-fledged car alarm, which is a rather...stupid...argument.

Re:Seconded.

[lukas84]

If you do not care if someone can get your data, you can use plain HTTP.

If you do care, you need protection against MITM attacks - which self signed certificates do not provide.

Re:Seconded.

[Waffle Iron]

If they would really let us be responsible for our own actions they would let us choose wether we want to pay for insurance or not.

Uusually, that's already the way it works. If you post a bond with the state in the amount of the minimum liability requirement, then you don't have to buy insurance. So you really have nothing to complain about unless you plan on causing damages and then skipping out on paying for them.

Re:Seconded.

[UnderCoverPenguin]

$14.99 is a "ridiculous" price? Really?

Does FF trust it? If so, maybe FF should not be trusted.

I have helped some of my clients get SSL certs. Even the $100 certs seemed way too easy to get.

Disclaimer: Web stuff is a hobby for me.

Re:Seconded.

[Tacvek]

MITM attacks need not impact more than one site.

It is completely possible for the MITM to just forward all packets including encrypted packets on to the intended site. The MITM would only stop the packets and pretend to be just that site. The MITM concern is really more about the this thrid party having a site that looks exactly like your bank's website, that asks for your password, and then returns an error indicating that the site is down for maintenance.

Monitoring *all* SSL connections is not generally the goal.

Re:Seconded.

[Anonymous Coward]

You've drawn in your conclusion a rather false and incomplete metaphor.

Re:Seconded.

[dayton967]

One issue that people seem to realize is that with a self-signed certificate is the whole man in the middle attack, it really doesn't add a great deal of security. With the DNS cache poisioning attacks, Gratitious ARP, an attacker can actually use this to his benefit. If someone is always adding the same certificate, they will just add the certificate without reviewing it. At one of my pervious companies, the mail system was available via web, and some one got personal information because the mail admins refused to spend the money on a certificate and people became so accustomed to allowing certificates because of them, that when a change occured, people just thought it was a change in certificate and they had access to the information. If you really want to secure it, don't do self-signed, build out a local PKI infrastructure that signs, and add that certificate to your browser. You have more control even, but again I wouldn't use it for external clients. As for the author, it's not Firefox alone IE7 does the same thing. The one solution for you people who want it free, is to encourage the browsers to support CACert(www.cacert.org), which uses a web of trust infrastucture

Re:Seconded.

[j79zlr]

$100 a month is too expensive?! So what happens when these people who can't afford $100 a month hit a building and cause $50,000 worth of damage? Or what about hitting another car with insurance. Now the responsible person ends up subsidizing the irresponsible.

I am 28 with a clean driving record. Full coverage insurance on my new(ish) car is $1,000 a year. Minimum liability insurance is not that expensive.

Re:Seconded.

[sirambrose]

I don't think that the school wants to "fix" the issue. At the University of Maryland, only a few sites like the one for registration and grades use a regular certificate. They run a CA that issues certificates for all the other servers. Assuming that they probably have several hundred web servers, using a private CA saves them a good bit of money.

The servers using the private CA have a link to the key file and instructions for installing it. Since the students and faculty will be using these sites for several years and they only need to install the certificate once, I think that this is a reasonable arrangement. I certainly wouldn't want them to raise fees to cover the cost of buying certificates.

Re:Seconded.

[Lennie]

I don't agree, they have a SSL-policy to only include CA root-certificates of organisations that have had their procedures, hardware, software and organisation properly audited.

That's not really very strange. Because the browser vendor has to trust the CA to do the right thing.

If you look at CA-cert for example, they are working on making this situation better for everyone else by getting them selfs audited.

These things take time, lots of time.
_

If on the other hand you want to create your own certs, create your own organisation-root-CA. So you can import the public-key of that CA all over your organisation.

Re:Seconded.

[DavidTC]

God, everyone else is so stupid about car insurance. At least you reached the halfway point with 'non-profit', but you need to take it another step:

Have the state government do it. You are required to pay into a fund every year you drive. (Aka, car tags just went up by 1000%.) If your car is damaged in an auto accident that isn't your fault, the government pays for it.

And we also increase the cost of fines for such accidents, by ten times or more, payable over a few years...aka, the bad driver's insurance premium went up.

The current system is sheer nonsense. The state already collects money from drivers. The state already finds fault in car accidents and levees fines. All it needs to do is increase both of those and direct some of the money to victims of accidents.

And instead of worrying about the 'likelihood' of an accident, something that is unfair and discriminatory towards different ages, genders, and races, it will be fining people for actual crimes committed.

Independent insurance companies, of course, could still provide comprehensive coverage, for damage caused by drivers to their own vehicles or damages incurred while not driving. (Hail damage and whatnot.) Heck, they could even insure against the state-levied fines if they want.

'Mandatory insurance that everyone has that is provided by private industry' is possibly the stupidest rip-off-ist idea that has even been invented.

(Someone here is going to mention 'but what about the cost of health care'. Yeah, guess who I think should be providing that.)

Re:Seconded.

[Anonymous Coward]

The cost of barebones liability coverage is not that high assuming you have a relatively clean record

As a 20-year old male new driver with a completely clean record I can tell you that this statement is not factually accurate, unless you think paying $1,000 per year for barebones insurance when driving a Ford Ka (60 horsepower) is cheap. Personally I consider that not cheap.

Of course, I also don't have the cash on hand to self-insure, which is perhaps your point.

Re:Seconded.

[DavidTC]

Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."

I believe it is you who trained them, by providing that warning.

The rest of us just want a trivial amount of protection for our fucking BB login, and we'd be happy if the browser didn't even mention it was SSL at all.

You're really not grasping this, are you? People complaining don't want to run damn bank sites or storefronts or anything you'd need signed SSL for.

We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords. Things like slashdot. Half the stuff is on shared IPs, so we couldn't even get a real cert for it, because we need a * one.

The joke is, for the longest time, browsers have provided visual clues that a site is SSL. Why are those clues not enough? Why not simply remove those clues for self-signed sites? Why popup bigass warnings?

The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all. And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.

Re:Seconded.

[profplump]

$14.99 is not a ridiculous price for one website, but when try the pricing on wildcard certificates for *.mydomain.com. And then try that pricing on when you are just trying to protect your personal data and not selling anything.

Setting up your own CA takes only a couple of minutes and lets you provide both encryption and (uni-or-bidirectional) authentication just like other CAs for any domain you like at no cost. The only expense is having to manually import the CA cert on machines where you want authentication and not just encryption.

Re:Seconded.

[rs79]

"Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks."

Yeah I used to think that. Till I looked at certs long and hard. If you can't figure out how to let a client prove he's taking to you given the information he has available maybe you don't need to be thinking about commercial grade websites that much.

Having said that this "Warning" in FF is utterly ratarded and has to go. This is not negotialble.

If you think SSL as it's imnplemented is really that safe you should try simulating the ssl handshake with low level ssl tools so you too can see the multiple errors in almost nearly evry cert that the browesers just plain ignore so at least things like paypal actually work.

SSL may be silly but it's all we really have and whatever kiddie put this warning in spent too much time in Redmond. All I really want is a bar that gives me a security threshold - a red line or a yellow line or a green line for the three levels of security. That'll be fine thanks. And stop terrifying my customers. They're smart enough to know what's going on and I'm sick of their giggling about this FF feature.

Sorry to be in a bad mood but I have some (non ssl) web pages that work in Opera and IE and are correct but do not work in FF now. This does not help.

Also, I really still don't get why aybody would use firefox as long as Opera is as good as it is. All FF does is just plays catch-up. Incredible.

Re:Seconded.

[profplump]

I don't know where your hackers sit, but most of mine are not in a position to bidirectionally intercept and re-transmit IP packets. Are there some people in the chain that could do that -- certainly: anyone on the same LAN segment at either end, and a handful of routers in the middle -- but that's not really a large number of potential hackers.

I agree authentication is a good thing, but it's stilly to pretend the a MiM attack is easy to implement.

Re:Seconded.

[profplump]

The point is you'd have to actually implement a MiM attack, not just record the data and later mine it for useful information. You'd have to be in a position to bi-directionally intercept and retransmit IP packets along the path of the data, and have a machine in-place that can either deny transmission of the original packet or be fast enough to produce the expected reply before the original arrives.

I agree that it's important not to mistake encryption for authentication, but they are *both* useful, even individually.

Re:Seconded.

[dwpro]

A scheme where I am legally required to pay someone else to insure my and other driver's driving errors hardly seems like a good example of personal responsibility, and so unless that last line is tongue in cheek I don't know what you mean. I agree with the rest of your post though.

Re:Seconded.

[profplump]

There's a reason why operating a motor vehicle on a public thoroughfare has to be considered a privilege, not a right.

Yeah, because people like you think we should be proactively protected by the government.

Re:Seconded.

[Nursie]

"Customers should just learn not to buy from www.amaz0n.com"

And without a trusted certificate from a third party, they'll have no way of knowing if they're talking to "amaz0n.com" when their browser says "amazon.com", after a DNS poisoning.

I agree that there are both too many CAs and the level of verification the perform is likely not enough, but getting rid of them is not the answer to everyone's problems.

Re:Seconded.

[Anonymous Coward]

That assumption is incorrect. Hell, Verisign were hacked and CA's changed.

Now a MITM attack will only work if the MITM is there poisoning your system at the very instant you are swapping credentials.

So really only an issue with your ISP or government snooping.

Re:Seconded.

[Deanalator]

Insurance is a scam. Insurance companies scare consumers, telling them that the money will pay off in the long run, but if it ever did, insurance companies would be out of business.

Re:Seconded.

[DavidTC]

Well, yes. A better metaphor is that car companies shouldn't be allowed to sell cars with cheap car alarms that can, in theory, be disabled in less than five minutes, and should have to either provide much more expensive ones...or they sell it with no alarms at all, like almost all cars. If they sell one with a car alarm that can be disabled in a short amount of time, they need to get the customer to do a lot of paperwork.

There's an arguable position that all car should have to come with car alarms, ones to a certain level, and that customers should be warned if they don't.

There's not really a reasonable arguments that says they can come without a car alarm, with no warning at all, but if you provide a cheap-ass one for a tiny bit more security, you have to give them all sorts of waivers to sign.

Firefox, and IE, right now, pop up enough warnings that make it seem that a web surf allowing an self-signed cert is the most dangerous thing you can do....which results in people not using any encryption at all for quite a lot of stuff. (Like, oh, the login to slashdot.)

People in favor of this talk about a 'false sense of security'. Ha. How about the false sense of insecurity browsers provide? Simply a single message 'This web site uses encryption that cannot be authenticated. Be aware it is no more secure than a standard web page.' would be more than enough. (Or, even better, no warning at all, and simply an unlocked 'lock' icon.)

Re:Seconded.

[tha_mink]

How long do you think the price will stay at $14.99 when there is an industry that knows that there can be no further entrants?

What? I think the price will be under $10 and stay there shortly.

One round of consolidation will give you a small cartel of companies that will take turns raising the price, just as any other high barrier to entry industry (oil is a good example, as is banking in many countries such as Australia).

Oil is a terrible example as the price of that is set by the open market and commodity traders.

Re:Seconded.

[Endo13]

Yeah, because people like you think we should be proactively protected by the government.

Yes, I do believe that human life is something that should be proactively protected by the government.

I consider your right to life as being far more important than my own right to travel.

Re:Seconded.

[Whatanut]

You're making the assumption that "self-signed" means something to the average user. It means something to you as a technical user, but it doesn't mean diddly to grandma. She'd be lucky to understand the difference between http:/// and https://./ The furthest they're likely to get is seeing the little lock icon and thinking "I'm safe!!" The warning that comes up in firefox currently is a big sign screaming "RUN AWAY!! FIRE FIRE!!" for the average non-technical user.

Re:Seconded.

[makomk]

There are three factors making purely passive eavesdropping easier than a MITM attack: (1) it requires less computing power, (2) there's no way the person being eavesdropped on can notice, whereas with a MITM attack on SSL there's a risk that one of the people is actually paying attention to the certificate and will spot the attack and (3) a MITM attack affects normal network activity, so there's a risk that an administrator will notice something's wrong.

Re:Seconded.

[DavidTC]

Does the proxy generate a certificate on the fly with a matching hostname? If yes, just import the proxy root certificate.

Wouldn't that, in fact, be incredibly dangerous?

Re:Seconded.

[tha_mink]

$14.99 is not a ridiculous price for one website, but when try the pricing on wildcard certificates for *.mydomain.com.

Ok. That'd be $199/yr. I don't consider that ridiculous for unlimited sub domains.

Re:Seconded.

[infolib]

having encryption without authentication is pointless, because man in the middle attacks are too easy to set up

I strongly disagree. Maybe my surfing passes through Sweden, China or USA?

If I surf encrypted sites there's quite a good chance they won't log more than some traffic from that IP to mine. Unencrypted they'll get the whole URL and cookie history. Yes, they could man-in-the-middle me, but that's likely to remain an exception for some time. For now,"encrypt first, sign later" sounds like moving in the right direction to me.

Re:Seconded.

[maglo]

Bear in mind the three levels of security: 1) no-ssl: offers neither encryption nor authenication 2) SSL(self-signed): offers encryption 3) SSL(3rd party signed): offers both

why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?

You cannot have encryption without authentication. Encryption is defined as the confidential transfer of information only to the intended parties. If you cannot be sure that you are exchanging session encryption keys with the intended party, you might just as well be talking to the man-in-ze-middle.

Re:Seconded.

[Deanalator]

You should be able to add a trusted root to all the browsers in the company, and have the proxy generate new certs signed with your internal root cert every time someone visits a new website.

The error message is because you are doing it wrong.

Re:Seconded.

[lukas84]

No, why? It's his workplace - if he can't trust the proxy, he has other problems.

But yes, surfing on job sites is not a good idea with such a setup ;)

Re:Seconded.

[Achromatic1978]

Or perhaps I should also exercise my right to bear arms and start firing high-powered rifle shots randomly around the city? I'm sure there's no chance at all I'll ever hit someone.

I know. You could use the high powered rifle to shoot drivers you deem to be a risk to you, and move the "proactive protection" the other guy is whining about from the government to you!

Re:Seconded.

[Anonymous Coward]

It's hardly a "mere" warning; it's a gigantic stop sign.
Give me a break. If they didn't do it, some idiot would get flamed because he didn't see the big stop sign, bitch about it on some blog and nobody would care.
This gigantic stop sign is called "anti-idiocy" and I agree to it. You clearly described what SSL is, but I'm sure that Joe has no idea, but he was probably told that "SSL means you're completely safe" which isn't true.

Re:Seconded.

[roystgnr]

They should just let people do whatever they wish. If you can talk on your cellphone while driving OK, if you create an accident you should suffer the consequences and that's all

And what kind of crime is "attempted murder", anyway? Do they give a Nobel Prize for "Attempted Chemistry"?

Re:Seconded.

[nmx]

I agree that it's important not to mistake encryption for authentication, but they are *both* useful, even individually.

They are both useful individually, that's true. However, to use encryption, you have to share a key. If you haven't negotiated that key in advance, your only alternative is to authenticate the peer using a public key system like a CA. So with SSL you MUST authenticate the peer, or accept the risk that you really have no idea who you're talking to or who's listening in. Given that most people have no idea how SSL works, I don't think the average user is informed enough to accept that risk.

Re:Seconded.

[MrNaz]

Which CA do you use for your SSH sessions?

Re:Seconded.

[lukas84]

RDP authenticates through SSL or Kerberos :P

SSH is pretty much the same as self signed certificates, but it's user base is entirely different. We have a few internal machines with a *nix on them, and i deploy their keys through Group Policy to all clients (using putty as an SSH client).

I suppose you can do the same in a *nix only environments by automating known_hosts deployment into all user profiles.

Re:Seconded.

[SanityInAnarchy]

We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords.

I'd call $10/year for a real cert pretty damned cheap. Maybe I'm off by a factor of two -- but $20/year is still pretty damned cheap. What do you pay for hosting?

There are actually a few ways to avoid sending cleartext passwords, even over an untrusted channel, which are reasonably immune to MITM attacks -- at least, on the password itself, assuming no one did a MITM while you were creating a login.

There aren't going to be the browser clues, but an extension would solve that.

If you really can't afford $10/year, that implies you don't have a job, which implies you have a lot of time on your hands -- so you should be able to figure this out, and write the extension if needed. If you don't have that kind of time, you probably do have that kind of money. How much does Slashdot make?

Half the stuff is on shared IPs, so we couldn't even get a real cert for it

Most clients support SSL for a virtual host by now.

Why not simply remove those clues for self-signed sites? Why popup bigass warnings?

Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.

The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all.

I think you just answered your question -- this is exactly why there should be bigass warnings.

And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.

The address bar now turns yellow -- green, for EV certs -- and sites like Paypal are hard at work training people to look for those signs. Why are you proposing to make that situation worse?

Re:Seconded.

[Anonymous Coward]

A "handful of clients" can probably have the self-signed key verified manually. Probably easier to set up your own CA and give them an installer or something though.

Re:Seconded.

[Deven]

It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.

I am running Firefox 3.0.1 under Windows right now, and I tried to visit this web page. Firefox displayed a full-page error message that looks exactly like the error message you get when a site is down:

Cannot Complete Request

www.cacert.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer)

Let's try to troubleshoot the problem:

• Check Internet connection: Your Internet connection seems to be working.
  
• Try to perform some diagnostic tests:

  [Ping Server] [Trace to Server] [Ping Myself] [Trace to Myself]
  [Retry This] [Google Cache] [Wayback] [Whois]

General troubleshooting tips:

Additional information about this problem or error is currently unavailable.

Yes, Firefox 3.01 did block me from accessing the website. The error message is completely unhelpful. There's no visible way around it. There's no explanation of how to resolve the problem. I was able to load the page by installing the root certificate manually, but any normal user would see this message and just think it's a broken website.

How does it benefit the world to get people to STOP using SSL?

Re:Seconded.

[lukas84]

The error message you're getting is completely different from mine:

Secure Connection Failed

www.cacert.org uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

        * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.

        * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.

Did you install fancy plugins? :)

Re:Seconded.

[marcosdumay]

There is almost no added security from #2 compared to #1. But Firefox could simply render the page like a normal, non-encrypted one. That means, no lock, no yellow bar and no security warning.

Re:Seconded.

[nevali]

They MIGHT use encryption if SSL was free and issued on a total wildcard basis.

A huge proportion of the web doesn't run on dedicated IPs.

Re:Seconded.

[Valfather]

You seem to not understand insurance. The ENTIRE point is so that people like you subsidize people who get into a wreck a week.

That and take the unknown risk of a car accident (in financial terms) and package it into a nice monthly fee.

Compulsory insurance means that you pay much less, because the pool of risk is much larger. And realistically everyone who drives needs auto insurance because accidents can be very expensive.

Re:Seconded.

[great_snoopy]

Don't be silly. Without a proper certificate one can sit right between you and amazon.com and rip you off. Don't confuse cheap lookalikes like amaz0n.com or variations with professionally made man in the middle attacks where you will really go to www.amazon.com but you will actually talk to someone else.It seems to be a lot of misconception and ignorance about certificates today. Also, do not forget that CA's bureaucracy is partially justified, think that their role is actually to grant certificates to a valid and verified entity, not just anyone.Same goes for entering the market, you would not want your average Chinese to open his own CA and then grant certificates without properly verifying who's behind them, right ? A certificate is ultimately an electronic ID for a service, and as with any ID, they must be granted under a more strict rule, or otherwise anyone will be printing his own driver license or ID card at home - problem being that one could easily impersonate anyone.

Re:Seconded.

[WNight]

Right, it doesn't need to claim the connection is to a known party, just use encryption to keep the ISP and everyone else from sniffing.

Re:Seconded.

[el americano]

This prevents those sites from using HTTPS, as it makes entering them pretty hard and obvious.

And preventing them from using https does what exactly? The users don't get that great big warning screen that they supposedly require. There's just a missing padlock in the status bar. It's hard to justify a full screen alert with a multistage exception procedure when it's this easy to go around.

Mission solved.

Accomplished. It's mission accomplished and problem solved. Except it isn't.

Re:Seconded.

[DragonWriter]

you run a self-signed certificate you still can get the man in the middle protection.

Well, no, you can't. If you share the key used to sign your certificates out-of-band with your users so that they can trust you as a CA, then you can get MITM protection, but then you aren't "self-signed" as the term is usually used (particularly, a browser with your CA key installed, the only way you get MITM protection, won't warn that your page is protected only by a "self-signed" certificate), you have a regular CA-signed certificate where the CA happens to be under your control.

Re:Seconded.

[Anonymous Coward]

Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.

For small community websites, 2 could easily exist. Simply pass the certificate through a secure channel and warn if it changes. Blocks out ISPs and prevents any MitM attacks.

Re:Seconded.

[Anonymous Coward]

"Things do not get much simpler than that."

um. right. You're not serious, are you?

To a non-tech person, a certificate is what you get after swimming 10 lengths, and signing is what happens to books, by authors. "The certificate can't be trusted because it's self-signed." means absolutely NOTHING to a non-tech person. They'll be sitting there thinking "what on earth does self-signed mean? Is that good?"

Even a message saying: "Most secure (https) websites have a "signed certificate" to prove who they are. This website's certificate was signed by themselves, and thus we cannot be sure of their identity" is too complicated for the lowest common denominator.

Something really basic would be better, like: "This website has given us no proof of who they really are. All secure (https) websites are encrypted to protect against eavesdropping, and the vast majority of them also provide proof of their identity. This one is encrypted, but there's no way we can ensure that they are who they say they are."

Re:Seconded.

[Larryish]

So the difference between a "professional webhoster" and an "unprofessional webhoster" is a 15 dollar certificate?

Re:Seconded.

[Anonymous Coward]

plaintext = possibility of sniffing + possibility of unknown identity on the receiving end

self-signed https = possibility of unknown identity on the receiving end

therefore, self-signed https more secure than plaintext.

Re:Seconded.

[kayditty]

The point is you'd have to actually implement a MiM attack

OH NO!!! It's so hard to apt-get install ettercap!!!!!!!!!!!!!!!!!!!! Security through obscurity. And not in a good way (security through obscurity is useless as a purely defensive measure, especially when it's your only one).

The number of people who mis-understand SSL on Slashdot is appalling; I keep seeing these threads pop up time and time again. Anyone who thinks self-signed certificates are a good tool for obtaining any form of security beyond that which is afforded by normal plain-text means, in a real, practical environment, does NOT understand SSL. At all. Get off of Slashdot.

Re:Seconded.

[Antibozo]

You got it wrong.

plaintext = possibility of sniffing + possibility of unknown identity on the receiving end

self-signed https = possibility of sniffing + possibility of unknown identity on the receiving end + false perception of secure comms

Therefore, self-signed https is less secure than plaintext.

Re:Seconded.

[hvm2hvm]

Haha, sorry but I'm not American. I don't want the government to instill fear in people, I want them to let the people learn by themselves what it means to be responsible. If you look on sites like notalwaysright.com (it's the first that comes to mind but I see examples like those everyday) you will see that humans are losing their common sense at a rapidly growing speed because of all the "proactive protection" imposed by the government. Whatever security and safety measures we put in place there will always be someone stupid enough to harm him/her or someone else. I'm not going to talk about willfully doing harm because you can't stop with regulations anyway.

Re:Seconded.

[hvm2hvm]

"and all that happens to me is I get sent to jail for at most a few years"
That is my point exactly. Stupid stuff like that should be punished more harshly. People would maybe then learn not to drive carelessly.

"Worst part is, I also didn't have insurance. My policy lapsed because I couldn't afford it."
To be honest, when someone important to me dies in a car accident I really don't care about the fucking money. Of course financial aid for hospitalization etc. is welcome in such cases but those could be provided by the state (or should be).

Getting money from the guilty guy is just a byproduct of capitalism. In my opinion anyone who thinks he deserves financial compensation proportional to the loss (s)he suffered (friend, relative, family) does not deserve any kind of help. That's just greed, nothing else.

Of course I will be flamed for this. Some will call me a communist or fascist, others will think I'm a sociopath. But just so you know I wouldn't take money if someone dear to me would die because of someone else. I would want revenge although I probably won't do anything about it anyway but would be happy the more jail he/she would get.

Re:Seconded.

[cecil_turtle]

You're still setting up a straw man argument to promote the authentication function of SSL. I totally understand what you're saying, we all get that. But you obviously don't have any real world experience on the ins and outs of this. Try to understand that there are times (many times in my experience) where you want SSL and don't care about a CA or getting authentication.

For one, *I don't CARE* about MITM attacks - they are 10000 times harder to pull off than basic wireless or ethernet snooping at a hotel, Internet cafe, or on a LAN. I am *WAY* more concerned with somebody sitting on the wire passively listening on a peer node than somebody with network infrastructure access and a server plugged in that is statefully monitoring all traffic and attacking HTTP SSL traffic by creating duplicate certs on the fly. That is what I use a lot of SSL for, to get OUT of a known hostile local environment, not to prevent a much harder MITM attack.

I should be able to use this perfectly valid and common purpose of SSL without excessive annoyances. Some of these cert errors aren't even bypassable in Fx3, which is even more ridiculous. The browser should inform the user as to the status of the certificate as best and unobtrusively as it can. If I wanted to be treated like I'm stupid and prevented from doing things that I want to do because a browser thinks it would be better that way, then I'd use IE.

If you're looking to worry about obscure attacks then I'm sure you modify your list of Certificate Authority's, removing ones who don't live up to your own personal levels of validation? Oh you don't? Do you check the signatures on your browser every time you install it or update it to make sure the upstream source wasn't tampered with? Do you check your keyboard plug every time you sit down at your desktop to make sure there isn't a logger on it? Do you cover your keyboard everytime you enter your password to make sure nobody is watching? No? There are thousands of potential vulnerabilities that exist every time you use your computer, let SSL do (one of) its job(s) and quit making it out like it's worthless without authentication - it's not. Security is effective only in layers; SSL is just one of those layers. As an intelligent user and/or sys admin I should be able to choose the security cost vs. risk ratio that I am willing to live with. Browsers making those decisions for me is a problem.

Re:Seconded.

[Hes Nikke]

I think changing the rules in the middle of the game is something Hit^H^H^H George W Bush would do :P

Re:Seconded.

[Endo13]

That is my point exactly. Stupid stuff like that should be punished more harshly. People would maybe then learn not to drive carelessly.

That doesn't address the issue.

First, there's no punishment sufficiently harsh for killing another human, other than the death penalty.
Second, there's automobile accidents where people die and no one is really at fault. It's just simply an accident. For whatever reason, it couldn't be avoided. Maybe I run into a pothole which causes me to lose control of my car, which then causes me to crash head-on into your car. Or maybe it's a dog. Or maybe one of my brand new tires was a lemon and I had a blow-out. There's just no way to always pin the blame on someone. So what you do is eliminate the most high-risk drivers to keep it as safe as possible. That's the whole idea of "driving is a privilege". You're in control of a machine that could at any moment cause the death of another person. In order to have the privilege to operate that machine, you need to qualify yourself as being capable of maintaining control even in many unavoidable emergency situations. (Obviously America doesn't do as good a job of weeding out the incompetent as many countries do, but that's another topic for discussion.) And for those times when you just can't, there's insurance.

Re:Seconded.

[hvm2hvm]

There is no punishment harsh enough that makes people feel better after losing a family member. But that is not the real problem since you can't take care of every person in the world. All we can do is make sure that on the whole less people die. Regulating each possible situation that may arise while driving is naive at best.

Now, how are insurances helping to weed out the high risk drivers? You just obligate dangerous people to pay in advance for the damage they will cause. And usually the insurance they pay doesn't cover a single repair cost. The money actually comes more from good drivers too since there are probably more of those out there. Also, insurance covers only some of the possible accidents and certainly not moral damages that would be payed in some extreme cases.
And how are they helping against honest accidents? Sure, the repair costs but then why couldn't the government just pay for true accidents and be asked for a 0.5$ more in taxes or something? It's more direct and cost effective.

Re:Seconded.

[SanityInAnarchy]

For one, *I don't CARE* about MITM attacks - they are 10000 times harder to pull off than basic wireless or ethernet snooping at a hotel, Internet cafe, or on a LAN.

Maybe so, but I don't have to, because someone else already has. Downloading Wireshark and downloading Airpwn are equally trivial. Implementing Wireshark is probably harder than implementing Airpwn, but that's really irrelevant.

And if your attitude becomes common, how soon before the same kinds of automated passive attacks are replaced with automated active attacks?

If I wanted to be treated like I'm stupid and prevented from doing things that I want to do because a browser thinks it would be better that way, then I'd use IE.

Major difference: IE won't give you a choice. If you feel so strongly about this behavior in Firefox, go patch it. Or, if you're not a developer (or feeling particularly lazy), file a bug asking for the ability to turn this off, or troll around looking for people willing to fork the browser.

For what it's worth, even SSH behaves like this. If you SSH to a host which is unknown, you'll get a big ugly warning -- and it will then keep track of that host key. If you SSH to a host whose key has changed, you will get a GIANT ERROR, which in BIG SCARY CAPS tells you that it's possible someone's intercepting your traffic RIGHT NOW OMG!

And there is no way to override it short of removing the key manually from the config file -- which is a good deal harder than four clicks.

I would think SSH is the kind of tool power users would be using for themselves. It's the kind of place you would expect people to be well-educated about this sort of thing, and where you'd expect people to not want their decisions made for them.

But they chose to make it difficult to be insecure.

Do you check the signatures on your browser every time you install it or update it to make sure the upstream source wasn't tampered with?

Actually, yes. Specifically, apt uses GPG to check them. Every install, every update -- of every app on the system. I therefore open myself up to a MITM exactly once -- when I download the install CD.

Do you check your keyboard plug every time you sit down at your desktop to make sure there isn't a logger on it?

Actually, I carry my keyboard with me. Not for security reasons, but it does kind of make this moot.

Do you cover your keyboard everytime you enter your password to make sure nobody is watching?

No. I do, however, use Dvorak, and type extremely fast. Someone would have to be watching very carefully, or recording it to play back at a slower speed. And that password is only used locally -- the passwords I use remotely, I mostly have my browser memorize, or they're keys instead of passwords -- so they would have to steal my machine in order to do it.

In the case of my laptop, they would also have to steal my USB key, or they'd have to very, very quickly perform a cold-boot exploit.

There are thousands of potential vulnerabilities that exist every time you use your computer

I don't see that as a reason to introduce more.

quit making it out like it's worthless without authentication - it's not.

Actually, it kind of is. Without authentication, it is security through obscurity -- you're basically praying that no one who is capable of sniffing your packets realizes that they could probably alter them, too.

Now, by some arguments, it's not completely useless. After all, neither is the "two-factor authentication" employed by most banks -- since it is theoretically possible that someone would collect your password, but not the answer to your security question.

But the payoff is so low, at this point, that I don't see why you'd bother -- and I think it's dangerous to support it at all, because it provides a false sense of security.

Re:Seconded.

[hardwarefreak]

By the definition of Terrorist in your sig, I was a terrorist in the minds of my athletic opponents back in high school, and Almighty God is a terrorist in the minds of many followers of the western religions including and descending from Judaism. Oh, throw great white sharks in as terrorists too, as being killed by Al Qaeda holds about the same probability as being attacked by Jaws. Yet in this case, the fear of Jaws is likely much greater than that of Al Qaeda.

Re:Seconded.

[michield]

very well said. It's the discrepancy between the "masses" and the "informed". It's brilliant, and very responsible of the FF team to make this happen to the masses, and for all of us "informed", in one way or another, we just re-install our company wide CA and we're off again.

I'd rather my mum gets told by FF to distrust some site, than instead her happily inputting her personal details to some site that's a bit flakey. That's the problem of having to protect such a large range of users. All my clients and staff are easily informed about a new CA certificate (mine) change (+url). Doing that to millions of unsuspecting users is not really that easy.

Re:Seconded.

[sjames]

When you consider that it requires no more effort on the CA's part than the $14.99 cert, it's an absolutely outrageous mark-up.

Re:Seconded.

[sjames]

And yet, phishing is rampant. Perhaps because people "know" that if the site was up to no good, there would be that big untrusted site/bad certificate thingy.

Re:Seconded.

[mysidia]

When you say 'good riddance to unprofessional webhosters'; you are not saying 'good riddance' to low-quality webhosters; you are saying good riddance to non-profit sites in general.

There is nothing wrong or invalid with a self-signed certificate.

The expectation is the user will validate (or reject) the certificate without the benefit of a for-pay CA.

If they accept it, they add it to the database, and the browser should recognize it as "known" in the future.

Just like your SSH client warns you the first time you connect to a new host.

It would be ridiculous for your SSH client to bring up a red "SECURITY ALERT" dialog, and demand you manually add an "exception" to your .ssh/hosts file, to allow the new host to be easily registered.

Re:Seconded.

[mysidia]

As an online discussion gets more and more posts, the probability of a reference to Godwin's law approaches one.

Re:Seconded.

[JohnFluxx]

> I would suggest that a browser not display the warning you are showing always, but only if the user is being prompted for data. That, or we need to make the three levels of security more clear to the end user. However, I'm not a big fan of putting more requirements on the user.

Okay so as a hacker I redirect my banks website to my own website, encrypted. No warning pops up on the users screen that the certificate is invalid yet. On the webpage, I tell the user that their bank account has been frozen, and to call a given phone number. The user does, and I get all of his details.

Re:Seconded.

[ftobin]

You raise a good point, but don't forget that in order to tell the user his bank account was frozen, he most likely would have had to input data. Otherwise, he would likely be wondering the bank was telling him his account was frozen without even entering his username.

Re:Seconded.

[guardian-ct]

What is your admin smoking? Do they really want your bank account number and password? They've installed a Man-in-the-Middle attack on their main network. Either they really don't trust the employees, or the admin who set it up wants to be rich after he leaves the company.

Re:Seconded.

[DavidTC]

No, I mean, trusting the proxy would present all SSL sites as authenticated...even ones that weren't, or were clearly the wrong name, or expired, or even revoked.

Re:Seconded.

[DavidTC]

There are actually a few ways to avoid sending cleartext passwords, even over an untrusted channel, which are reasonably immune to MITM attacks -- at least, on the password itself, assuming no one did a MITM while you were creating a login.

Not without Javascript or HTTP auth.

If you really can't afford $10/year, that implies you don't have a job, which implies you have a lot of time on your hands -- so you should be able to figure this out, and write the extension if needed. If you don't have that kind of time, you probably do have that kind of money. How much does Slashdot make?

Aaaaaand....cue the personal attacks and insinuations.

As it so happens, I do have a job, and part of that job is to run an web server with some SSL storefronts. It also runs a lot of Joomla community sites that have a slight amount of security would be nice.

Most clients support SSL for a virtual host [wikipedia.org] by now.

'Most clients', of course, not including IE6 or IE7 on XP. Which by themselves occupy >50% of the web browsing traffic. (And while half the remainer might be using more advanced browsers, the other half is using less.)

Because in the case where it is a bank site, you do want a giant fucking warning if someone's trying to MITM you.

If someone is trying to MitM your bank, you know what he'll do? He just won't use SSL.

The address bar now turns yellow -- green, for EV certs -- and sites like Paypal are hard at work training people to look for those signs. Why are you proposing to make that situation worse?

What the hell are you talking about? I said to not provide the clues for self-signed certs. People who know about the clues thus won't be fooled. People who don't know about the clues are already fooled by simply not using SSL.

I swear, people like you are so goddamn annoying. Everyone pushing for not having big warnings about self-signed certs is fine if browsers don't put up lock icons and green bars and everything, and we've been saying this from the start. It's fine if there's no indication at all it's an encrypted connection.

All your yammering about people being 'fooled' requires people somehow being smart enough to figure out they're on encrypted connection, and yet dumb enough to not realize it's not signed by a trusted authority. So you imagine a world where web browsers treat CA-signed and self-signed certs exactly the same, despite that being obviously fucking stupid and not what anyone is suggesting. Web browsers can indicate it however they want, or not at all, as long as they don't run around implying it's somehow less secure, and requires more work, than plaintext browsing.

We are simply suggesting that we be allowed to encrypt web pages, with no authentication, if we so choose, without bigass warnings popping up scaring everyone, so people can't trivially snoop on a connection and get passwords. (Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.) That is all.

Re:Seconded.

[lukas84]

In such a setup, it would be the SSL Proxy's job to make sure that the "real" certificate is right. The user never sees it.

Re:Seconded.

[DavidTC]

Well, the whole thing is set up stupidly in the first place.

The entire concept of secured-from-the-start SSL on another port was incredibly stupid. It happened with POP3, IMAP, HTTP, etc, and has caused nothing but problems.

Writing all protocols where you first connect in plaintext, and then switch to an encrypted connection, would have been infinitely more sensible.

Especially since, if we'd done it then, we could have had a OOB character defined to do that and everyone could have done it the same way. I.e, it should have been part of the 'telnet' protocol.(Yes, yes, that's not actually the 'telnet' protocol, but you know what I mean.)

Everyone's switching over now, with things like STARTTLS and the new virtual hosts for HTTPS (I believe that starts unencrypted and sends the hostname, and then flips to encrypted, but I could be wrong.), but there are always going to be clients out there that can either speak plaintext or SSL, not start plaintext and switch, so the SSL ports will be around for a long time.

Hell, I still have to run a damn encrypted 'smtps' port on 465 on my mail server, for Outlook Express, because it can't connect to the standard submission port and send STARTTLS.

Re:Seconded.

[SanityInAnarchy]

Not without Javascript or HTTP auth.

Right. Why is this a problem, again?

Aaaaaand....cue the personal attacks and insinuations.

This isn't personal. Minimum wage in this country is more than enough to afford $15/year for a cheap certificate. As an expense for a business, it should be minimal.

For the amount of time and effort you've put into arguing with me, at a decent wage, you could probably afford two certificates, or the same certificate for two years.

You haven't actually provided a counterargument -- you've just refused to answer it as a personal attack.

It's fine if there's no indication at all it's an encrypted connection.

Seems outside the scope of SSL. Or rather, under that scope. And as you stated above, you already have two options: HTTP auth and Javascript.

All your yammering about people being 'fooled' requires people somehow being smart enough to figure out they're on encrypted connection, and yet dumb enough to not realize it's not signed by a trusted authority.

For over a decade, there has been a lock icon in the taskbar, and https in the URL -- and we've been training users to look for these signs. A green address bar is nice, yes, but what you're proposing is that we completely retrain users to look for completely different clues for "this is an encrypted connection that I trust" and "this is just some random encrypted connection".

That, or you're proposing that we hide the crypto from users entirely -- which seems just as heavy-handed as throwing up gigantic warnings. So much for wanting choice.

(Which, despite what people seem to think, actually is a hell of a lot easier than MitMing a connection.)

Seems you didn't actually have a counter for my airpwn link.

Give me one situation where someone would "trivially snoop on a connection" without also being able to trivially run an SSL MITM attack, and trivially snoop on your wish-it-was-SSL connection.

Re:Seconded.

[Antibozo]

Writing all protocols where you first connect in plaintext, and then switch to an encrypted connection, would have been infinitely more sensible.

I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.

I'm not sure what problems you think having TLS-wrapped port designations causes.

Everyone's switching over now, with things like STARTTLS and the new virtual hosts for HTTPS (I believe that starts unencrypted and sends the hostname, and then flips to encrypted, but I could be wrong.)

The client uses an extended TLS Hello that contains the desired hostname. It's not encrypted, since it precedes key establishment. As far as I know, this is not in wide deployment as of yet.

Re:Seconded.

[JohnFluxx]

Good point. Maybe you could have it look like he is still logged in?

Re:Seconded.

[DavidTC]

I disagree. With STARTTLS, it's much easier for a misconfigured client to send credentials in the clear. Server policy may prevent those credentials from being honored before TLS establishment, but by then they've already been exposed.

Yes, it's easy for a misconfigured client to do almost anything. I mean, type the wrong domain name in, and who knows where it will send your credentials!

However, if the system had been set up to switch automatically from the start, correctly configured servers and any clients that supported SSL could switch automatically. Without any prompting or 'configuration'. If the client and server support SSL, they'd negotiate it in the connection. If one of them didn't...well, you're insecure no matter how you're configured.

Whereas, with a two port system, all clients are going to default to the unencrypted port, which means they will have no security at all. Which in actual fact is a good 95% of POP3 and IMAP users out there. They selected POP3 or IMAP, and got port 110 or 143, and that's it. (1)

And, of course, nothing would stop clients from offering a 'refuse to send credentials until encrypted' toggle. Although a more logical default, especially for mail clients, would just be to store a cert, for each connection, when they get it, and warn if it changes.

I'm not sure what problems you think having TLS-wrapped port designations causes.

Well, um, there's exactly what we're talking about, with HTTPS connections.

1) Of course, a lot of server scramble the login, but reading other people here talking about unauthenticated HTTPS, we are apparently required to assume there are dozens of MitM attempting to hijack our connections, and any 'security' that doesn't protect against that is no security at all and not worth doing. So obviously scrambled passwords are a scam...MitM can just hijack your IMAP connection, or whatever, and keep it open forever.

Re:Seconded.

[Antibozo]

I mean, type the wrong domain name in, and who knows where it will send your credentials!

True, but domain name, unlike TLS/STARTTLS settings in a client, is relatively hard for Joe User to get wrong. And if he succeeds, the eavesdropper doesn't automatically know what host the credentials are for.

Whereas, with a two port system, all clients are going to default to the unencrypted port, which means they will have no security at all.

Unless the server isn't even listening on the cleartext port, which is how I configure my systems. This way the client can't establish a connection to the non-SSL version, let alone send credentials or other data in the clear. This wouldn't be possible in the switching system you advocate for.

Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.

And, of course, nothing would stop clients from offering a 'refuse to send credentials until encrypted' toggle.

There'd be no harm in having such a toggle for clients, but as server admin, I don't get to make sure it's set. So I prefer a method where I can keep the client from talking to the server unless SSL is already negotiated.

An alternative to the status quo that might satisfy both of us would be to do away with cleartext IMAP and POP altogether. But for services like SMTP, HTTP, and LDAP, a parallel cleartext version is less dispensible.

Although a more logical default, especially for mail clients, would just be to store a cert, for each connection, when they get it, and warn if it changes.

Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.

I'm not sure what problems you think having TLS-wrapped port designations causes.

Well, um, there's exactly what we're talking about, with HTTPS connections.

Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?

reading other people here talking about unauthenticated HTTPS, we are apparently required to assume there are dozens of MitM attempting to hijack our connections

If you assume otherwise, you get what you deserve.

Re:Seconded.

[DavidTC]

This isn't personal. Minimum wage in this country is more than enough to afford $15/year for a cheap certificate. As an expense for a business, it should be minimal.

And I notice you completely ignored the 'And we don't have infinite IPs either' point when I demonstrated that the majority of web browsers do not support them.

IP addresses are not free.

And I've already pointed out we're not talking about businesses. Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.

Seems outside the scope of SSL. Or rather, under that scope. And as you stated above, you already have two options: HTTP auth and Javascript.

Yes, and I use Javascript.

That doesn't mean that I can't say 'I wish the web browser would encode this password using the encryption built in, instead of something written in this annoying language'. Public key encryption in Javascript is incredibly annoying.

HTTP auth would be an option, and this is actually what it's designed for, if it wasn't the ignored step-child of web browsers. It's a frickin giant dialog box, entirely breaking the paradigm of the web. Why they can't give a login bar along the top of the page and print the 'error' page under it, I don't know.

That, or you're proposing that we hide the crypto from users entirely -- which seems just as heavy-handed as throwing up gigantic warnings. So much for wanting choice.

How the heck is that 'heavy handed'? I have no problem with it.

If you're really that worried about 'https' in the URL bar, I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections. Or a yellow warning bar that the page's origin cannot be verified.

Anything but the big pop-up implication that there's some huge security issue when someone goes from plaintext to unsigned SSL, requiring four or five clicks to get past.

Incidentally, I suspect that's some of what's causing the actual security issue of people trusting random web sites, in that people think plaintext browsing is somehow secure and people can't lie about their origin. Sure, it sounds crazy, but if people see a few giant security warnings, they could quite legitimately assume everywhere there's not a warning is secure.

Give me one situation where someone would "trivially snoop on a connection" without also being able to trivially run an SSL MITM attack, and trivially snoop on your wish-it-was-SSL connection.

There are at least two orders of magnitude difference needed to log web pages, especially if you're just grabbing the headers and POST variables, and needed to read, decrypt, reencypt, and send along web pages. Especially if you have to check which are signed by a known CA and not alter them.

There's a reason that Comcast wasn't altering torrent connections to disconnect them, and was instead sending TCP reset packages...it couldn't operate fast enough to actually edit the connections in situ. They're actually statistically sampling the connections because they can't handle the volume, and their system was operating from a copy of actual traffic, not 'in line'.

Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.

You're arguing just because something isn't technically impossible for an attacker to break means we shouldn't allow it. That's just crazy talk. We allow all sorts of 'moderate security' in the computer industry, a lot of actually aimed at passive spying, like logins for mail and http auth, which anyone could MiTM, and storefront software that doesn't store entire CC numbers, despite anyone being able to alter it to do that very quickly.

Saying 'Ha ha, anyone can MiTM, and asking for a security ability that can be defeated by it is stupid' is just security elitism. We're asking for 'wearing a badge' security, not 'fingerprint and r

Re:Seconded.

[DavidTC]

This wouldn't be possible in the switching system you advocate for.

Sure it would. The telnet protocol allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.)

Granted, the client could lie, but that would be a protocol violation, and if we're considering those, nothing stops a client from spewing plaintext into a SSL connection either.

That said, the problem there is poorly designed protocols that allow one greeting unparsed message from the server and then the client instantly sends the login. This was yet another protocol stupidity, right up there without allowing switching to SSL via telnet negotiation. (Although if we'd used the latter, we wouldn't have worry about the former...telnet negotiation happens before any communications at all.)

SMTP, interestingly, doesn't have this problem, because SMTP wasn't designed with authentication in the first place. The server has to state the ability to login, via ESMTP options. IMAP, being a late designed protocol, doesn't have this problem either.

With both IMAP and SMTP, you connect, and get a message from the server, but that message has to state the various methods you are allowed to login.(Along with various other options.) The server can, in fact, state no login methods at all, and just present the 'I can switch to SSL' option. After the switch, it can present the login methods again.

Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.

I don't know what you mean by that. SSL negotiates itself quite well between different versions. A lot of SMTP traffic already magically switches itself to SSL. I myself have let my mail server switch to SSL (Well, TLS) on demand, and have had over 500 TLS connections the last two days. (Which is actually absurdly high for the amount of mail we get, so either spammers are using SSL or my grep failed.)

Although obviously, looking at it from that direction is stupid. Our mail server (postfix) also attempts to negotiate SSL connections for outgoing mail, and I've never seen mail bounce because it couldn't negotiate a connection.

Certificates change regularly for legitimate reasons. I see no reason to confuse users by alerting them when this happens.

Let me restate: Users should be alerted when an self-signed cert changes to another self-signed cert, or when a CA-signed cert changes to a self-signed cert.

Yes, what specific problem are you talking about? HTTP is for anything that doesn't require a secret (mod Digest auth); HTTPS is for everything else. What's the problem?

The problem is that negotiation happens before any other communications, so that clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.

This actually would be a problem in other protocols, except no email client expect signed-by-the-email-domain in email SSL connections.

Re:Seconded.

[Antibozo]

Sure it would. The telnet protocol [iana.org] allows both ends to specify requirements, and results in a disconnect if the other end doesn't support it. (In fact, it appears to already support SSL, but I suspect that doesn't include certs.

Nonetheless, what I described—the client cannot talk to the server in the clear at all because the corresponding port is not listening—is not possible.

Furthermore, a switching system entangles application protocols with the constantly mutating TLS, which would make maintenance of both more difficult.

I don't know what you mean by that. SSL negotiates itself quite well between different versions.

I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a <starttls...> tag, etc. Then the protocol has handle various failures gracefully.

With the separate port method, TLS is just a layer on top of the application protocol and the application protocol can focus on doing what is was designed to do. In addition, each application that adopts TLS as a native feature locks us in deeper to TLS, both in code added to implementations and in TLS-specific error handling. This makes it harder to swap TLS out for something better if/when that comes along.

Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.

clients cannot state what website they are actually connecting to, so the server cannot present the correct certificate for that web site. Which is why HTTPS sites need their own IP.

That's a defect in the original design of SSL, which should give you an idea as to how well thought out it was (not very). This problem is addressed with the extended Client Hello, which is gradually being adopted in client software. Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.

Re:Seconded.

[SanityInAnarchy]

And I notice you completely ignored the 'And we don't have infinite IPs either' point when I demonstrated that the majority of web browsers do not support them.

You've got one, right?

How many domains do you need to support, exactly?

Online businesses obviously need authentication. A guy who can barely afford godaddy to run his joomla discussion board does not.

First, Joomla? Really?

Second, why does this disqualify him from needing authentication? All you're talking about is the economic impact (which I've demonstrated as pretty small). If we're assuming he actually can run SSL, which implies that he has his own virtual host, Godaddy charges something like $40/mo for that -- an additional cert (for a plan which doesn't actually include a free one) is going to be less than $2/mo.

That doesn't mean that I can't say 'I wish the web browser would encode this password using the encryption built in, instead of something written in this annoying language'.

Javascript is actally fairly powerful, and often misunderstood, but that's beside the point. It has a builtin method for exactly what you're asking, which is called HTTP auth. You just find it ugly.

It's a frickin giant dialog box, entirely breaking the paradigm of the web.

Paradigm? I don't think that word means what you think it means...

And it really doesn't, much -- you would just be implementing exactly the same thing in an HTML form, maybe with some javascript. It has the added advantage of being uniform -- every page that uses HTTP Auth will provide the same login form.

How the heck is that 'heavy handed'? I have no problem with it.

That's a great definition of "not heavy-handed" -- "something I have no problem with." That's serious Godwinbait.

I'd be happy with a newly-defined 'httpe' or something, for encrypted but non-authenticated connections.

Fine, go ahead. I don't think it's worth the effort it'd take to implement, but that's me.

Sure, it sounds crazy, but if people see a few giant security warnings, they could quite legitimately assume everywhere there's not a warning is secure.

That actually is pretty crazy. When driving past a prison, you see giant signs that say "Do not pick up hitchhikers." Does anyone assume that hitchhikers are 100% safe everywhere else?

There are at least two orders of magnitude difference needed to log web pages, especially if you're just grabbing the headers and POST variables, and needed to read, decrypt, reencypt, and send along web pages. Especially if you have to check which are signed by a known CA and not alter them.

Are you talking about performance?

In other words, it takes a few orders of magnitude more clock cycles on my laptop when I airpwn you. What does it matter to me, as long as I have enough?

Or are you assuming that I'd be trying to crack quite a lot more connections at once? What's the motive? Where is it that I have the opportunity to intercept enough traffic that the "orders of magnitude harder" even matters -- and for what purpose do I need that much data?

I'm not trying to say "you have nothing to hide" -- what I am saying is that I don't see a scenario where such an attack would make sense -- where it would have an economic incentive, even.

Especially if you have to check which are signed by a known CA and not alter them.

Which you don't, really.

Remember, you'd have to intercept all communications. You couldn't encrypt half with one key and let the rest pass buy.

First, I only need to accept all communications from the client I'm trying to 0wn. I don't need to intercept all communications from everyone.

Second, I only need to get lucky once -- I

Re:Seconded.

[DavidTC]

I mean that every protocol has to define a unique way to start TLS negotiation: LDAP sends a particular OID, SMTP uses STARTTLS, IMPP uses a tag, etc. Then the protocol has handle various failures gracefully.

Yeah, I agree. That's why I wish the telnet negotiation protocol itself had included SSL, enabling essentially all line-mode TCP/IP connections to switch to SSL on the fly.

Then we could have avoided all this silliness. All connections start plaintext, all of them switch to SSL without sending a single byte in-band. (Except if it needs to, like HTTP.)

That way it could be, like you say, a layer on top of the application. You'd probably get it free with sockets in libc. Stick a flag on the socket when you make it, and it only accepts SSL.

(Even better, of course, would have been, instead of inventing SSL, invent something that works like SSL entirely at the telnet negotiation level, where all connections are just 'plaintext SSL' connections, and to go encrypted, you just change the encryption used. But I don't know the history well enough to know if that would have been possible.)

Furthermore, SSL's being a mixed binary and ASN.1 protocol makes it very squirrelly when a line-based protocol such as IMAP or SMTP switches it on. At best, it's, shall we say, aesthetically displeasing.

No kidding. That's probably the worse method possible.

I know what you're saying about multiple ports being better than single 'upgradable' ports, and in a way they are, but having two ports means every piece of software in existence defaults to the unencrypted one.

So while you talk about hypothetical misconfigured software that someone failed to check 'Don't connect if cannot secure the connection', what's actually going on is that almost none of the population is using SSL ports at all. Their mail client defaulted to the standard ports, and it worked. If that port offers encryption, the mail client will upgrade, but it's not going to randomly look for the encrypted port.

I know this for a fact. I've been running a mail server for years, and it's moved between machines. Once, when I moved the mail server but not the webmail that was using the same domain name, I had to forward the IMAP and POP3 port to the new server, and I had already pointed my client there to test, so failed to notice I forgot to forward the SSL ports...for two weeks. No one even noticed. Out of forty or so people, not a single one was using an encrypted connection, not a single one complained their email stopped working. I only caught it when I fixed my client to use the old server name and couldn't connect.

SSL ports are only 'more secure' if there's a set of people who would go around setting up their client to use that port, but not setting up their client to require encrypted connections. I suspect this set of people does not, in fact, exist, and even if it does, it is vastly outnumbered by the people who just accept the defaults if everything works.

Within a year or so, hopefully, virtually hosted SSL sites will be commonplace.

Not until IE7 on XP supports it. For some reason, IE7 does on Vista, but not XP. Despite what MS likes to pretend, XP will be around a long time.

Re:Seconded.

[DavidTC]

How many domains do you need to support, exactly?

About a dozen on the server I've got could reasonable benefit from an encrypted, in that they have moderately sensitive information passing over them. Any CMS, for example, has at least an admin interface.

First, Joomla? Really?

And your ideal CMS is...?

If we're assuming he actually can run SSL, which implies that he has his own virtual host, Godaddy charges something like $40/mo for that -- an additional cert (for a plan which doesn't actually include a free one) is going to be less than $2/mo.

You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.

I suspect that if there was demand for it, which means it wouldn't pop warnings up all over the place, they'd give everyone SSL access, using a wildcard cert, via HTTPS, to their existing websites. For no cost. (Heck, it wouldn't cost them anything.)

In fact, thanks for that example, I think it just demonstrated my point for me better than I ever could.

I'm not trying to say "you have nothing to hide" -- what I am saying is that I don't see a scenario where such an attack would make sense -- where it would have an economic incentive, even.

And neither do I. Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.

Normal human beings are not subject to MitM attacks that SSL would protect them against. They really aren't.

Moreover, if they are, either they're going to fall for it regardless, or they're not going to fall for an unauthenticated connection that look sufficiently different from an authenticated one.

First, I only need to accept all communications from the client I'm trying to 0wn. I don't need to intercept all communications from everyone.

Second, I only need to get lucky once -- I only need to be faster than the DNS server for one response -- or, for that matter, the DHCP server. After that response, the client will connect directly to me.

If you are talking about targeted attacks, my point about encryption makes more sense. Because people use the same passwords all over the place. A single cleartext login and you've won.

Moreover, as I've repeatedly pointed out, if you're going to MitM someone with a targeted attack and editing web pages, the logical thing to do is to simply set up a real SSL server with a similar name to the bank, and replace the links in the banks cleartext webpages to that place.

Or just don't use any SSL at all.

Or, heck, just present an invalid cert, and insert a message on the cleartext webpage to click past it, and quite a lot of people would click past it.

I'm not sure why having the option to have unauthenticated encrypted connections helps any of those in the slightest.

I'm arguing that in a context where one might be expecting security, we shouldn't pretend something is more secure than it is. And I'm arguing that when there's a finite amount of development time to be spent improving browsers, I'd much rather it be spent on things like the HTML5 video tag, SVG, standards compliance, Javascript performance, etc, rather than on making mediocre security easier.

That's it. That's where you're at. You have no objection except the time it would take?

Well, okay then. I'm done.

Re:Seconded.

[Antibozo]

That way it could be, like you say, a layer on top of the application. You'd probably get it free with sockets in libc. Stick a flag on the socket when you make it, and it only accepts SSL.

This is the sort of thing we could have with opportunistic encryption using IPsec. But for that we need universal PKI. With universal PKI, every system can have one or more public keys. Authentication can then be mutual between systems. The application protocols could be, as you suggest, almost completely oblivious to this; they will simply require a secure socket and an IPsec tunnel is created automatically.

If we ever get this, we may regret all the work that has been done to munge protocols with TLS awareness.

A big reason I advocate DNSSEC is because it has the capability to provide this universal PKI at no per-system cost to the domain owner. Once you have a signed domain, CAs are no longer needed because you have a superior chain of trust right there in the DNS.

what's actually going on is that almost none of the population is using SSL ports at all

I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order ;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.

Yes, a couple of years ago, this wasn't workable for the little guys. But with $20/year certs available now, it's kind of inexcusable to do anything else.

Re:Seconded.

[SanityInAnarchy]

You are arguing in circles. The reason it cost that much is that Godaddy gives you your own IP and cert.

Fine. You write the scenario.

I'm on Slicehost -- that's $20/mo. IP is included. Cert is, as I've said repeatedly, $15/year. (Except when I thought it was $10/year -- sorry about that.) Insignificant next to hosting costs.

I suspect that if there was demand for it, which means it wouldn't pop warnings up all over the place, they'd give everyone SSL access, using a wildcard cert, via HTTPS, to their existing websites. For no cost.

Well, there are two options there:

Either you put everyone on a subdomain, or a subpath of the same domain -- think Freewebs -- and this might cause XSS issues...

Or you actually start handing out certs for free, without doing any background checks. That wouldn't cause giant warnings -- until the people Godaddy is reselling from invalidated their cert, and/or browsers started removing that root cert, as it's obviously not trustworthy for verifying identity.

(And you're assuming they wouldn't want to use that demand to basically print money.)

Or, you do the background checks -- but this costs money. How do you earn it back? One way is to charge people for the service of identifying them, and... hey! That's how SSL works right now.

Passports -- real, physical ones, that you use to go to other countries -- aren't free, either.

Moreover, I'm failing to see why you think that failing to see why a MitM attack would be implemented somehow demonstrates your point.

Actually, I was talking about your passive attacks.

Or, heck, just present an invalid cert, and insert a message on the cleartext webpage to click past it, and quite a lot of people would click past it.

Which is actually an argument for my point -- make the warning bigger and more obnoxious, so that people actually realize that there's a real security implication, not just another thing to click through without reading.

You have no objection except the time it would take?

Given that you're talking about implementing a whole new URI scheme, and pushing it into major browsers, I think that's a lot of time. I'm not even counting time to educate users.

Given that one of your complaints about my suggestion to "just get a real cert" is that SSL with virtualhosts isn't widely supported enough, I also don't really see the point. We've now, again, reduced the cost of real SSL to $15/year, or $1.25/month -- and that would have wider support than "httpe".

However, making it indistinguishable from plaintext is a bad idea. Making it indistinguishable from verified SSL -- or allowing the possibility for someone to confuse it with SSL -- is a much worse idea. That is what I was arguing against.

And I still don't like it. I think the benefit from it is so small (really, certs are cheap), and the implications are yet another thing which people should learn in order to be secure on the Internet, that it would be better not to have it.

And I think that, moreover, there would be a brand new meme of misinformation that your httpe is "secure enough" for whatever purpose, among people who otherwise would buy a cert, and would be better off for it. (Take rubyforge.org as a shining example of someone who already does this with self-signed certs -- though maybe I should ask and find out why they do it that way.)

But at this point, I think I'm done. After all, my browser already supports things like a fish:// URL scheme, as well as zip:/ and other fun things. People invent new URL schemes all the time -- there's steam:// for Valve products on Windows, "magnet links" for Azureus and friends...

So ultimately, my objections don't matter. Either you'll get it standardized, in which case, it'll hopefully be much more thoroughly debated (and be much improved as a result) -- or you won't, in which case, it'll be a nonstandard extension, something between you and your users, and my opinion won't really matter (kind of like Flash -- fucking Flash...)

Re:Seconded.

[Migity]

True. When you are providing services to the general public you need a trusted 3rd party to verify your identity.

Re:Seconded.

[cecil_turtle]

you're basically praying that no one who is capable of sniffing your packets realizes that they could probably alter them, too.

You do understand that to pull off a "Man in the middle" attack, you actually have to be in the middle, right? (From a network architecture perspective). A peer node can't modify your packets, it's not a matter of just using different software. If you don't recognize that peer nodes are the largest threat (compared to ISP infrastructure) then you're not living in the real world.

The "False sense of security" argument is BS. *I* get to determine what level of security I need for my purposes and budget. SSL, self cert or otherwise, is just one tool in the bag. A browser cannot and should not make that decision for me.

the passwords I use remotely, I mostly have my browser memorize, or they're keys instead of passwords -- so they would have to steal my machine in order to do it.

You're storing your login to SSL sites in your browser? Are you kidding me? No, they don't have to steal your machine, they can just sit down at it when you walk away and forget to lock it. Or they can use administrator level access or somebody else's compromised credentials to go steal your browser's profile or just copy the cookie. Or get it from a backup. Or use a remote exploit. Or turn it off and clone your drive when you're not there. Etc. etc. etc.

No. I do, however, use Dvorak, and type extremely fast.

Talk about security by obscurity. You're rant afterwords is akin to what I'm saying about SSL - you know your environment, you know the likely threats and you are implementing security measures (or not implementing them) based on those perceived threats. That's exactly what I'm saying, thank you for making my point and agreeing. I think we're done here.

Re:Seconded.

[DavidTC]

This is the sort of thing we could have with opportunistic encryption using IPsec.

The problem with IPsec is, frankly, it is never going to actually happen.

And the problem with SSL is that there's no protocol-level independent generic 'negotiation'. It really really should have been designed to start plaintext and switch over, which would have allowed magically building it into every TCP server. TLS is designed to switch over, but not in a protocol independent way, so that's even more annoying.

I recognize that that's the status quo, but it's easy enough to fix. Admins just need to disable the cleartext ports and publish instructions for their users (not necessarily in that order ;^). Every one of my mail users uses IMAPS, because port 993 is the only protocol available. And even if they were to muck up the client config by changing the port to 993 without checking the SSL/TLS box, they wouldn't be able to get to the point of sending IMAP credentials in the clear, because the IMAP client won't be able to read a server hello.

Ha, I wish I had as much authority over my server as you. There's no way I could justify breaking everyone's mail connection...again.

I have actually done something like this once, I stop accepting mail submissions on port 25 and made everyone use the smtp submission port. (And the stupid smtps submission port) I was able to justify that because about every month someone would call and tell me 'the mail server was broken', when in fact they were on a new connection, or their ISP had just started, to block port 25. And I eventually said to hell with it and made everyone switch off 25 at once, as I was able to convince my company that, eventually, the amount of problems using port 25 was causing outweighed the amount of problems switching it off all at once would cause.

I doubt I can use the same logic for unencrypted connections. If it's not broken don't fix it is the motto at most companies, and definitely don't fix it in a way that breaks current setup for people.

Meanwhile, I run SSL ports, if anyone uses them, and I have TLS switching on my main ports. Which means if anyone's bothered to click any security setting, or the client does TLS by default, it's encrypted.

Grepping the logs, almost no one does.

Re:Seconded.

[DavidTC]

Either you put everyone on a subdomain, or a subpath of the same domain -- think Freewebs -- and this might cause XSS issues...

Or you actually start handing out certs for free, without doing any background checks. That wouldn't cause giant warnings -- until the people Godaddy is reselling from invalidated their cert, and/or browsers started removing that root cert, as it's obviously not trustworthy for verifying identity.

Godaddy doesn't have to hand out the certs they use. They simply have to set up a listening server on port 443 with the same virtual domain setup they have, and put a * cert on that.

However, making it indistinguishable from plaintext is a bad idea.

I wish you would EXPLAIN WHY instead of just saying it is. Just asserting things does not make them true.

An encrypted connection without authentication should be trusted, by the end user, as much as plaintext. I'll accept that. (1)

So how is making indistinguishable from plaintext a bad thing?

1) Although I will still argue that the system as a whole is much more secure from outside tampering, in the same way that sealed envelopes are more secure than postcards, despite the fact that almost anyone can file a change of address form at a post office or steal from their mailbox and intercept someone's mail, open the envelopes, and replace them in the end mailbox after tampering. Requiring people stealing your mail to go to all that trouble, instead of letting everyone read and write on your mail and happily send it on its way with no trouble at all.

Re:Seconded.

[Antibozo]

The problem with IPsec is, frankly, it is never going to actually happen.

But the reason IPsec has not become commonplace is the lack of universal PKI.

In any case, IPsec is not necessary to replace TLS. A modified TLS-like encryption layer can use DNSSEC (or whatever ubiquitous PKI) to acquire public keys securely; they don't have to be signed by a CA as long as there is some other trust chain available. The key is to make it cost nothing to set up this trust chain for each host. Since DNSSEC is needed anyway to solve DNS cache poisoning, we might as well use it to provide universal PKI. It would be silly to pay a CA to try to prove, via cleartext email, that you control a domain, so they can sign your public key, when you could instead simply add it to the DNS.

Ha, I wish I had as much authority over my server as you. There's no way I could justify breaking everyone's mail connection...again.

All you need to do is adopt a policy that all credentials have to be encrypted in transit, and then you have the leverage you need. Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.

I doubt I can use the same logic for unencrypted connections. If it's not broken don't fix it is the motto at most companies, and definitely don't fix it in a way that breaks current setup for people.

You don't have to break it, initially. You can just auto-nag all the users that use cleartext ports until they stop, then disable the cleartext ports.

Re:Seconded.

[Antibozo]

They simply have to set up a listening server on port 443 with the same virtual domain setup they have, and put a * cert on that.

Any CA that signs a cert for * should have its CA cert revoked.

Frankly, anyone that uses a wildcard cert should have his ears boxed a few times. Wildcard certs are a moronic devolution that is driven by the economic model of the broken X.509 PKI we're using. We can do better.

Re:Seconded.

[Antibozo]

A peer node can't modify your packets, it's not a matter of just using different software.

If, by "peer node" you mean a node in the same broadcast domain, you are 100% wrong. A "peer node" can very easily put itself in the middle, via arp spoofing, DNS spoofing, etc.

If you don't recognize that peer nodes are the largest threat (compared to ISP infrastructure) then you're not living in the real world.

"Peer nodes" have the most direct access to your traffic. That doesn't make them the largest threat for most people, since for most people there are relatively few attackers on "peer nodes". DNS cache poisoning can be effected by the much larger population of remote attackers.

Re:Seconded.

[cecil_turtle]

No, I assure you that I am not wrong, dns and arp poisoning are unreliable at best between peer nodes, dns poisoning is really only used effectively upstream. The reason for this is that the victim machine effectively spoofs it right back, so they become competing traffic (or in the case of DNS receives two replies, then timing becomes an issue). To do MITM on arp spoofing you need to impersonate both ends, which even more difficult/unreliable, especially if the other nodes are already actively communicating or the arp cache gets cleared (or is disabled). And all are more difficult than passively listening with a filter for plain text traffic.

"Peer nodes" have the most direct access to your traffic.

That is exactly why it's the most dangerous - they see ALL unencrypted data coming out of your computer, hence the desire to encrypt as much as possible coming out of your computer with SSL (HTTP/IMAP/POP/whatever). Anything else has to be a more targeted attack. Peer nodes attack the low hanging fruit. It's like locking your car door in the mall - sure there are other ways to break into the car, but it's just easier to move on to a better/easier target. That's my car analogy for the day.

doesn't make them the largest threat for most people, since for most people

You're confusing largest threat with largest exposure, the two are not directly correlated, I'm making a subjective observation due to the point immediately above and noted in prior responses - the reason I use self-cert SSL is to get out of perceived hostile local environments.

I agree that a CA signed cert is "better" than self-signed, though still not perfect and not uncompromisable, just "better". But the point is if somebody makes a financial choice to only use a self-cert, they are still better off than not using a self-cert. Again, you yourself even made a similar point - why introduce more vulnerabilities? There are two problems that SSL can possible help with (read original article), and self-certs help with one of those problems. I can't, for the life of me, comprehend why anybody would want to eliminate that option.

Re:Seconded.

[Antibozo]

No, I assure you that I am not wrong, dns and arp poisoning are unreliable at best between peer nodes, dns poisoning is really only used effectively upstream. The reason for this is that the victim machine effectively spoofs it right back, so they become competing traffic (or in the case of DNS receives two replies, then timing becomes an issue).

And I assure you that you are indeed wrong. You only need to win these races once and you can remain interposed as long as you like. In fact, you don't need to win a race at all with arp spoofing. A targeted gratuitous arp will generally do the trick, and the host you're spoofing won't even know it happened because it never sees it. Hosts only arp when arp entries expire from cache, which is easy to prevent—just keep sending traffic to the respective hosts.

As for DNS spoofing, it's trivial to beat the DNS server at answering a resolution request.

I agree that a CA signed cert is "better" than self-signed, though still not perfect and not uncompromisable, just "better".

Sure, "better", in the same sense that "useful" is "better" than "useless".

Re:Seconded.

[SanityInAnarchy]

I wish you would EXPLAIN WHY instead of just saying it is.

It falls under "hiding things from the user", which I generally consider to be bad -- and could have unpredictable results.

A contrived example: I've installed a new BB system -- or blogging engine -- whatever. I've configured everything properly, or so I think, and I'm wondering why most pages work, but certain pages just seem to hang forever.

Or, alternatively, I'm trying to access someone else's site, through a heavily restrictive censoring firewall. Again, certain pages work as intended, and certain pages hang forever, until the connection times out.

With at least some distinction in the URL scheme, I might think to myself, "Aha! These are SSL requests of some kind! Port 443 must be blocked somewhere!"

Requiring people stealing your mail to go to all that trouble, instead of letting everyone read and write on your mail and happily send it on its way with no trouble at all.

Given that all of this must be done manually -- calling the post office, intercepting the mail, physically opening the envelope, finding an identical one, and replacing it -- or opening it carefully, so as to be able to re-seal it with no evidence of tampering -- all of this requires a significant investment of time and effort, and a small investment of money.

All you're doing is requiring people to download a somewhat more sophisticated version of airpwn.
Kind of like how using rot13 is pretty pointless, for any data you actually care about. Security through obscurity, plain and simple.

Re:Seconded.

[cecil_turtle]

Beating a DNS server's response is only trivial because you need it to be for your argument to make any sense.

Sure, "better", in the same sense that "useful" is "better" than "useless".

The fact is if all network traffic were encrypted without authentication (a method on which many protocols operate, as you even provided examples of), there would be a net gain in security. I don't know what you think is different about SSL. You have yet to address my primary points in any of these responses, clearly you simply don't have an answer. Good day.

Re:Seconded.

[Antibozo]

Beating a DNS server's response is only trivial because you need it to be for your argument to make any sense.

Beating a DNS server's response on a local network is only trivial because it's trivial. What do you imagine makes it the least bit difficult? Even if you didn't have better latency than the real nameserver, the real nameserver has to ask someone. You don't--your lie is ready to transmit as soon as you see the request.

You clearly have never done any this. I haven't even mentioned, oh, say, using a rogue DHCP server...

The fact is if all network traffic were encrypted without authentication (a method on which many protocols operate, as you even provided examples of), there would be a net gain in security.

No, there would be net gains in CPU utilization and difficulty of debugging network problems, both of which would lower security. Encryption without authentication is useless. You walk into a crowded, pitch black room and say "John, come over here; I want to tell you a secret." Someone comes over, and you whisper your secret to him or her. Well done!

I don't know what examples of protocols that encrypt without authentication you think I provided examples of.

You have yet to address my primary points in any of these responses, clearly you simply don't have an answer.

Perhaps you could indicate which points you consider primary, so that I can correct any additional errors you may have made there as well.

Re:Seconded.

[cecil_turtle]

SSH is the example of a protocol that encrypts and doesn't have a CA behind it that we discussed earlier. It does throw a warning - as you mentioned; and one can just press "enter" to continue past the warning with ease. Sending an encrypted email to somebody using their public key but not signing the message with your own private key would be another example, that we did not discuss earlier.

Let's try this a different way. Let's try to isolate where our disagreement lies. Specify to each of the following what you would agree, or not agree to:

1. A technological system / computer network most likely has a number of different points of vulnerability
2. Security works best in layers
3. There is no single solution that can solve every possible vulnerability
4. Encryption and authentication are two different things meant to solve two different problems
5. If one could theoretically iterate every possible vulnerability in a system (so you have a known number of total vulnerabilities), implementing solutions that reduce that number of vulnerabilities is good - i.e., is better than not implementing those solutions
6. Users should be free (as in speech) to choose the solutions they implement based on price, perceived threat (whether subjective or objective), and other factors
7. An end-to-end system (clients, servers, network) that utilizes SSL provided by a CA to encrypt one point of communication still most likely has numerous other vulnerabilities (see #1)

Let's start there, just list out each one of those and if you agree or disagree with the statement.

Re:Seconded.

[Antibozo]

SSH is the example of a protocol that encrypts and doesn't have a CA behind it that we discussed earlier.

You appear to be confusing me with someone else. I haven't discussed ssh with you. In any case, trusting ssh host keys without verifying them is something that you shouldn't do, and the ssh client suitably warns you when you are about to do so, just as Firefox warns you when you are about to use a self-signed cert you haven't previously asserted as trustworthy.

In the future, hopefully, ssh host key validation will be automated using DNSSEC.

Sending an encrypted email to somebody using their public key but not signing the message with your own private key would be another example,

No, that's not an example, unless you failed to validate the public key of the recipient. You are confusing authentication of the peer with authentication to the peer. And even if you do sign the email, the peer still has to validate your public key before you've authenticated to him. This sort of confusion is a good example of why general users need to be sternly warned about self-signed certs—it's easy to get mixed up when you're trying to do crypto.

I agree in principle with all of your assertions. What's missing is how those assertions can lead you to conclude that Firefox should be more tolerant of self-signed certs than it is.

Re:Seconded.

[cecil_turtle]

You appear to be confusing me with someone else.

You are correct, my mistake, there were two different people to who I replied in the same thread.

No, that's not an example.

Sorry my example was poorly worded, I meant the user in this case being the recipient, not the sender. The recipient received an encrypted mail (using his public key) that was unsigned. Must he disregard the content under all circumstances? Or could it possibly be that the encryption was meant to keep prying eyes from reading the content instead of serving another purpose? That was my point.

I agree in principle with all of your assertions.

If you agree with all of those assertions how can you call encryption without authentication useless? They are two different problems, and solving one problem is better than solving none. If you take a hard stance on this point because of another potential attack vector, then how is any solution ever good enough when there will always be another potential vulnerability? One of my points is that there is a line - there is always something that can be compromised that is out of your control, using a CA isn't a panacea.

Going back to your previous reply:

You walk into a crowded, pitch black room and say "John, come over here; I want to tell you a secret."

Wouldn't it be more akin to calling John via cell phone (self cert SSL) instead of yelling out what you want to say for all to hear (plain text)? Sure, somebody (at the phone company) could re-route the call and maybe they could also mimick John's voice, and maybe they later call John and spoof your caller ID and mimick your voice and relay to him what you said, but if I'm not concerned with those things I'm still better off quietly calling John in the pitch black room instead of yelling it out for all to hear. I have prevented at least some people in the room from hearing what I have to say.

What's missing is how those assertions can lead you to conclude that Firefox should be more tolerant of self-signed certs than it is.

I'm glad we've cycled back to the original article. Let's talk about the recent versions of Firefox (Fx). Fx2 did in fact warn you of a self signed cert, to which a user could simply click OK. Fx3 now requires 3-4 clicks to do the same thing. That's just being in the way for no good reason - a warning message and maybe a colored URL bar would be fine. There was also a time during the Fx3 beta when it was not possible to bypass the dialog for self-signed certs AT ALL, thus rendering access to a self-signed cert site impossible. Fortunately the mozilla devs changed their minds on that one before the stable release. There is still, however, other cert errors that are not bypassable in Fx3 that were in Fx2. Here is one of them: https://bugzilla.mozilla.org/show_bug.cgi?id=312732. This one does have a "workaround" that is fairly difficult and requires some guessing. So Firefox is unnecessarily getting in the way for much SSL usage, going well past a simple warning dialog.

Re:Seconded.

[DavidTC]

Any company that considers its proprietary information to be private should have a hard time arguing with that. And it's easy enough to demonstrate to management bozos how trivial it is to sniff passwords off the wire.

Ah, but this isn't a single company. We're webhosts for a dozen or so businesses, and a few cheap local non-profits, in addition to running our own websites and storefronts.

Company computers are set up with encryption. (At least since I discovered that no one else was using it.) It's the other guys who aren't.

But your idea isn't a bad one. I need to figure out if I can determine from the logs who's using TLS over standard ports (I know I can see who's using SSL ports.) and start talking about a 'security upgrade' that will, sadly, require certain people to fix their email clients.

Re:Seconded.

[Antibozo]

You are correct, my mistake, there were two different people to who I replied in the same thread.

I suspected as much. It happens...

I meant the user in this case being the recipient, not the sender. The recipient received an encrypted mail (using his public key) that was unsigned. Must he disregard the content under all circumstances? Or could it possibly be that the encryption was meant to keep prying eyes from reading the content instead of serving another purpose?

I'm still not sure the example is what you intended. If someone sends me an unsigned, encrypted email, and I can read it, then the sender is using the correct public key, and no one else but me can read the message. The opportunity for subterfuge in this kind of scenario is that an attacker may give the sender a forged public key for my email address, and the person who uses that public key will generate an email which I can't read, but which the attacker can.

In the SSL scenario, the recipient is the SSL server, and whatever entity is connected to the server will use the public key the server sends in the Server Hello. A man in the middle could substitute a different public key in that step, but the conversation would stop when the server couldn't decrypt the client's message. As far as signing, unless you're using client certificates, the SSL process doesn't authenticate the sender; if the server requires authentication this is typically accomplished using a password at the application layer. If a bank didn't require you to authenticate somehow, and let someone transfer money out of your account, that would be a problem, just as it would be if someone sent me unsigned instructions, and I followed them without requiring some other form of authentication in the content of the message.

If you agree with all of those assertions how can you call encryption without authentication useless? They are two different problems, and solving one problem is better than solving none.

The confusion arises because the term "encryption" by itself is too unspecific, and is being used as shorthand for what's really going on. "Encryption" between two parties is fine, but that presumes that those parties have already established a shared key. That is, the point of encryption is privacy, and to have privacy, some method must be used to establish a key that only the parties in question possess. Publishing an encrypted document along with its private key doesn't accomplish anything useful, even though the document be properly encrypted.

The problem here is with the key establishment phase, because there is no evidence that you are establishing a shared key with the party that you want to talk to, rather than a malicious third party. Yes, "encryption" and "authentication" are two different things, but you can't do what "encryption" is short for in this context without having to authenticate first.

Similarly, in the pitch black room, you have "privacy" when you whisper your secret to the person who walks up to you—only you and that person know the secret. That privacy is useless, though, because you don't know whom you were being private with.

Wouldn't it be more akin to calling John via cell phone (self cert SSL) instead of yelling out what you want to say for all to hear (plain text)? Sure, somebody (at the phone company) could re-route the call and maybe they could also mimick John's voice, and maybe they later call John and spoof your caller ID and mimick your voice and relay to him what you said,

The difference is that doing all the things you describe is difficult, and there aren't publicly available tools for it. Being a man-in-the-middle in an SSL session established with an untrusted cert is easy. There are readily available tools for hijacking SSL sessions, and these tools keep getting better. Positioning oneself as a man in the middle is now easier than eve

Re:Seconded.

[cecil_turtle]

I appreciate the response. I think I'll still connect to my self-cert IMAP mail server via SSL rather than plain text. It also provides the added benefit of bypassing most content filtering firewalls :)

Clearly we have different ideas as to what is easy and what is difficult in pulling off an attack, and what is and isn't worth bothering to protect yourself against. A passive listener (Eve) seems to be much more common and very easy to protect against than an actual attacker (Mallory). If you're worried about that more aggressive attacker it seems to me that CA provided SSL isn't enough, you need to worry more about the endpoints as well. I totally get what you're saying about the availability of tools, but they're far from automated. Getting fragrouter/ettercap/dnsspoof/webmitm/wireshark/ssldump to attack/trap/decrypt/re-encrypt/pass all other traffic/store/filter data all at the same time, in real time, in two directions is not trivial. Maybe metasploit put something together I haven't seen. But setting up any of a number of different packet sniffers with a simple filter for "username" that will work for pop/imap/telnet/ftp/http/etc traffic is much easier; I could walk my mom through it over the phone.

The caller ID spoofing bit of the phone attack I described isn't that difficult at all actually, there are many websites that will do it for you easily - they have made the news from people being scammed and whatnot.

It all just comes down to your perception of the threat based on your own knowledge. That's why choices are good.

Re:Seconded.

[Antibozo]

I appreciate the response. I think I'll still connect to my self-cert IMAP mail server via SSL rather than plain text.

But presumably you've already added that certificate to your local store so it's trusted. And if you're providing that service for a number of users, why don't you buy a $15 cert from a cheap CA?

Clearly we have different ideas as to what is easy and what is difficult in pulling off an attack, and what is and isn't worth bothering to protect yourself against. A passive listener (Eve) seems to be much more common and very easy to protect against than an actual attacker (Mallory).

Again, Eve has to be on the network path, which few attackers are. Mallory can be anywhere if he can poison your DNS. Getting the DSniff stuff working is not difficult at all, and you don't even need that—a couple of stunnels connected by a logging script is sufficient. It's 20 minutes' work to set up. You don't even need to log both directions; client-to-server is where the credentials and credit card numbers are.

Understanding the threat requires considering more than the superficial difference in difficulty level between plain sniffing and setting up a man-in-the-middle attack. The potential reward to the attacker and the amount of effort required are important factors. With sniffing, the reward is small because you only have visibility on a small number of machines, and the effort required is large because you have to compromise a system on the network path for each victim, and monitor all traffic waiting for a few credentials to pass by. With a DNS-based man-in-the-middle attack, you just have to set up a proxy and poison a cache at one of the large ISPs and you can have literally hundreds of thousands of victims. The DNS-based attack can be targeted at the institutions you want credentials for, and you don't have to look at unrelated packets; the only traffic you see is directly related to the information you're looking for.

To me, it's obvious that the man-in-the-middle attack is a far, far larger threat, and I suspect the decision at Mozilla was informed at least in part by some advance knowledge of the Kaminsky DNS attack.

The caller ID spoofing bit of the phone attack I described isn't that difficult at all actually

Spoofing Caller ID was just one of the challenges in the attack you described. The attacker also has to be able to intercept calls and mimic at least two voices. If you want to talk about a scenario where the only authenticator is caller ID, then yes, I would agree that's somewhat like using a self-signed cert, though still perhaps more difficult to pull off than an SSL man-in-the-middle attack.

Not much to say

[JiminyJones]

Except that the entire issue somehow reminds me of Moby Dick

dumb

[oliderid]

looks like I will have to switch to internet explorer to access self signed https extranet. There are various cases where you do not need any third party to prove your identity. Firefox 2.X was already quite annoying with this. Firefox 3 seems to be even more.

Re:dumb

[Cheesey]

I suppose you could just add an exception for the site you want to access. (Four clicks?) Or your corporate IT people could add their signing certificate to the version of Firefox they distribute.

I don't understand the "antifeature" accusation at all.

Re:dumb

[Darfeld]

Not so much... You can accept certificate once and for all for a site, it's not that much annoying.

Well, the betta of FF3 was annoying because it wasn't clear how you could accept those certificate, but they fixed that. Now it's as simple as in FF2.

Re:dumb

[Anonymous Coward]

Jesus, what a Firefox cock sucker. You must like the taste of Open Sores jizzum all over your lips and mouth.

Re:dumb

[Anonymous Coward]

I'm going back to Telnet -- no pesky security certificates to worry about.

Re:dumb

[hal9000(jr)]

All browsers post a warning when a self-signed certificate that is not imported into the local certificate store is used. This is NOT a firefox problem.

You WANT to be warned when you have a self-signed certificate thrown at you. Let's say https://example.com/ has a trusted certificate (trusted meaning the signing CA or the self-signed cert is in the local store). If you get a self-signed warning, then you *know* there is a problem.

Re:dumb

[Z00L00K]

Not really a problem, just that the self signed certificate is unknown to your browser.

Don't forget that once it is installed it is no different from a well-known certificate and SSH uses the same approach by allowing you as a first-time user to accept the server signature and barf if it has changed.

Re:dumb

[iuyterw]

There are indeed various instances where ID verification isn't needed. I can't think of any though where encryption IS needed and ID verification isn't. How do you know you're sending your sensitive data to the right server?

Re:dumb

[sqlrob]

No, it's not as simple. I could do a one time exception very easily in FF2. Now it's easier to give a permanent exception.

Re:dumb

[Hyppy]

looks like I will have to switch to internet explorer to access self signed https extranet. There are various cases where you do not need any third party to prove your identity. Firefox 2.X was already quite annoying with this. Firefox 3 seems to be even more.

I'm sorry. You installed Firefox 2.x and Firefox 3. You read Slashdot. You are familiar enough with some web security and encryption lingo. But... you don't know how to add a site into the "Allowed" list?

Re:dumb

[illumin8]

No, it's not as simple. I could do a one time exception very easily in FF2. Now it's easier to give a permanent exception.

And this is actually more secure, because the permanent exception will become invalid if the certificate changes, i.e. if you're being attacked by a man-in-the-middle. How many of us use to use FF2 to connect to our self-signed administration websites and always just click "trust for this session" without verifying that the key didn't change? I know I for one actually feel more secure with FF3 because it allows you to easily make a permanent exception. FF2 had the annoying problem that if you make a permanent exception and 2 different administration websites you use had the same self-signed cert, they would conflict with each other and FF2's cert database/store would get corrupted.

Re:dumb

[DavidTC]

Yeah, and if FF popped up a message explaining that the website had presented a way to contact the same site securely in the future, although this did not confirm who they were, and ask 'if you want to store this code for the future, or just for this session, or not visit at all', that would be one thing.

Messages implying that it's somehow less secure than normal unencrypted web pages are another thing. Warning users, in big error pages and with sinister sounding warnings, when you are at least as secure as the dozens of unencrypted pages they visit every day, is just absurd.

Re:dumb

[DavidTC]

The problem is you've invented a world where all sites need verification. They clearly do not.

Slashdot, for example. You log in here, they have no SSL. Your password is transmitted in cleartext.

I would like my password to be encrypted so it's harder to see via traffic sniffing.

Re:dumb

[psydeshow]

Mod parent up.

We trust self-signing for SSH every blessed day. Why isn't it good enough to protect our privacy on the non-commercial web?

Re:dumb

[Slick_W1lly]

I suppose you could just add an exception for the >site you want to access. And what happens when the 'site that you want to access' is on your local network, accessible only by you and... there are hundreds of them. Take, for example, ILO's (remote consoles to blade machines using a web page). I have to add a fscking exception for *every single one* when I first go to it. When the number of machines you have is in the 100's - that's an awful lot of clicking for something I shouldn't *need* to do. Slick.

Re:dumb

[oliderid]

Yes, funny isn't it. I read slashdot for years, I develop web services since...1997? I use firefox for...mmmh 3 years and I have never touched this allowed list. I never had to.

Now...Let's imagine what would be the reaction of the lambda user. They'll think that those uncrypted server are more secure than those crypted ones with a self signed key. And this "allow" or exception feature is a very dangerous security breach.

One Question

[frodo from middle ea]

wouldn't implementing what the author suggest, defeat the very purpose of having a CA ? SSL is not just for encryption you know. There is a little thing called 'trust' which pays a big part in it too.

Re:One Question

[Anonymous Coward]

Exactly.

A "secure" and encrypted connection to a compromised or malicious server is worthless.

Re:One Question

[Iamthecheese]

It didn't make sense, the thing you just said. The author is proposing an easier flow to accepting self-signed certificates. How could that defeat the purpose of having a CA?

While he may have a valid point, I resent and disagree strongly with the author's implication that there is a profit motive to this. A bad decision, but not one made for profit.

Re:One Question

[adamwright]

If there was any real "trust" component, I'd buy this argument. SSL certificate authorities are supposed to be sources of trust - we trust them to have authenticated that the FooCorp who bought a certificate really is FooCorp Ltd (and not F0oCorpe). However, the only inducement most vendors need to issue a certificate these days is money.

I've successfully bought SSL certificates for companies that I had little or no verifiable connection with, from authorities that are trusted by all major browsers. Now, I obtained these with full permission of the companies in question, as a contractor, but as far as the authority was concerned, I was Joe Bloggs. They've even realised that now, and introduced the new EV Certificates - now with Extra Validation! Until of course, these get paid off as well, and we need EEV Certificates and so forth.

Using SSL for trust based on the word of companies like Verisign is pointless - you have to do manual authentication. The only use I see for them these days is transport encryption.

Re:One Question

[jgtg32a]

Do you really trust the CA? Its really not that hard to get a certificate, you pay them money and then they give you certificate.

Re:One Question

[gnasher719]

wouldn't implementing what the author suggest, defeat the very purpose of having a CA ? SSL is not just for encryption you know. There is a little thing called 'trust' which pays a big part in it too.

Absolutely. As a rule, leaving security to amateurs (and even more rank amateurs like the author of the article) leads to insecurity. This is like everyone else discussing how to protect your house from burglars who might try to sneak in by the most obscure routes, and here we have a guy who doesn't even complain that locks on doors are impractical, he complains that we should do away with doors in the first place.

Re:One Question

[Anonymous Brave Guy]

Sure, but frankly, anyone who relies on the "trust" aspect of SSL certificates today for anything serious needs their head examined. In this world, trustworthy == willing and able to pay.

The encryption is by far the most important aspect of SSL for most applications, and you can use that regardless of any issues with CAs and trust.

Re:One Question

[pmontra]

CAs do very little to ensure that the site you're connecting to is really the one it claims to be. So SSL is almost useless for authentication and trust. It's worth using it only for encryption and self signed certificates are as good for that as the ones you buy with money.

As a webmaster and owner of a site that uses SSL I second the author's proposal and more: let's stop pretending CAs can ensure the identity of the communicating parties, shut them down, save money and use SSL only for encrypting data.

Re:One Question

[morgan_greywolf]

I've successfully bought SSL certificates for companies that I had little or no verifiable connection with, from authorities that are trusted by all major browsers. Now, I obtained these with full permission of the companies in question, as a contractor, but as far as the authority was concerned, I was Joe Bloggs.

Same exact experience here. And the thing is that they don't even bother calling anyone to verify anything. I've even used my own credit card to buy certificates.

Re:One Question

[Nursie]

No, the certificates verify that you are talking to whoever the CA gave the certificate to. That's all they do, and that's very important. You don't have to go any further than that.

Re:One Question

[duffbeer703]

Newspapers can get the news wrong. Does that mean that we should only accept news heard via word of mouth?

Even with a minimally verifying SSL provider, the police do have some ability to track a transaction back to a specific individual or company via the payment trail. Or they can use a stolen credit card, which is easy to detect.

Re:One Question

[Nursie]

No.

Seriously, stop being a retard.

If I'm connecting to my bank, and I get a certificate that matches the domain name and was signed by a widely trusted 3rd party, that gives me much more confidence than selecting some bozo's self-signed certificate.

Does it guarantee the identity and trustworthiness of the entity? Not absolutely, but it's a whole hell of a lot better than just encrypting comms and sending them to whoever happens to be running a man in the middle attack today.

Re:One Question

[Rakishi]

The problem with this is that it does not guarantee that your connection is actually encrypted. There is a reason why CAs where created and it has a lot to do with ensuring proper encryption. Basically a man in the middle attack can with self-signed CAs fake the user into accepting their CA instead of the website's CA. You now have the illusion of security and encryption which some would consider worse than no encryption at all. To the end user they would be identical and while there may be a complaint about different keys, if the user went to the site before, most users would probably ignore them (especially after they seem them a dozen times for legitimate sites that for some reason changed their keys).

Re:One Question

[Nursie]

That depends what you're trusting.

Are you trusting that because they guy at the other end has e certificate that he is an honest trader and to be trusted with your money?

Bzzzzzzt. You deserve everything you get.

Are you trusting that you're talking to the company you thing you're talking to and nobody's listening it? Because that's what it gives you.

Re:One Question

[Anonymous Coward]

There should be no "flow" to accepting self-signed certificates at all. Users do not verify the authenticity of self-signed certificates. If a website presents such a certificate, the connection should automatically be encrypted, but there should be no visible indication that the connection is any more secure than an unencrypted connection, with two exceptions: When you actively open the page info dialog and when the certificate is different than what the site presented in previous sessions.

Re:One Question

[Anonymous Coward]

with mastercard?

Re:One Question

[Ed Avis]

The question you should ask is why is a website using a self-signed certificate presented to the user as *less safe* than one that is sending all information in the clear?

Re:One Question

[gbjbaanb]

stolen credit cards can be easy to detect... but can also be very easy to miss. If the charge is less than a certain amount, most CC software processes it directly (and if it turns out to be stolen, too bad, the acquirer refuses and the merchant takes the few dollars hit). The idea is that the cost and time of processing the small amounts aren't worth the bother. I think the acquirers also mandate it - possibly not nowadays in the super-fast always-on networks we have, but in the days when authentication was via dial-up they'd have been saturated with connections for every $5 transaction.

The other factor is that sometimes stolen cards aren't marked as stolen for some time - if I lost my wallet this morning, I wouldn't know about it until I came to pay for lunch.

So, considering you can get a certificate via bogus means, how does this apply when it gets revoked shortly afterwards. I mean, you do have all up-to-date CRLs installed on your browser don't you? Or use OSCP. IE6 doesn't support it, but IE7 does... but only on Vista. There were problems with OSCP on FF2 (and the advice was turn it off), so I don't know how many FF3 installs there are with it still turned off (just check... mine included!)

Re:One Question

[lucifuge31337]

This is exactly the point I was going to bring up. If you have access to install a certificate on a web server, you most likely have access to an admin-like email address, which is really all that is needed to get a "trusted" cert. One of the companies I use will validate by email to a domain contact or alternately to root@, postmaster@, webmaster@, admin@, etc. (a list of about a dozen they will accept).

SSL is useless for initial authentication, however, like most SSH implementations, if it were made easy to accept the cert and then you got an exception if and when the cert changes (DNS attack, mitm, site pwned, etc.), I would find it useful. Of course, "average users" would probably not find this behaviour in any way meaningful.

Re:One Question

[norton_I]

No, the certificates verify that you are talking to whoever the CA gave the certificate to. That's all they do, and that's very important.

That is of no value whatsoever if they will give the certificate to anyone. It is just as true for a self-signed certificate--it verifies you are talking to the person who generated the certificate.

The $10 certificates are a giant boondoggle, a business that shouldn't exist except for misguided policy decisions on the part of browser developers.

Re:One Question

[locofungus]

Exactly.

A "secure" and encrypted connection to a compromised or malicious server is worthless.

Exactly! My accountant needs some documents from me. Rather than email them I have them up on a secure site. If my accountant connects to the wrong site I really don't care, he's not going to find the documents he needs so he's going to give me a call and ask where they are.

Self signed certs are for when you want to do the encryption but you're doing the authentication via other means.

I've used this in the past (although not to my accountant).

At the very worst, a self signed certificate is no worse than a plain HTTP connection.

If we didn't have plain HTTP at all then we would consider sites using self signed certificates as secure (or insecure) as a plain HTTP connection.

Tim.

Re:One Question

[jellomizer]

while there are decent standards many free and open use to keep your idenity hidden, there isn't any good way to proove you are who you say you are. At least if you are willing to pay a couple hundred bucks to someone with some minimal proof they are who you say you are it is better then nothing. We are stuck with it unless we can find an open standard that can proove you are who you say you are.

Re:One Question

[Nursie]

"It is just as true for a self-signed certificate--it verifies you are talking to the person who generated the certificate"

No it doesn't.

Not if you haven't pre-distriuted the associated authority public key it doesn't. It doesn't verify anything.

"The $10 certificates are a giant boondoggle, a business that shouldn't exist except for misguided policy decisions on the part of browser developers."

No, they're not.

You have a choice -

a) Distribute your authority certificate to your users ahead of time, so that they can be sure who you are
b) Suck it up and pay 10$ for someone else to do it for you.

a is probably the best option, but it's currently not practical. b is the next best.

Just getting users to accept self-signed server certificates is very bad, because it trains them to accept them, and they'll get phished.

Re:One Question

[Urkki]

CAs do very little to ensure that the site you're connecting to is really the one it claims to be.

So, are you claiming that you could get a recognized CA certificate for a domain that I own? If you can't, then there's enough security to achieve what is supposed to be achieved.

As a webmaster and owner of a site that uses SSL I second the author's proposal and more: let's stop pretending CAs can ensure the identity of the communicating parties, shut them down, save money and use SSL only for encrypting data.

The thing is, you can't have secure encrypted connection without authorization, because of man-in-the-middle attack vector. Ie. your encryption is really only as secure as your authentication.

SSL with insecure authentication provides only insecure encryption. Then SSL encryption is only as secure as SSL authentication.

To "use SSL only for encrypting data" is not an option, if by "encryption" you mean reliable end-to-end encryption, with no eavesdropping and no modifying the transmitted data by a man-in-the-middle. Really.

Re:One Question

[pmontra]

Does it guarantee the identity and trustworthiness of the entity? Not absolutely

So again, what's the point with CAs?

As you said, it doesn't guarantee the identity of the remote site. An attacker can buy a certificate for www.yourbank.com (easier if he's an insider and has a mail @yourbank.com), poison your ISP's DNS cache and redirect your SSL traffic to his site.

I'll trust CAs a bit more when they'll come to my office to deliver my servers certificates. They're pretty useless until then.

To the modders: IMHO this thread is't mean to be a flamebait.

Re:One Question

[shaitand]

From TFA:

'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'

He is right. Since when is security an all or none affair? Security is about making it more difficult to attack with the understanding there are always attacks you can't protect against. An alert saying that 'a secure connection is established but the identity of this website has not been verified by a central authority' (and an option to add to a domain whitelist) would even be ok to make the distinction but not the current prompts which more or less say the site is a scam.

The bigger problem is that there is an open CA that verifies ownership of the domain and firefox does not include them. Verifying domain ownership is all numerous commercial CAs do including godaddy and frankly, is all most of us expect a cert to be good for in the trust department.

Re:One Question

[MightyYar]

If my accountant connects to the wrong site I really don't care,

That's not the problem. The problem is that a man-in-the-middle can snag your documents if your accountant accepts a self-signed certificate.

Re:One Question

[shaitand]

Agreed. And there is an open CA that the major browsers don't include in their root list either.

It verifies DNS control. That is more than some of the cert whores and really all I need a CA to verify since it prevents man in the middle attacks.

Even a self-signed cert is dramatically better than an unencrypted connection. Security is not an all or none affair, encrypted is better than unencrypted, and encrypted and trusted is better than merely encrypted. The current prompts make it appear as if unencrypted connections are safer than encrypted!

Re:One Question

[Anonymous Coward]

Ah, but as soon as there is profit involved then a motivating and corrupting element exists. See Network Solutions and the early days of the world wide web for more.

Re:One Question

[MightyYar]

Actually, in a fresh install you get a popup that warns you when you try to send an unencrypted form. Stupidly, they make the default to display the message only once, which is why you forgot about it. :)

Re:One Question

[Z00L00K]

And the bank may still have it's own CA or use a self-signed certificate. That will also work fine, but only if the bank provides you as a user with sufficient information regarding this.

See this as an analog with the SSH solution.

Re:One Question

[shaitand]

That doesn't fit here. The self-signed certs provide an encrypted connection. This is like having locks locked on the windows and doors (encryption) but no monitored alarm system (additional identity verification).

Currently, the browser makes it appear as if having locked doors is less secure than having unlocked doors. You can check yourself, go to an unencrypted site and note the lack of any warning suggesting wrongdoing on the site owners part, now go to a self signed one which will result in prompts that all but tell you to cancel your CC and call 911.

Re:One Question

[shaitand]

I agree, domain verification is useful and should not be done away with entirely.

I don't agree with the current policy though. A simple notification saying the connection is encrypted but the domain identity isn't verified by a 3rd party with a box to not show this again would be fine. Currently the popup goes as far as to say that the site is not legitimate!

Also, this CA 'https://www.openca.org/' does verify you have control of the domain. Why is it still not included in the browser by default?

Re:One Question

[tepples]

You now have the illusion of security and encryption which some would consider worse than no encryption at all.

Some would. The point of the article is that others wouldn't.

Re:One Question

[Eivind]

Reading the article would be good, ya ?

The articles main complain is that the way FF does thing by default a website secured using a self-signed https:/// certificate looks MORE scary and LESS secure than the very same site using http:/// and no certificate whatsoever.

That, the author argues, is wrong. True, a https:/// site *with* a certificate is even better than one without one. But BOTH are more secure than simply using http:///

So, it makes little sense to make self-signed https:/// look MORE scary that http:///

I agree.

Re:One Question

[norton_I]

No it doesn't.

Yes, it does. The problem you are seeing is that the person who generated the certificate could be anybody. But the same is true for the cheap CAs--they will sign a certificate of basically anyone who asks. So you know that you are talking to the person they gave the certificate to, but that could be anyone. The $10 certificates are a waste of money since they don't prove anything meaningful.

Just getting users to accept self-signed server certificates is very bad, because it trains them to accept them, and they'll get phished.

I agree. What browsers should do is accept self-signed certificates without prompting and make the UI clearly display the difference between encrypted (has https in the URL but displays no signs of authentication) and authenticated (yellow/green URL bar, padlock closed). Then, drop support for all the discount CAs that provide worthless certificates.

Re:One Question

[pmontra]

You're right from a technical point of view (I've read this discussion about SSL and MITM attacks) but my point is that we can't trust CAs in the real world.

The one I'm using had no idea of who I was when I bought a certificate from them for my server. They only knew that I was responding to an email address that matches the name of my company, which they never heard about and probably never will.

Certificates are something we have to buy to let our customers think we're caring about them but they have very little value for ensuring the identity of our servers.

Re:One Question

[Nursie]

The point is that

1) They should't be doing that. And if he's an insider then he'll get caught.
2) This hasn't yet happened as far as I know
3) Without CAs the guy doesn't have to go through getting the thing, which most likely will be caught as yourbank.com is already taken, and yourbank.com is a known entity and they should (and it appears they do) have better procedures than to sell multiple citibank certs.

I agree that it would be better for them to take a lot more precautions, but they're currently the best we've got.

UNLESS you want to do things in-house and take responsibility for distributing the trusted root certificate for your own CA to those that need it. That there is the best option, but most folks don't want to do that and for yourbank.com it would be a big expense to make sure all the customers received this cert in an offline/secure way.

And yes, it's not meant to be flamebait, I just need more coffee this morning and to stop throwing the invectives around...

Re:One Question

[shaitand]

Not really, you can easily buy 'legitimate' certs certifying you are a company you have nothing to do with.

Certs don't verify you are talking to who you think you are in reality. Certs should verify you are talking to the DOMAIN you think you are. But a self-signed cert is better than no cert so there certainly shouldn't be more stringent notifications than there are for completely unencrypted pages. Further, open and free ca like https://www.openca.org/ should be in the root trust of the browser, since they verify domain ownership.

Re:One Question

[Nursie]

It's only really useful if you can guarantee you're safe the first time.

Pre-distribution of a trusted root (or even the md5sum of a trusted root) would be fine. But that's basically what you pay the CAs for.

Re:One Question

[Anonymous Coward]

I don't understand that. How can an attacker buy a cert for mybank.com and make it work? Wouldn't he have to force the origional dns entries for mybank.com to return his rogue webserver so that he can now hand out his own bogus mybank.com certificate? How does it really work to have multiple certificates out there for the single entity mybank.com?

Re:One Question

[cryptoguy]

There are lots of times when SSL is used for less than its complete feature set. SSL provides a mechanism for *mutual* authentication, but how often does the server actually require a verified SSL certificate from the client? The fact that servers usually don't do this does not mean SSL is not useful in that context. Likewise, the absence of a verified server side certificate does not necessarily mean that SSL is providing no value. Encryption without authentication provides a degree of privacy, raising the level of difficulty significantly for anyone who would want to eavesdrop. When a client encounters a self-signed certificate, or when the certificate is a type that is weakly verified by the CA, the client should simply notify the user of that fact. That can be done with a single notifier. The notifier can provide the user the option of verifiying the certificate out-of-band so it will be trusted next time without a nag screen.

Re:One Question

[Ed Avis]

Actually, in a fresh install you get a popup that warns you when you try to send an unencrypted form.

Yeah, I remember that; everyone turns it off.

I'd like to see a warning only when you enter something that resembles a credit card number or bank account number (basically if the form contents contain more than six digits). Yes, I know phishing sites can work around this, but (provided Javascript permissions are set appropriately) only in bizarre ways that would alert the user something is wrong.

Re:One Question

[Firehed]

No. The accountant doesn't have the documents for the man in the middle to intercept (this is a one-way thing, from the poster's description), and obviously he wouldn't find them by connecting to a hijacked server. The most that a MITM attack could gain for the attacker is what files the accountant is looking for provided that this was set up as some odd search-based system rather than some equivalent of a directory listing. On the other side, the man in the middle COULD intercept documents that you're *putting on* the server if the box/cert became compromised.

Re:One Question

[GrenDel Fuego]

If there was any real "trust" component, I'd buy this argument. SSL certificate authorities are supposed to be sources of trust - we trust them to have authenticated that the FooCorp who bought a certificate really is FooCorp Ltd (and not F0oCorpe). However, the only inducement most vendors need to issue a certificate these days is money.

An SSL CA is only supposed to validate that the person requesting a certificate for authorized to request for that domain, not that its tied to any particular company. If I own bankoamerica.com, then they're supposed to issue a certificate to me.

EV certs were created to combat the phishing issues that were not a problem when the CA process for normal certs were created. EV certs tie a certificate to a verified legal entity. I believe the rules allow for the cert to be tied in a person, but last time I dealt with EV cert policies (a year or so ago), the companies I talked to only had processes in place for validating corporations.

If I had a company which owned bankoamerica.com, I could probably still own a cert for it. If I do something nefarious with it, people would know just where to find me. Bank of America would probably consider just the act of owning it nefarious.

Now the lack of validation of authorization for a domain that you mentioned can be an issue for SSL certs, but its a separate issue. Any CA which does not properly check that you're authorized to buy an SSL cert for a domain should have their CA cert revoked IMHO.

Re:One Question

[Nursie]

No, SSL (well TLS) is not useless for authentication, not in the slightest.

If you're going to argue that you don't trust the CAs, then that's one thing, but I won't have you slandering an entire family of protocols just because you don't like the policies of a few companies!
TLS is great, and TLS is very secure, IF you take an interest in what's going on.
If you just want certificate change detection then your browser is good for that too, but expect to get a nice fat warning the first time.

The problem here is not the protocol, and it's not the browser behaviour, it's the CA behaviour.

Re:One Question

[Nursie]

I don't think that's enough.

It needs to interrupt the flow of what the user's doing, and significantly, so they actually think about it.

Dropping low-rent CAs is a good plan though.

Re:One Question

[beyondkaoru]

government issued incorporation-time signatures -- would this perhaps help?

we already have to trust the government on documents of incorporation. could we add an extra field to the paperwork to include a public key's fingerprint?

Re:One Question

[bickerdyke]

So.. no authentification? Great Idea. So everyone who stumbles upon that "secure" URL can download those confidental documents. But at least over an encrypted link.. So as you said: you need some other form of credentials. I guess you'd go with a htaccess-password. Now you need a secure channel to get that password to your accountant. (phone) "Hello Mr. Accountant, this is Bob. You recognize my voice, right? ok, to check your identity for downloading those documents use User foo with password bar on my website. To check MY identity, compare the SSL-Fingerprint with de:ad:be:ef." So.. where's the problem? Or in short: Encryption without authentification doesnt give you (or your site visitors!!) a secure channel to someone. (yourself or your visitors) It gives a secure channel to ANYONE (on BOTH ends of the connection!)!

Re:One Question

[Nursie]

No, it makes a lot of sense.

You still shouldn't trust sending financial info over an unauthenticated connection. Or (increasingly) anything at all, as it could be your ISP listening in, as they increasingly seem to want to do.

People who don't understand anything about security (or computers) will be phished all the more easily if they get used to seeing self signed certs. People who have just enough knowledge to be dangerous will also think they're somehow safe. They aren't.

Re:One Question

[Urkki]

I did not say anything about FF. I did not respond to TFA. I only criticized what I quoted: the implied claim that anybody could get a proper certificate for a domain that I own, and the impossible suggestion to "use SSL only for encrypting data".

Reading the message you respond to would be good too, ya?

Re:One Question

[Nursie]

"The self-signed certs provide an encrypted connection."

No they don't.

Look up Diffie Hellman (DH or DHE key exchange in SSL or TLS). They don't provide encryption. In fact asymmetric encryption with certificates is computationally expensive and discouraged.

The only this a self-signed certificate gives you that a certificate-less connection gives you is the assurance that you are talking to the same guy as last time you tried, or at least someone with his private key.

Re:One Question

[Midnight Thunder]

It didn't make sense, the thing you just said. The author is proposing an easier flow to accepting self-signed certificates. How could that defeat the purpose of having a CA?

I am just thinking of something like Linked-in or Facebook for certificates. You create a network of trust and you could see visually who the web of trust is associated with. That way you could self-sign a certificate, but get a friend to trust it and in turn you vouch for trust his/hers and so on. Certain entities might trump this web, such as paying entities, since this creates a a financial record identifying who the party is.

Re:One Question

[Firehed]

Firefox 3 already does this, to a degree. Plaintext (http) has a white address bar and favicon. Unverified certs change the favicon to a blue background, and verified (example) turns it green. On any of them, you can click the favicon to get expanded details.

The problem is that it's not especially obvious, and that it has very little meaning to most people even if they do notice. The only way that people will notice without a doubt is to make self-signed certs as obtrusive as they currently are - block the page entirely and proceed on if you allow an override. That doesn't fix it having little or no meaning to most people, but that's an entirely separate issue.

Re:One Question

[Nursie]

Much of the time they are, given that it's usually phishing sites that will try to encrypt but can't authenticate.

Re:One Question

[fbjon]

I find the article to be rather flamebaity, actually. What he really means is: the interface for self-signed certs should be less heavy on the fear-speak.

After that, a lot of ranting, saying that Firefox's behaviour is somehow incorrect, that Firefox should be forked if this doesn't change, all the while offering no solution whatsoever.

Meh!

Re:One Question

[MightyYar]

The accountant doesn't have the documents for the man in the middle to intercept (this is a one-way thing, from the poster's description), and obviously he wouldn't find them by connecting to a hijacked server.

I don't think you understand how man-in-the-middle would work here.

His accountant would connect to the fraudulent server, which would give him a self-signed ssl certificate. It would then connect to the legitimate site using his credentials and display whatever the legitimate site would display. Anything available to the accountant would also be available to the man-in-the-middle, by definition - and the site would work just fine from the accountant's perspective, so no suspicion would be aroused.

Re:One Question

[Nursie]

"But a self-signed cert is better than no cert"

Only in that you can tell it changed from last time. Otherwise using authentication-less SSL is just as good.

What you really want is to act as your own CA and then make sure your users get your trusted public certificate ahead of time and in a secure way.

Re:One Question

[Anonymous Coward]

If you trust the creator of the self-signed certificate, where's the problem? A 3rd party CA is only necessary when there is no prior trust between the parties.

Re:One Question

[Firehed]

This is why I like how my bank handles their online banking. Beyond the SSL cert (which ironically has some missing info causing a blue rather than green info pane in FF3), their login system is a two-stage thing. I give them a username alone, they send me back an image and phrase that I set when creating the account in addition to the password field. If the image or phrase is wrong, then I know something is up.

Infallible? Of course not. But it makes me feel a HELL of a lot better than AmEx, which (aside from their awful interface) does the typical login interface, but upon sign-up forced my password to have between 6 and 8 characters and I still haven't found the link to change the password. Why anyone would EVER limit a password to any maximum size is well beyond my scope of understanding, let alone one of the world's largest financial companies. Given that approach, I wouldn't be entirely surprised to find a VARCHAR(8) `password` field in their database.

Re:One Question

[lucifuge31337]

The problem here is not the protocol, and it's not the browser behaviour, it's the CA behaviour.

I agree. And when you look at the real world, and not an idealized version of what it should be from ietf.org, you see that it is broken beyond reasonable repair as far as authentication is concerned. The protocol IMPLEMENTATION is broken, as "a few companies" can break the entire thing for the average user.

Re:One Question

[Firehed]

You're right. I somehow mistranslated the MITM attack to a hijacked box and/or some sort of redirect where the accountant would never actually communicate with the intended server.

It's Monday morning and I hadn't had any coffee yet.

Re:One Question

[init100]

According to the Wikipedia page on TLS, there is a draft specification for using OpenPGP certificates instead of X.509 certificates with SSL/TLS. And as you might be aware of, OpenPGP uses a web of trust model.

Re:One Question

[pmontra]

Agreed, every extra step makes things more difficult for the casual attacker, but the big bad boys will run away with the money before getting caught.

UNLESS you want to do things in-house and take responsibility for distributing the trusted root certificate for your own CA to those that need it. That there is the best option, but most folks don't want to do that and for yourbank.com it would be a big expense to make sure all the customers received this cert in an offline/secure way.

My bank mailed me a SecureId key months ago. They could have also added their own CA certificate, which any attacker could get anyway by simply opening an account with them.

And yes, it's not meant to be flamebait, I just need more coffee this morning and to stop throwing the invectives around...

Nice to see that your score has been upped to 2 and the post changed to Insightful :-)

Re:One Question

[illumin8]

The author is proposing an easier flow to accepting self-signed certificates. How could that defeat the purpose of having a CA?

The problem is that Mozilla is trying to balance the needs of non-educated consumers who have been the victims of these sophisticated phishing attacks against the needs of more educated geeks like ourselves who know what we're doing when we setup self-signed certificates.

This is a legitimate question... How much security do we need? I think they've struck the right balance.

There is no conspiracy here. Mozilla is not trying to put your "free" website out of business. It's perfectly valid for them to give a lot of warnings, and I think their method of adding a self-signed certificate and then never being bothered about it again is highly usable, and easier to use than the previous method in Firefox 2.

Re:One Question

[Anonymous Coward]

Not necessarily.

If you don't view the separation between authentication and encryption, but instead view it from the average person point of view (SSL = secure) - there is a problem with "perceived trust". The user has no expectation of security over normal HTTP whereas they have an expectation of security over HTTPS. While a self signed cert still gives encryption, if they aren't in a position to know what it means when the cert changes, they're better off thinking the entire connection is untrustworthy than to give trust.

Re:One Question

[shaitand]

What I really want is for there to be no charge for encrypted connections and EVERY web connection to be encrypted in a fashion that assures that only I and the party I am communicating with can read the communication. If i can be sure that the machine I am communicating with is the machine I think it is then that would be a nice bonus.

As far as I am concerned there is no need for clear text surfing.

Re:One Question

[lbschenkel]

I don't agree. A false sense of security is worse than no security. By using a self-signed certificate I have no idea if I'm encrypting the data to the right recipient.

Of course, I still can validate the certificate via an out-of-band mechanism. In Firefox 3 I can validate and accept it with 4 clicks instead of one. So what? This is something I should do very seldom for a specific web site. Four clicks are even better than one because it forces me to *think* before accepting an unknown certificate and potentially exposing myself to men-in-the-middle attacks.

Do you think that the average user knows what a certificate is and how to validate a self-signed one out-of-band? Most users were just clicking "Accept" and unknowingly exposing themselves to MITM attacks. Then they saw the padlock and thought they were safe, when in fact they could be getting *zero* protection.

If you don't want average users to be scared, then don't use self-signed certs. Don't use SSL. Average users don't validate self-signed certs anyway, so it's better for them *not* to have a padlock and be aware that they are getting *zero* security.

If your users are tech-savy enough to know how to validate a self-signed cert they will know exactly how to proceed when they get the warning in Firefox 3.

Re:One Question

[DaveV1.0]

The problem with your assertion is the following:

Now, I obtained these with full permission of the companies in question, as a contractor,

This says you had permission to obtain the certificate. Therefore, you had a verifiable connection with the company. The certificate company could have contacted the company and asked if you were allowed to obtain a certificate on their behalf.

Re:One Question

[blacklint]

Or, I could walk down to Safeway, buy a $25 Visa Gift Card with cash, and have a perfectly valid non-traceable payment method. Hurrah. Secure.

Re:One Question

[r7]

Using SSL for trust based on the word of companies like Verisign is pointless - you have to do manual authentication

I wouldn't say it is pointless but it is not a panacea. Let's not forget that the sometimes dysfunctional methods browsers use to handle SSL certificates are an artifact not of security but of monetization. We can thank Verisign and Netscape for this, as they designed it that way back when Netscape granted Verisign an exclusive on browser certificates. Verislime milked this monopoly for all it was worth (as they did with domain registration about the same time). This is is one of the features IE improved on, and one of the reasons it eventually put Netscape out of business.

The sad part of all this is that Verislime still charges big bucks for worthless "premium" certs (at a 99% markup) and people are still foolish enough to purchase them. Worse is when open source browsers support this kind of "security theater" even though it only benefits a small number of providers and their unethical business practices.

Re:One Question

[devman]

I disagree. HTTPS:// with a self-signed cert would give a false sense of security to an unknowledgeable user, which is more scary than a no security implied HTTP:// connection.

Re:One Question

[blacklint]

Precisely. But there's no way to use authentication-less SSL with HTTP, is there? (At least that a normal use would understand, no tunneling.) And that's the problem.

Re:One Question

[Anonymous Coward]

The use of self-signed certificates is a no-no because the user gets a security related dialog. This should not happen. A self-signed certificate should be used for encryption without user interaction. The user should not see any indication that the connection is secure, because it is not.

Re:One Question

[Wdomburg]

Why on earth would you need to courier deliver a certificate?

Re:One Question

[MSG]

'This ignores the value of simple encryption.'

Encryption is worthless if you don't know who you're connected to. If you're on a wireless link, those guys who can so easily snoop your traffic can also hijack your connections and launch MITM attacks. Trust is more important in untrusted networks, not less as you imply.

Re:One Question

[Nursie]

"What I really want is for there to be no charge for encrypted connections and EVERY web connection to be encrypted in a fashion that assures that only I and the party I am communicating with can read the communication. If i can be sure that the machine I am communicating with is the machine I think it is then that would be a nice bonus."

It's not a nice bonus, it's the only guarantee you're not broadcasting your data to a cracker/phisher/whatever. You almost may as well not bother with encryption otherwise. Sniffing attacks are (AFAIK) rare. DNS redirection seems to be quite possible right now.

In other comments there was an open CA mentioned that give away certs for free and have their CA certificate in ... here it is - http://cert.startcom.org/

The only reason that plaintext browsing should still exist, IMHO, is because we don't need security on everything and the extra processing overhead on large (or small) sites could be a killer.

Re:One Question

[GleeBot]

Likewise, the absence of a verified server side certificate does not necessarily mean that SSL is providing no value. Encryption without authentication provides a degree of privacy, raising the level of difficulty significantly for anyone who would want to eavesdrop.

Except it doesn't, because if you can't trust the certificate the server offers, you've left yourself completely open to a man-in-the-middle attack.

Alice and Bob want to communicate via SSL. Bob creates a self-signed certificate for www.example.com.

Now Carol can't duplicate Bob's certificate with his presumably secret private key, but she can create her own self-signed certificate for www.example.com. Then she hijack's Alice's DNS (perhaps using the recent DNS cache poisoning exploit) to point to her server instead of Bob's, then transparently proxies between Alice and Bob (since Bob doesn't verify Alice's identity, either), intercepting all communications.

If Bob's certificate was signed by a known authority, then Carol couldn't trivially create another certificate that claimed she was www.example.com, too, preventing this attack.

Self-signed certificates with unknown parties are pretty much tantamount to no security at all; the encryption can't be relied on for more than obfuscation. Probably the only good use for self-signed certificates is when you can get the certificate via a secure channel (and no, accepting the certificate via a browser dialog isn't a secure channel). Obviously, this approach doesn't scale.

Re:One Question

[Anonymous Coward]

"While he may have a valid point, I resent and disagree strongly with the author's implication that there is a profit motive to this. A bad decision, but not one made for profit."

How do you know what the motivation was?

Re:One Question

[VGPowerlord]

Unless you're using Firefox 2, in which case it's yellow for both unverified and verified certs.

We use Firefox 2 / Internet Explorer 6 where I work.

Re:One Question

[muckracer]

> there is a draft specification for using OpenPGP certificates
> instead of X.509 certificates with SSL/TLS. And as you might
> be aware of, OpenPGP uses a web of trust model.

It's a good idea in theory and one I'd like to like more than the CA setup on principle.
A question I'd have though is this: How do you verify via web of trust the key (and now SSL cert as well) of a company?
The chain of signatures would have to be very long indeed, I'd imagine, and given the current use of GPG etc. for mail I don't see that happening anytime soon.

Personally I still like the SSH-style approach of showing the fingerprint on first connect and giving you a choice of accepting it/the key or not. If you do accept it a warning gets shown if ever in the future the key is not the same anymore. Seems pretty reasonable to me for most minor to medium threat-scenarios. Never had a different key/fingerprint on first connect via SSH, Instant Messenger (OTR and Pidgin Encryption) or similar...

Perhaps a combination of the two would do...

Re:One Question

[Intron]

Maybe because Mozilla publishes their motivation.

# We will not charge any fees to have a CA's certificate(s) distributed with our software products.

Re:One Question

[Anonymous Coward]

Have you ever heard of caller id?

Myself, I'd just write the fingerprint down and take it to my accountant's office. If your accountant is far away, you could have it notarized and sent via registered mail or even armored car if your paycheck is really that big.

Transmitting a bit of confidential information is an old and solved problem in the physical world.

Re:One Question

[DavidTC]

Mod parent up. This is exactly what everyone's been saying.

Although I won't mind a little yellow bar at the top of the page that notifies you that the cert has been saved and lets you mark it as trusted or remove it or whatever.

Re:One Question

[drew]

So I'd get a warning every time I try to submit my phone number to a web site? No thanks...

Re:One Question

[muckracer]

> A false sense of security is worse than no security.
> By using a self-signed certificate I have no idea if
> I'm encrypting the data to the right recipient.

By not using any encryption you also have no idea if you're sending your data to the right recipient. So did the self-signed cert make anything worse? No, it didn't. At worst you're exactly back to square one where you would have been HTTP'ing from anyway. And the false sense of security for most people starts already when they open the browser or their E-mail program....

Re:One Question

[Chandon Seldon]

Self-signed certificates with unknown parties are pretty much tantamount to no security at all; the encryption can't be relied on for more than obfuscation. Probably the only good use for self-signed certificates is when you can get the certificate via a secure channel (and no, accepting the certificate via a browser dialog isn't a secure channel). Obviously, this approach doesn't scale.

Snooping a connection is a hell of a lot easier and more common than hijacking one. Hell, if someone can arbitrarily hijack connections, they can get themselves a completely valid SSL certificate by demonstrating their (hijacked) control of the domain to some minor CA.

There are no perfect answers to these security problems. But there are wrong answers - and requiring website owners to always sign up and be approved before they can use the HTTPS protocal on a public website is a wrong answer.

Re:One Question

[spectre_240sx]

A .htaccess password would not work well here. In this case, we're talking about authenticating a server, not a user.

Imagine the following:

1. User creates a secure connection to a malicious web site.
2. The compromized web site prompts the user for their credentials, which the user enters.
3. The malicious website now has the users credentials.
4. Depending upon the complexity of the transactions, the malicious site's server could forward the user with credentials to the site and they would be none the wiser. Later, the credentials are downloaded and the attacker can get whatever they want.

Re:One Question

[CastrTroy]

I think an OpenPGP model would work a lot better. You go down to the bank, and pick up a disk with their public key on it. Only accept keys from those you really trust. That way you can't end up at mybank.example.com which happened to get a certificate for *.example.com, and mistake it for your bank, with a real signed cert that your browser just automatically trusts. The number of sites that you should actually trust with a secure connection is probably quite small. Your bank, your credit card, I don't even know if most other people would have any other ones. Ideally, when you purchase something from an online shop, you wouldn't even send them your credit card information. Just a signed cert from your bank or credit card company (the store would have their public key also) stating that you had authorized money to be transferred to their account.

Re:One Question

[cryptoguy]

Self-signed certificates with unknown parties are pretty much tantamount to no security at all; the encryption can't be relied on for more than obfuscation.

Sometimes obfuscation is all you need. The proper choice of countermeasures depends on the threat and the value of the information being protected, and on the cost of the countermeasure.

Re:One Question

[CastrTroy]

It's good that it makes you "feel" better, but I don't think it does much to add any security. It's trivially easy for the MITM to forward you login ID to your bank, and pick up the picture they showed you, and forward the picture to you, so that you think you are actually on your bank's site. You might want to read about Bruce Schneier, and his open wireless network. Assuming you have security when you really don't is more dangerous, then knowing you are insecure in the first place.

Re:One Question

[Znork]

You now have the illusion of security and encryption which some would consider worse than no encryption at all.

And the current state of CA's make things different how? Besides the social engineering aspects, I'd be hard pressed to come up with a government TLA I don't think could obtain signed cert for basically whatever they want.

And if you are compromising the CA and running an MITM there wouldn't even be a complaint about different keys; even worse than the self-signed situation.

Trusting a CA today just means you're compromising your limited trust relationship by adding an untrusted third party.

Frankly I'd rather see an ssh type exchange-keys-on-first-meeting and build trust from there; connect to a new site and you get the choice to add the domain CA. For important things like banks you could get it via physical mail. Even better would be web-of-trust type security, and/or/complemented with having multiple independent CA's sign off on a certificate, at least allowing levels of trust and fewer single points of failure.

I do find it rather fascinating how many appear to be fine with trusting corporations like the CA's and anyone willing and able to apply pressure to them. Basically the structure encourages something that's not much different from the various "if you want to encrypt anything you need to hand the government your keys" schemes that have been suggested.

Re:One Question

[squiggleslash]

It isn't doing anything of the sort. What the browser is doing is saying "This website is asserting it's safe when it isn't." The browser has no need to do so for HTTP because the website is not using anything that might imply there's any security between the browser and the server. The user has a reasonable expectation that there's something secure about HTTPS (otherwise, why use it?), which an unsigned certificate renders meaningless.

To use a car analogy: You don't expect a car to have "Do not eat" enscribed upon it. You might expect some plastic fruit to have that label, however. Nobody expects a car to be edible, but they might expect something that looks like fruit to be.

Re:One Question

[Sancho]

Yes, it does. The problem you are seeing is that the person who generated the certificate could be anybody. But the same is true for the cheap CAs--they will sign a certificate of basically anyone who asks.

I've seen this over and over, with nothing to back it up. Which CAs will do this? I'd like to know so that I can test them, and if it's true, remove their certs from my browser.

My experience with a cheap cert went as follows (Godaddy, within the past 6 months):
1) Sign up for cert for a domain I don't control.
2) Godaddy says that they mailed the domain contact for that domain. I mail that contact and ask that they approve the request.
3) Contact screws up the approval. Godaddy rejects my request. I resubmit.
4) Contact approves the request.
5) I get my cert and apply it to the machine I co-manage with the domain owner.

If I had wanted to, I could have hijacked the contact's e-mail--but that's only because I have root on the box that gets those messages. Godaddy did some minimal checking to ensure that someone related to the domain was involved in the process. Are there flaws? Yes. Could someone manage to hijack the process? Sure, but it wouldn't be as easy as some people make it out to be.

Re:One Question

[Ed Avis]

What the browser is doing is saying "This website is asserting it's safe when it isn't."

That's the assumption that needs fixing: that merely by using encryption a site must be claiming all kinds of super trusted certificated warm fuzzies. Why can't a website (like, say, Slashdot) use SSL to stop people sniffing passwords as they go over the wire? What's so bad about that? If you want the green glowing bar or the padlock icon, sure, you need a certificate from Verisign (for all the extra security that provides, which is pretty dubious). Why is an SSL website which hasn't paid Verisign money somehow *less* trustworthy than a website not using SSL?

The user has a reasonable expectation that there's something secure about HTTPS (otherwise, why use it?)

Ninety-nine users out of a hundred have no idea what HTTPS is. They rely on their web browser to show them indicators like green bars to indicate 'safe' and warning pages to indicate 'unsafe'. They are not well served by Firefox marking a self-signed SSL certificate as unsafe but giving no warning whatsoever about an unencrypted page.

Re:One Question

[Chandon Seldon]

Just getting users to accept self-signed server certificates is very bad, because it trains them to accept them, and they'll get phished.

How are they any more likely to get phished on a self-signed certificate than a valid certificate on the wrong URL or on the correct insecure (http) URL?

Re:One Question

[nobodyman]

At the very worst, a self signed certificate is no worse than a plain HTTP connection.

That depends. I'd argue that it's actually worse if it give the user a false sense of security.

Let's say that we implement the trust system that you propose (self-signed certs appear as more secure than plain sites, and less secure than trusted certs). This would do nothing to prevent against phishing attacks. In fact you'd have just as many attacks, but all the phishers would start using self-signed certs so that their sites appear as "more secure" than a regular website.

As firefox gains market share Mozilla has to abandon the assumptions that their userbase is tech-savvy and has web "street-smarts". I agree that this policy is onerous and it has affected me personally for some sites that I'm using self-signed certs on.

Ultimately I think that Firefox 3's policy is the only one that will make a dent in phishing, but there is collateral damage. I think the author's attempt to liken this to a violation of net neutrality is wrong.

Re:One Question

[Chandon Seldon]

Why should self-signed certificates be treated any worse than no certificate?

So far, I've heard about exactly one scenario where the current behavior would be better than simply treating a self-signed certificate like no certificate - if the attacker controls the user's DNS and the user is visiting a bookmarked https URL.

If an attacker controls your DNS, you've mostly lost already. If you don't have a bookmark to an https URL, the attacker can just point the form at another secure URL (with a valid certificate) or an insecure URL with the URL you expect.

Note that in the latter case (insecure but valid URL) the UI will look exactly the same as it would if Mozilla treated self-signed certificates like insecure sites.

Re:One Question

[Chandon Seldon]

Sure, a MITM attack trumps unauthenticated certificates. A phishing with similar URL attack or a trick-the-CA attack trumps an authenticated certificate.

A self-signed certificate is better than no certificate because it keeps out an attacker who can snoop but not hijack the connection. This is a common scenario, and worth protecting against.

Re:One Question

[Antibozo]

Why should self-signed certificates be treated any worse than no certificate?

Obviously, because when a user types "https:" in the location bar, or uses an https: bookmark, he or she expects an encrypted connection. There are multiple cues in the GUI for the nature of the connection you're using, and possibly the most important one is the URL scheme.

Re:One Question

[Antibozo]

A self-signed certificate is better than no certificate because it keeps out an attacker who can snoop but not hijack the connection. This is a common scenario, and worth protecting against.

Sounds pretty uncommon to me. What scenarios can you describe where an attacker is able to snoop but not hijack?

Re:One Question

[Chandon Seldon]

If you're on a wireless link, those guys who can so easily snoop your traffic can also hijack your connections and launch MITM attacks.

This is true in theory and completely false in practice. Everyone and their dog has a wireless sniffer app. Hijacking a wireless connection is much more difficult.

Further, it wouldn't be too hard to provide practical warnings to the user in this case - if you store the certificate the first time you go to the site, you can flip out if it unexpectedly changes later.

Re:One Question

[Chandon Seldon]

In the article, I suggest that a site with a self signed certificate should be displayed with a white address bar, no lock, and a "this site cannot be authenticated..." info bar. How does that lead the user to a false sense of security?

Re:One Question

[Chandon Seldon]

This is simply factually incorrect.

Remedial computer security lesson: The SSL protocal provides authentication and encryption. At the start of an SSL session the certificate is checked to authenticate the server and symmetric encryption keys are exchanged to encrypt the rest of the session.

Re:One Question

[bwcbwc]

This needs to be looked at from the point of view of the average user, not just the power user. Most users' dealings with SSL will be to places like financial institutions, service providers and other companies in situations where the authentication of the correct site is at least as important as the encryption. See the man in the middle attack description above. So the default setting definitely should be to disallow self-signed SSL certificates. We shouldn't want to compromise the security of the internet masses for the convenience of the much smaller percentage of users that link to sites with self-signed certificates.

That said, there needs to be a configurable override for more advanced user to either allow self-signed certificates globally, or to easily enable self-signed certificates from specified sites. The use-case where authenticity is established out-of-band via other communications is common enough that it needs to be supported by the browser.

But the key for me is 1) Firefox DOES support adding exceptions to the configuration (see the screenshot of the "big scary" warning message in TFA) and 2) if there is a level of trust between the client and the site owner that is high enough to accept self-signed certificates, then the site owner should be able to instruct the client how to accept the certificate and get the desired SSL connection.

Re:One Question

[cryptoguy]

Agreed. But it shouldn't take four clicks and an "add an exception" dialog to bypass.

Re:One Question

[legirons]

Basically it's going to take some ISP or country-wide firewall doing bulk, automated MitM attacks before the idea ever gets any publicity. At the moment, it's just a what-if (= don't worry) for most people since nobody has actually tried to masquerade as their favorite encrypted website before

Re:One Question

[Chandon Seldon]

Sounds pretty uncommon to me. What scenarios can you describe where an attacker is able to snoop but not hijack?

- Any time they don't catch the beginning of the session, since SSL doesn't allow swapping certificates mid-session.

- 99.9% of script kiddies sniffing wireless networks have sniffers but aren't set up to hijack.

Sure, that second point isn't worth much in theoretical security - but unauthenticated encryption would sure put the damper on the "wireless-dump.sh | grep '[1-9]{16}'" attack - which seems like a threat worth protecting against in practice.

Re:One Question

[marcosdumay]

How else can the CA deliver them and not having a third party eveasdroping/rewriting them? By cifering it with the certificate they are delivering?

Re:One Question

[Obfuscant]

Let's say that we implement the trust system that you propose (self-signed certs appear as more secure than plain sites, and less secure than trusted certs).

I don't think that's the trust system being proposed.

I think it is obvious that self-signed certs don't provide a trust chain.

However, I think it should be the USER'S choice to accept them or not. The browser should not be making claims about the authenticity of the site or whether it contains malicious code based on the self-signed cert. Firefox 2 has it about right. "Cannot verify, will you accept?" This nonsense from IE telling people NOT to go to a site with a self-signed cert is over the top and absurd.

Re:One Question

[Anonymous Coward]

You totally forget user psychology. When people use encryption they are inherently LESS CAREFUL.

You must think this through more clearly. Weak security is WORSE than no security because of this. Mozilla understands this perfectly, because I'm sure they have some CISSPs working with them.

Re:One Question

[nobodyman]

However, I think it should be the USER'S choice to accept them or not.

Both FF2 and FF3 provide that choice. I admit that the FF3 method involves more hoops (upon receiving the SSL error, click on "Or add an exception", then "get certificate", then "add exception"), but on the plus-side it never asks you again. With FF2 it repeatedly asks you each-and-every time you visit the site (can you permanently add an exception in FF2? I've never tried).

Re:One Question

[warsql]

This is precisely why the self signed cert should be stored. If Alice had visited www.example.com last week and stored Bob's certificate, then she would be able to detect what Carol was up to. Or if this was Alice's first visit, at least in future visits she would find out that someone had presented a forged cert before. This assumes Carol doesn't have a permanent mitm scheme going on. If Carol does have such control, only then are Alice and Bob worse off.

Re:One Question

[Antibozo]

You're playing mighty fast and loose with the statistics. Where are you getting your numbers? I would lean toward hijacking being far more commonplace because DNS is so easy to subvert, and this can be done from anywhere without requiring direct access to the victim's network path. Meanwhile, the risk of snooping alone should be minimal, because smart site admins don't transmit secrets in the clear. And there's always Digest auth.

The truly commonplace problem is malware-installed keystroke loggers. Of course certificates of any stripe can't do anything about those.

As far as snoopers missing the beginning of a session, how common does your statistical oracle tell you it is that someone is able to snoop a session, but misses the beginning of it? Generally speaking, of course, anyone in a position to snoop on a connection is also in a position to hijack it. Eve and Mallory may have different names, but on the current Internet, Eve can almost always choose to be Mallory.

As far as protecting against the threats of snooping and hijacking, Firefox is protecting against both of those, which is superior to protecting against only one of them. I frankly don't understand the complaint, or, rather, I think it's vacuous. If you're using private certs for private sites, just import them into your cert db, or set up a private PKI for them. If you're creating public sites, shell out $15-$20 and get a real cert, and stop whining already.

Re:One Question

[Anonymous Coward]

First of all, you do not have to hand over your private key to get a certificate.

Second, the whole thing is mostly a tough user interface problem: Users do not want to be bothered with checking the authenticity of certificates. They just want everything to work. If the web site does everything according to the standard, it is unacceptable that the browser disrupts the interaction with a security related task that most users don't understand, even if it just happens the first time the user connects to that server. That's the number one reason for a system where the browser comes with a "trust anchor" and web sites pay to be in that system. You simply cannot make people aware of a security issue when they enter your web site, because it destroys trust. Prompting them to verify and accept a certificate destroys trust, even though it technically provides a way for them to be more confident that they are talking to the right server than in the CA system, or at least that they're talking to the same server as last time.

In the real world, these problems are solved by liability: If a CA vouches for a domain-operator relationship, then that CA should be liable for any damage which results when the person who got the certificate doesn't actually own that domain.

Re:One Question

[Chandon Seldon]

There is exactly one attack that this stops: The attacker has hijacked DNS and the user is going directly to an https URL (probably through a bookmark). In order to protect against this attack, Firefox is effectively restricting use of the https protocal to sites that have been centrally approved.

That's a horrible trade off especially since there are other defenses against that one specific attack: for example, the browser could warn the user if the certificate is different from what it was last time - if they already have a bookmark, they've been to the site before.

Re:One Question

[DragonWriter]

wouldn't implementing what the author suggest, defeat the very purpose of having a CA ?

AFAICT, yes; self-signed certificates are less secure, and visitors should be warned about them (and, as Mozilla does now, allowed to proceed despite the warning, should they choose to.) OTOH, there should be a reasonably easy way to add new root certificates to allow new CA's to be trusted (and, in a perfect world, a UI feature that identifies the trust level the user has a assigned to the CA when connecting to a site with SSL), which would seem to deal with the entire neutrality problem without relying on blind trust for self-signed certificates.

Re:One Question

[Antibozo]

There is exactly one attack that this stops: The attacker has hijacked DNS and the user is going directly to an https URL (probably through a bookmark).

And, as I say, I would estimate that this is a far more frequent attack than snooping. In practice, I regard this as a much more important threat to protect against than snooping, since, as I already said, smart web admins don't transmit secrets in the clear anyway.

In order to protect against this attack, Firefox is effectively restricting use of the https protocal to sites that have been centrally approved.

Your constant repetition of that claim doesn't make it true. There are several ways to use certificates that haven't been "centrally approved".

Re:One Question

[Chandon Seldon]

Your constant repetition of that claim doesn't make it true. There are several ways to use certificates that haven't been "centrally approved".

There really aren't. Not for people who want to run public websites.

Re:One Question

[Antibozo]

Not for people who want to run public websites.

And, as I said already, those people should shell out $15 for a cert already, and quit whining.

If you care, advocate for a better PKI, e.g. a DNSSEC-based PKI, where there won't be a charge for each certificate.

Re:One Question

[Anonymous Coward]

His accountant would connect to the fraudulent server, which would give him a self-signed ssl certificate. It would then connect to the legitimate site using his credentials and display whatever the legitimate site would display.

At this point, his browser would notice that the site was using a different certificate from the one it had always used in the past, and would pop up a big scary error message.

Re:One Question

[Obfuscant]

Nor should the user be told that the site IS a fake and contains malicious code and the user should NEVER go there, like IE tells people.

The correct statement is that the authenticity of the site cannot be verified. "Not verified" is not synonymous with "fake".

Microsoft's IE action is forcing sites to get signed certs that don't need them. Mine is one of them. I'm perfectly happy with agreeing to accept a self-signed cert for my site; some people weren't and they forced the issue. The level of security needed was not sufficient to justify the cost. The reason why MS programmed their browser to make these false statements about my site I cannot know; it certainly reeks of money.

Re:One Question

[Haeleth]

Just getting users to accept self-signed server certificates is very bad, because it trains them to accept them, and they'll get phished.

So, remind me, exactly what is it that prevents the phishers from buying $10 certificates?

Re:One Question

[Antibozo]

At this point, his browser would notice that the site was using a different certificate from the one it had always used in the past, and would pop up a big scary error message.

Why would the browser complain that the certificate has changed? Certificates change all the time, because they expire and have to be replaced. Usually they get replaced before they expire so there isn't any down time. Sometimes they get replaced because a private key is compromised. So under what circumstances, exactly, should a browser complain about a certificate changing?

Re:One Question

[norton_I]

I've seen this over and over, with nothing to back it up. Which CAs will do this? I'd like to know so that I can test them, and if it's true, remove their certs from my browser.

I got a RapidSSL certificate, and they would allow domain ownership to be verified by any email listed in the whois record or any of about 10 "predefined" email addresses @domainname in question, including root, admin, postmaster, webmaster, and several others.

The only legitimate person to contact is the "administrative contact" in the whois record. Neither the technical contact nor whoever happens to get email sent to webmaster@example.com should be able to get a certificate on their own. Furthermore, the email itself in insecure and any number of people along the way are in a position to intercept the validation email. Since it is a completely automated system, it also vulnerable to trojans, even if the infected computer is on an otherwise "insecure" part of the network network.

But that is beside the point, really. Domain ownership is not a particularly useful thing to prove. Anyone can register a domain. For instance, Bank of America owns bankofamerica.com bankamerica.com and probably several others to reduce the dangers of typo squatting, but they can't anticipate every possible legitimate appearing name much less hard to notice typos.

At the very least an SSL certificate used for commerce should include a physical address and contact person and the CA should validate that those are correct, that they own the domain in question, and that they actually requested the certificate.

Re:One Question

[MightyYar]

What if your accountant was being sniffed before he ever picked you up as a client?

Re:One Question

[Sancho]

I got a RapidSSL certificate, and they would allow domain ownership to be verified by any email listed in the whois record or any of about 10 "predefined" email addresses @domainname in question, including root, admin, postmaster, webmaster, and several others.

But this isn't "basically anyone". It's much broader than I'd like, to be sure, but it wouldn't let me get a cert for a Google domain (for example.)

The only legitimate person to contact is the "administrative contact" in the whois record. Neither the technical contact nor whoever happens to get email sent to webmaster@example.com should be able to get a certificate on their own. Furthermore, the email itself in insecure and any number of people along the way are in a position to intercept the validation email. Since it is a completely automated system, it also vulnerable to trojans, even if the infected computer is on an otherwise "insecure" part of the network network.

All true, but now you're talking about much more complicated attacks, even farther from something that "just about anyone" could do. Security is imperfect. We do the best we can, and we try to be aware of the issues.

But that is beside the point, really. Domain ownership is not a particularly useful thing to prove. Anyone can register a domain. For instance, Bank of America owns bankofamerica.com bankamerica.com and probably several others to reduce the dangers of typo squatting, but they can't anticipate every possible legitimate appearing name much less hard to notice typos.

Again, we're now talking about different things. You seemed quite happy with domain verification when it's done right. Now you're sort of indicating that verification using a CA is entirely pointless.

You can't anticipate every typosquatter, and you can't stop someone from using the https://maliciousdomain.com/ at all. That doesn't mean that we throw the baby out with the bathwater.

As I see it, the point of verified server SSL certificates is to ensure that the endpoint I'm talking with is who they say they are. Due diligence on my part is required to ensure that the domain I'm talking to matches the company I think that I'm talking to. Just because that due diligence isn't automated doesn't mean that the rest of the chain of trust is pointless.

Re:One Question

[owlstead]

True, but only if you have to trust it each and every time. The same thing goes for most of my PGP keys. They simply get send to me (at a specific time, if possible). After that I see the responses on my encrypted mail and I am certain I can trust the certificate. After that no man in the middle can harm me.

To make a long story short, it must also be easy to assign trust to a certificate. Maybe not full trust directly, but at least some trust. If you can share the trust as well, that would also be nice. Currently you can trust a certificate, you can import it into your local trusted store. This process is however rather hard and not for you average joe.

Re:One Question

[norton_I]

Again, we're now talking about different things. You seemed quite happy with domain verification when it's done right. Now you're sort of indicating that verification using a CA is entirely pointless.

No, i think verification by a CA of *identity* can be very valuable. That is much more than checking domain ownership. At the minimum that requires a name and address, and if there is a business name it should be verified as well. Among other things this provides a chain of accountability--if I get screwed by someone using an SSL certificate I can get enough information to track them down to press charges or whatever. Obviously a CA can't determine whether foobarwidgets.com is actually a legitimate enterprise, but if they tell me it belongs to Bob Smith of Lexington, KY, owner of Foo Widgets, incorporated in the state of Kentucky that actually means something.

The existence of low-cost SSL CAs actually *does* make the entire web less secure, since many browsers (though not FF3, evidentially) treat them the same as validated certificates. This means I only have to game the weakest CA to get a paypal certificate.

FF3 (hopefully others have or will do the same) improves this a lot by using a different UI for domain-only certs vs. validated certs. However, once you do that, I don't see any advantage to not treating self-signed certificates in the same (or similar) way.

Re:One Question

[owlstead]

Bollocks. I want you to find any CA that is willing to let you have a certificate for bankieren.rabobank.nl. Not possible? Good, then I can trust the bank site. Don't forget that it only needs one person to notice an anomaly. Banks get audits as well. People think: ooh, you can play man in the middle attacks by requesting weird certificates. But you have to keep the time factor in mind, and the fact that bank SSL sites are N:1 with a very large and interested N.

Re:One Question

[MightyYar]

I know we all have different opinions on our UIs, but to me the way of accepting a self-signed certificate in Firefox is very, very easy. I just did it to sign into my company's new OWA email server, and now it no longer asks.

Re:One Question

[Nursie]

"My bank mailed me a SecureId key months ago. They could have also added their own CA certificate, which any attacker could get anyway by simply opening an account with them."

Ah, but that's fine. It doesn't matter who gets it, it matters that their public key gets to you intact and unaltered. But then we enter the realm of "How much do you trust the courier?"

Re:One Question

[calica]

Because the website with a self-signed cert looks EXACTLY like a MITM attack. Even if the original site uses a CA signed cert, a person could MITM using a self-signed cert and hope the person just clicks "OK". Self-signed provide a bit of security against passive attacks (packet sniffing) but NOTHING against active attacks (MITM). Again, a self-signed cert looks EXACTLY like a MITM attack. Assuming that the first connect isn't a MITM is risky.

CAs provide a financial paper trail. That's where the trust comes from. Figure out how to find someone and they become more honest. True criminal can get around it (and have for centuries) but it helps keep some order.

My last experience with web certs was over a decade ago and with Verisign. They required the domain holder to have a DnB number and provide a letter on company letterhead. There was a few other requirements and both us (the tech consultants) and the contracting company had to interact with Verisign. It took a few weeks to complete and seemed worth the hundreds paid.

Too bad the quest for cheap has made the CA checks worthless.

Re:One Question

[alexborges]

Well... he is going to need some serius identity data from the company.

At least last time I bought, you need the all the legal documents that make up the company and the signature of a valid company representative.

It aint that easy.

Having said this, I hate the schema of CA's basically because it grants monopolies to companies whose only value-add is the fact that they check this things before selling the cert.

If they dont, they shouldnt be trusted by default in any broser.

Re:One Question

[alexborges]

UNLESS you want to do things in-house and take responsibility for distributing the trusted root certificate for your own CA to those that need it. That there is the best option, but most folks don't want to do that and for yourbank.com it would be a big expense to make sure all the customers received this cert in an offline/secure way.

Correct. More so: most financial services that some of my customers use (and some of them are full fledged stock market brokerage firms), work with this scheme. As you say, the best possible (and a plus if your throw in client certs in there), is being your on CA for the people using your services.

Its a bitch, but security almost always is.

Re:One Question

[Anonymous Coward]

gives me much more confidence
That's the exact problem. Now you think you're safe.

The fact is, with a little cash I can get a valid certificate for someone like, let's say Bank of America, pointed at a Phishing site.

Most of the time, if the average user feels unsafe they will be Careful and Pay Attention. When they feel safe, caution is thrown to the wind. In the minds of most consumers on the internet, there is not gray area- it's just safe or not.

Re:One Question

[alexborges]

Please Cease and Desist in your publication of internally documented coding standards at AmEx.

Failure to comply will result in a visit from GWB dressed as Meryl Strip in The Devil Wears Prada.

Thank you very much.

Re:One Question

[petermgreen]

Will browsers even make a ssl connection without any certificates at all?

Re:One Question

[shaitand]

'Sniffing attacks are (AFAIK) rare.'

You have been misinformed. In the world of theoretical security sniffing attacks are less common. In the real world any paper cert MCSE and tech savy high schooler knows how to sniff a wireless network with pre-written scripts as easily as they could once winnuke a windows 95 system. A script kiddie can not hijack DNS, it requires a bit of actual knowledge.

Re:One Question

[Firehed]

Well unless you want to start going to https://72.14.207.99/ I suggest you propose a better solution. (incidentally, Google's cert only cares for google.com and not their IP)

Most self-signed certs are, in fact, not MITM attacks but just cheap site owners. It may not rule out DNS poisoning or any of that crap, but at least you know nobody's going to snag your login credentials through that open WiFi.

Re:One Question

[JoelKatz]

An encrypted connection to an unknown endpoint is no better, and in some ways worse, than an unencrypted connection. The suggested browser changes would seriously weaken security. Users cannot be expected to know which sites are "supposed to" have unauthenticated certificates.

Re:One Question

[shutdown -p now]

What the browser is doing is saying "This website is asserting it's safe when it isn't.

Which is an incorrect claim, because the website asserts nothing of sort. It just provides the encryption without providing a way to validate the identity of the website in question, but nowhere does it "assert that is is safe".

Re:One Question

[shutdown -p now]

That depends. I'd argue that it's actually worse if it give the user a false sense of security.

That's why it's up to the browser to correctly indicate that without trying to induce the user into panic ("argh! this is a totally malware trojaned insecure site! get away from here immediately!" - which is what the FF3 page for self-signed certs effectively looks like).

Re:One Question

[Eivind]

Nobody argues (that I've seen) that self-signed https: should get the SAME security-icon browser-bar-color whatever as one with a signature.

The problem is, today quite a few small/tiny websites are opting for HTTP over self-signed HTTPS because the former is perceived as MORE secure by people visiting, despite in reality being LESS secure.

It arguably should be somewhere-in-between.

Plain http means there are NO guarantees who you are talking to and ANYONE in between can passively listen in.

Self-signes https means there are NO guarantees who you are talking to, but NOBODY in between can passively listen in. (they can however ACTIVELY pose as man-in-the-middle)

Signed https means you are talking to whomever the authority gave the certificate to. And nobody can passively or actively listen in.

Please explain why the MIDDLE of these three safety-regimes should get a scary warning that DOESNT show up on either the higher or the lower alternative.

When the end-result is sites using http instead, security is WORSE than it'd otherwise be.

Re:One Question

[Eivind]

It's somewhere in between in reality. I don't think everyone can easily get a certificate for anyone. The demands for getting one ain't -zero- plus cash. But they are -low- plus cash.

I work in web-development, and I can tell you I personally could easily get a certificate for any of the ~1500 companies for which we've developed the website, or hosted the email-solution, or even just delivering dns-for.

There are ~30 other people in my company, all with that access.

I could do this -without- the company owning the domain OR anyone else at my work finding out about it.

This ain't theorethical -- indeed I do it several times a year, because the client asks me to. But there is literally nothing stopping me from doing it even if they DONT ask me to.

The certificates have -some- sort of value as evidence who you're talking to. They're hardly anywhere close to rock-hard proof though.

I'm with the article-writer: A automatic free authority that authorized anyone that can demonstrate control of DNS would provide pretty much the same security, and would have the added benefit that more sites would use https since the price and hassle would be less.

Anyone with control of DNS can -already- get a certificate; (by redirecting email then simply ordering a certificate the normal way) it's just that he also has to pay.

Re:One Question

[Eivind]

No. But I think that having a automatic, free CERT that signs the certificate of anyone that can demonstrate control of DNS will give the same security as todays solution, and will give ADDED security in that it'll lead to more sites using HTTPS.

(it could simply say: Please make 04aecf44bbfae.yourdomain.com resolve to 127.0.0.1 to prove you are controling DNS for the domain -- then when you do that, you get the certificate. Simple, quick, free, just as secure as todays solution. (all VeriSign verifies is that you can read email to like post@domain.com anyways, and that can easily be done if you control the DNS)

There are authorities like this already. It's just that their keys aren't distributed by default in FF (and others). In my opinion, it would improve security if they -where- included. It would also cost VeriSign and friends 90% of their customers, and leave them with those few who need an extended-verification certificate. Which is just fine.

Re:One Question

[Eivind]

I -do- think clearly.

I agree self-signed shouldn't be presented as THE SAME as externally-signed. But it also shouldn't be presented as WORSE than nothing at all.

Two changes should happen:

First, some authority that signs for free for anyone that can demonstrate DNS-control should get their key included in FF (and the other browesers). This alone would do a lot.

Second, we need two security-icons rather than one. One for encrypted or not. One for identified or not. Self-signed https is encrypted, but not identified.

unknown unencrypted website. (http:)

unknown encrypted website. (self-signed https:)

KNOWN encrypted website. (signed https:)

It's not that hard really.

Re:One Question

[Znork]

First of all, you do not have to hand over your private key to get a certificate.

Of course, but as there's no requirement to have _the_ signed key, only _a_ signed key, anyone who can get a signed key can still mitm.

even if it just happens the first time the user connects to that server.

So don't even prompt the first time, just store the relevant info the first time and prompt if it changes.

In the real world, these problems are solved by liability

And in the real world, the problem of liability is solved by litigation cost barriers, weasel-wording and jurisdictional issues.

I wouldn't assume I could get a dime out of a CA under any circumstance.

Re:One Question

[Ed Avis]

Assuming that the first connect isn't a MITM is risky.

I guess this is a reasonable point.

But again, if you go to http://mybank.com/ and it turns out to be a phishing site, there is no warning whatsoever. Most users have no idea what the difference is between http and https; even when typing in URLs by hand they don't type the http:/// part.

In olden days users were encouraged to look for the padlock icon. Nowadays the connotation of trust that provides has been worn down by the CAs' sloppiness in handing out certificates, so the new user interface marker is the green glowing bar for an EV certificate. As long as the self-signed https website does not appear any more secure to the user than an unauthenticated site, I don't see there is a problem.

By all means have the scary warning appear for self-signed sites, as long as you make it appear for unencrypted sites as well! They are both equally likely to be fakes.

Re:One Question

[Nursie]

No it doesn't. It requires sniffing a dns packet and spoofing the response.

Easy to do with a script.

Re:One Question

[owlstead]

Just for fun, I tried it on the sample website provided by the link. Sure I succeeded, but I would not call that easy for anyone not really experienced. We're talking market penetration here, not geek penetration (somehow this bring on very distasteful images in my dirty mind, but whatever). Uh, lets say that it is easy for geeks but hard for A. Joe.

Re:One Question

[Kent Recal]

Amen.
As far as I am concerned you should be modded through the roof!

I proposed the exact same thing on multiple occassions. But my pessimistic outlook is still the same: VeriSign & friends won't allow that happen because it would invalidate their license to print money.

Re:One Question

[Chandon Seldon]

Well unless you want to start going to https://72.14.207.99/ I suggest you propose a better solution.

Any time you go to a SSL authenticated website, the browser should store the certificate. If the certificate changes, it should notify the user (i.e. info bar). If it changes from a PKI authenticated certificate to a self signed certificate, it should flip out like it does now.

This still leaves open the possibility of first-visit hijackings, but first visits are usually to http URLs that a DNS hijack could redirect anyway.

Re:One Question

[BZ]

> Snooping a connection is a hell of a lot easier and more common than hijacking one

I suggest you give http://blog.johnath.com/2008/08/05/ssl-question-corner/ a read. And heck, that's not even including wireless access point operators, who can hijack whatever connections they want.

> by demonstrating their (hijacked) control of the domain

Hijacking a connection just means replying to the user's request. No control of the domain required. And CAs that don't verify domain control properly don't end up in UA trusted CA lists.

> and requiring website owners to always sign up and be approved before they can use the
> HTTPS protocal on a public website

No one is requiring anything of the sort. Do read Johnathan's blog post linked above.

Re:One Question

[BZ]

For someone who understands the issues, "encrypted + trusted > encrypted > nothing".

For someone who just looks for the lock icon, treating "encrypted" like "encrypted + trusted" makes it a phish magnet. So you certainly can't do that. Your options are either to not show the lock icon or to make it clear that something is up in this special case.

Put another way, for most users, given their trust and threat models, unencrypted connections _are_ safer, since they don't trust them. Or they do, but then they're just screwed no matter what.

Re:One Question

[BZ]

> But a self-signed cert is better than no cert so there certainly shouldn't be more
> stringent notifications than there are for completely unencrypted pages.

This would be fine if self-signed certs also didn't show any encryption indicators. But people want to see those for some reason... Then you have to make it clear that they're not quite the same as the encrypted pages one is used to.

> open and free ca like https://www.openca.org/

They're free to ask to be included (which includes an audit that verifies that they in fact verify domain ownership). The process does take a little bit of time on everyone's part, of course.

Re:One Question

[BZ]

> First, some authority that signs for free for anyone that can demonstrate DNS-control
> should get their key included

This is already the case.

> Second, we need two security-icons rather than one. One for encrypted or not. One for
> identified or not.

There start to be serious issues with user confusion here. It's taken about a decade to sort of get people looking at the lock icon. Sometimes.

Dealing with security UI for people who don't know much about security is really hard. Of course the same is true if you replace "security" with just about anything else...

Re:One Question

[BZ]

> So, it makes little sense to make self-signed https:/// look MORE scary that http:///

It makes all the sense in the world if users are conditioned to just look for the https:/// and assume everything is fine.

Re:One Question

[BZ]

As far as I can tell, it's never asked to be included (e.g. it's not present on the "pending review" list of CAs on mozilla.org). Being included does involve some time investment on the part of the CA, since the browser maker wants to verify that the CA does in fact perform domain verification, etc. So maybe they just haven't gotten around to finding the time to do this.

Re:One Question

[Wdomburg]

Certificates aren't private. They're transmitted to any client attempting a connection. The only private component is the private key, which the CA never sees.

Re:One Question

[marcosdumay]

Ok, that is the same problem, on a different transmission. How can the CA be sure that the certificate is authentic if it is delivered by email?

One communication step is not safe, that one must be done in person if you want to claim you know who you talking to. Even with PKI.

Re:One Question

[Wdomburg]

The certificate originates with the CA, so of course they know it's authentic.

It seems like you're not actually familiar with how thi works:

1) The site administrator generates a key pair. The private key is never ever transmitted to anyone - not the certificate authority, not the end user.

2) The site administrator generates a signing request and sends it to the certificate authority; this contains only the public key and data which will be included in the certificate (including the "common name", which is the FQDN the certificate is intended for).

3) The certificate authority gives back back a certificate.

None of the communication here contains any privileged information, which is part of the beauty of PKI. Secure transmission simply isn't necessary.

What you do need is some form of validation. For a basic certificate the aim is to tie a certificate to a domain owner. A simple mail to a privileged account name (or even better, one on file with the registrar as an authorized contact) is simple and reasonably effective.

For extended verification, where the goal is to validate a certificate against a legal entity, the process is far more involved and does require a physical meeting (if not with the CA directly, with an appointed third party validator or notary) as well as proof of legal existence (with onus on the issuing CA to validate and cross-check the information). These certificates are required to be backed by multi-million dollar policies with an agency in good standing.

Re:One Question

[Abcd1234]

So did the self-signed cert make anything worse? No, it didn't.

Yes, it did, because a person naive in the inner-workings of SSL and public key cryptography would assume that encryption == safe. Period. And thus they would treat the connection as a trusted one, when that's precisely what they *shouldn't* be doing.

So, in the case of an educated user, you're right, it doesn't make a difference. But guess what? The current Firefox policy is no worse for, guess who, *educated users*. But the very users who *could* be duped by a self-signed cert are the very people the new procedure is targeted at. Which is why it's a very positive change, IMHO.

Re:One Question

[shaitand]

There is a pretty wide gap between a "help get me out of here" button and a statement that says that no legitimate site would use a self signed cert and simply not displaying the lock icon on self-signed connections.

Although for someone who understands the issues, we know that the bar is low enough with authenticated certs that they don't provide trust either. Which means they are really only good for encryption without trust as well.

Re:One Question

[BZ]

Just curious... which side of the wide gap do you think the two things lie on?

> we know that the bar is low enough with authenticated certs that they don't provide trust
> either

They provide trust that the entity you are talking to is the legal owner of the domain name listed in the cert. Any CA that doesn't guarantee that shouldn't be in the default CA lists of browsers (and Mozilla in particular requires that from the CAs it includes).

Re:One Question

[shaitand]

Self-signed certs do provide an encrypted connection, so they should provide an encryption indicator.

When you visit an unencrypted page in firefox for the first time, it brings up a notification telling you as much. This has a box to not show again that is selected by default.

A notification of this sort, with the same default indicating the page is encrypted but the other party had not been verified by a certification authority would be fine. It should have the same never show again box with a check mark.

Whether the encryption used is strong and secure is a technical matter that joe blow is not capable of determining. The website's identity not being verified is not a technical matter at all and Joe can make that informed choice on his own. The fact that we all know Joe is a moron and will probably make the wrong choice IS NOT a relevant factor, joe is an adult and free to be duped all day long if he sees fit.

Re:One Question

[shaitand]

That actually wasn't the site I meant to link. But it has come out elsewhere that is a free as in beer CA trusted by mozilla browsers. Unfortunately, IE has not included them.

Re:One Question

[shaitand]

'Just curious... which side of the wide gap do you think the two things lie on?'

Currently, Firefox 3.0 displays the button and message claiming that self-signed sites are not legitimate.

I think simply not displaying the padlock would be a better option or better yet, a prompt of the sort I mentioned earlier.

'They provide trust that the entity you are talking to is the legal owner of the domain name listed in the cert. Any CA that doesn't guarantee that shouldn't be in the default CA lists of browsers (and Mozilla in particular requires that from the CAs it includes).'

Nonsense, you can go out an get a cert that is poorly or not at all verified today for about $15.

Re:One Question

[BZ]

> Self-signed certs do provide an encrypted connection, so they
> should provide an encryption indicator.

Only if the user cares about encryption but not whether they're talking to who they think they're talking to. Can't think of such situations offhand, to be honest.

> When you visit an unencrypted page in firefox for the first time,
> it brings up a notification telling you as much.

Uh.. not last I checked, no. That would be most pages users visit, and I can assure you that Firefox does NOT bring up notifications every time you hit a site you haven't been to before.

> Whether the encryption used is strong and secure is a technical matter
> that joe blow is not capable of determining.

We agree on something!

> The website's identity not being verified is not a technical matter at all

Sure it is. Try talking to an actual Joe Blow sometime... I think you underestimate how much technical knowledge and understanding of the CA/certificate/SSL setup goes into even asking the question, "Is this website's identity verified?"

Re:One Question

[BZ]

> I think simply not displaying the padlock would be a better option

It was considered, actually. Interestingly, people seemed even more vocally opposed to that than to the current setup.

> Nonsense, you can go out an get a cert that is poorly or not at all verified today
> for about $15.

Not verified that you actually have to do with the domain the cert is being issued for? Which CA, pray tell me? Sounds like some CAs need to be removed from the default CA list.

Re:One Question

[Kalriath]

Obviously you've never got an SSL certificate from Verisign. The one occasion I had to experience that, they required us to provide them a valid business incorporation number, a Dunn & Bradstreet number, physical address, contact name, phone bill, phone number (which they then ignored - their verification policy is that they will only call a number either printed on your phone bill or found in the white pages) and the whole thing took a week. I found it a similar experience getting a Code Signing certificate from them - except they skipped the D&B number.

Re:One Question

[Kalriath]

Uh, the certificate wont work without the corresponding CSR and private key anyway... only the CA and you have the CSR, and only you have the private key. Rewriting them is quite frankly impossible, and eavesdropping is pointless since they don't have all the parts.

Re:One Question

[Antibozo]

Your single occasion getting a server cert from Verisign must either have involved getting an extended validation cert, or have occurred quite a few years ago. For regular certs, they may still ask for phone number and address, but they don't use them for anything. Dunn & Bradstreet number? Business incorporation number? I've never needed such things with any CA.

The principle authentication measure the CAs use these days is a cleartext email to an address in the domain, containing a token. In cases where your registrar is also a CA, you may be able to get a cert using the same authentication procedure needed for domain administration.

Historically, very few bogus certs have been issued by the standard CAs. That may change, however, especially as DNS continues to get weaker.

Re:One Question

[Kalriath]

What are you talking about? OpenCA doesn't issue certificates at all! Look around their site- their "Demo CA" is a 404 Not Found page, and the rest of the site is quite clear that OpenCA is a software package.

If you mean CACert, they aren't included yet because they're still being audited. And according to their blog, they failed their last audit.

Re:One Question

[Kalriath]

For the 10 bajiollionth time, OpenCA doesn't issue certificates.

Re:One Question

[shaitand]

'I think you underestimate how much technical knowledge and understanding of the CA/certificate/SSL'

None. We can't guarantee you are sending the credit card information to who you think you are. Simple, not technical at all, and its no more complicated than that. Joe now knows all he needs to know to decide if he wants to take the risk anyway.

Joe probably won't risk it, until he REALLY wants the red ryder bb gun. Then joe takes a chance, and next time joe takes another chance and so on for years until joe ignores that prompt altogether because neither he nor anyone else he knows ever got hit with a man in the middle attack. That's Joe's choice and its none of our concern.

Re:One Question

[BZ]

> We can't guarantee you are sending the credit card information to who you think you are.

That's false, though. There are situations where we can certainly guarantee it at the level at which it's guaranteed in a brick-and-mortar store. Self-signed certificates just aren't such a situation.

I admit that it's nice to have the view that people shouldn't be using the Internet for anything money-related, and if they do they're just ignorant morons. It's simple and consistent. It's not very useful, though, unlike the view that it would be good to make it usable for money-related things, and that if the Internet needs to change to support that then it should.

Re:One Question

[marcosdumay]

No, I am familiar with the process, just didn't pay atention to the terminology (up until now). You say step 2 contains no priviledged information, you are tangentialy right, it contains authenticated information. Access to an email isn't enought to authenticate a person* since email is vunerable to men-in-the-middle attacs, and you can rewrite the information during transmission.

Authenticating a company is still harder, since it has no physical form. But that is a problem that we've being unsucefuly trying to solve for ages.

Re:One Question

[Kalriath]

Nope, it was last year or so, and NOT an EV certificate. Verisign is ridiculously harsh on their validation procedures (which you'd bloody expect for $800/yr!)

Re:One Question

[Wdomburg]

It doesn't matter if the signing request or certificate are modified, though. The request originator can easily validate that the certificate since he holds the private key. And the point isn't to authenticate an individual, just a domain. In theory, yes, intercepting a particular SMTP transmission is entirely possibly. In practice it's far from trivial. Ideally it would be nice if e-mail verification required DKIM or at minimum SPF, but even current practice represents a significant increase in security over a self-signed cert.

As for authenticating companies, who cares about physical forms? The important bit is tying to a legal entity, which doesn't strike me as a particularly difficult problem. Check for legal registration, verify the registered location, verify a principal individual in the company. The requirements set forth by the CA/Browser forum are actually quite good, overall.

Remember, security can never make a breach impossible. The goal is to make it hard enough it's not worth trying.

Re:One Question

[Anonymous Coward]

SSL client certificates are not used often, but that's only because HTTP authentication can be used instead and is considered more convenient to set up.

Another problem is that PKI security is quite often horribly flawed, for example in Novell's default setup (or at least the one my company uses) it's completely useless. You can download any user's certificate if you have the username and password, which means that the security of PKI is never greater than the security of the password, so you could just as well not use PKI at all. It's worse than useless because it only offers a notion of increased security, not actual security. It allows the marketing folks to check off another bullet point, so who cares if this approach doesn't actually work from a security perspective.

The way it really should be is that certificates are handed out to individual users on a physical medium (ideally a smart card but now I'm dreaming) in such a way that only the user knows the passphrase. But that would be oh so inconvenient, so no thanks.

This is stupid

[duffbeer703]

The whole point of SSL is to have some assurance that you are connecting to whom you think you're are connecting to.

While the model of paying a CA to assure your identity is not perfect by any means, ignoring the issue isn't either. Many slashdotters seem to have a hard time getting this.

IMHO, the system in Firefox 3 is superior. While self-signed sites are blocked by default, it is not easier to explicitly trust a self-signed SSL site. In the past, most people would just click past the nag dialog when it popped up.

Re:This is stupid

[jgtg32a]

But there's one problem you understand what the error message says and means.
My parents couldn't get past that message even after I explained it. I had to downgrade FF because they would freak out when they saw that message.
From a usability point of view its terrible.

Re:This is stupid

[js_sebastian]

The whole point of SSL is to have some assurance that you are connecting to whom you think you're are connecting to.

No. As TFA says, there are 2 points to SSL. 1 is to provide confidentiality (encryption) the other is to authenticate the server to the user. A server with a self-signed certificate provides protection against passing (but not active) snooping. This is worse than what a real, trusted-third-party signed certificate provides, but it is better than no encryption at all!

So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?

IMHO TFA is very much correct this is a problem. The solution is not obvious, because users are used to the lock icon and may not understand the concept that confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.

Re:This is stupid

[quantumplacet]

I think that's exactly the point. If you can't understand what a self signed certificate is, you shouldn't be accepting them.

Re:This is stupid

[elFarto the 2nd]

While I like Firefox 3, I find it annoying that I have to accept a self-signed certificate forever. I'd much prefer to accept it from my current session only. Accepting it forever seems a little insecure to me.

Regards
elFarto

Re:This is stupid

[Anonymous Coward]

Self-signed certs are still strictly more secure that completely unencrypted traffic. If it warns you about a self-signed cert, then it should warn you /every/ time you visit a completely insecure site. In reality, it should just accept self-signed without indicating that its secure, and have an icon for people who know/are expecting self-signed certs to indicate that is what has been given.

Re:This is stupid

[duffbeer703]

IMHO TFA is very much correct this is a problem. The solution is not obvious, because users are used to the lock icon and may not understand the concept that confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.

The people who don't understand this are not IT people who are going to be futzing with self-signed certs, or are IT people who need to clue up and understand the implications of using self-signed certs.

Re:This is stupid

[Anonymous Coward]

Oh you're so right, encryption is definitively useless, especially when I want to read my mails on a public wifi area.

Re:This is stupid

[mapsjanhere]

Insecure is less dangerous than encrypted untrusted. How many less-than-savvy users are trained by their more geeky relatives to check for two things - the httpS and the little lock icon. How easy do you want to make it for the phisher if he can safely pretend to be https://cidybank.com/ with the lock icon? Getting "trust" established was one of the hardest thing for e-commerce to do. Anything that undermines it needs to be stamped out.

Re:This is stupid

[Darfeld]

I don't know... It's a choice to let the user do anything (right or wrong) or to protect them from themself. From a clue-less user point of view, the latter seems better. For a well-informed user, it doesn't really matter (One clic at the first visit, and that's it...).

In the end, SSL isn't that common. You could always add exceptions in FF so they wouldn't cross the warning again.

Re:This is stupid

[pmontra]

Let's do it with alert boxes.

HTTP only: "The communication with this site is insecure because it doesn't ecrypt the data you're sending to it. Furthermore there is no guarantee that it's owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore.

Self signed HTTPS: "The communication with this site is secure because it encrypts the data you're sending to it. However there is no guarantee that it's owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore."

CA's signed HTTPS: "The communication with this site is secure because it encrypts the data you're sending to it. Furthermore [the name of the CA] guarantees that the site is really owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore."

However one has to be really naive to believe the guarantee part of the last statement or that CAs are willing to have any legal responsibility for the claims they're issuing with any certificate. Actually that third alert box might be harmful as it perpetuates the delusion that certificates do anything about authentication.

Eventually it's not a problem of GUIs but a problem of understanding what certificates are really for.

Re:This is stupid

[ztane]

Mod parent up! If someone was trying a man-in-the-middle attack with your online bank, you would want to be loud about it, now wouldn't you. Man-in-the-middle is just too easy, considering for example that we had a serious DNS flaw published not so long ago, and that not every DNS server has been patched. In that case you'd want to freak out any users that come across with invalid certificates. Otherwise the SSL is just void for security, and we could pretty much use plain HTTP anyway.

Re:This is stupid

[Anonymous Coward]

Except that you can do just that: there's a checkbox "Store certificate permanently" which is enabled by default. Disable it and you get the per-session behaviour.

However what's the point of a temporary certificate? If you store it permanently you'll be warned of man-in-the-middle attacks (assuming the cert you're accepting is the real one in the first place). If you store it temporary for your session, you'll just do that too with the fake certificate from the evil hacker and you'll never know. Or do you remember the fingerprints and check them every time?

Re:This is stupid

[QuietLagoon]

That's the interesting point in all this. Good security cannot get in the way of doing what you want to do. Windows Vista proved this with the UAC nagging.
.

If I visit my friend's website, and he tells me that he self-signed the certificate, then I will trust that more than if a CA had signed a certificate. Why? Because I trust my friend more than I trust Verisign or whomever. Why should FF3's acceptance of the former trust relationship be more complex than its acceptance of the latter?

FF3 needs to make it easier to accept self-signed certificates.

Re:This is stupid

[Anonymous Coward]

Accepting it each time you connect is worse. Once it's accepted, ANY CHANGE will throw a warning. The change is what is important. Otherwise, once you start accepting temporarily every time for a given site, when some one posts a man in the middle attack, you'll have no clue

Re:This is stupid

[lysse]

You grant that the users will understand that there are two separate properties under discussion, separate them out, and have them both independently verified. Seems to me that the error here is that historically, there's been no separation of these things, no way to say "we're not claiming to be anyone, but you can rest assured your data won't leak on its way here". It's always been a problem - FF3 has just made it a really visible one.

Re:This is stupid

[Phs2501]

Accepting it permanently is actually more secure, because then you know when it changes. That way you know it's at least the same host each time (or a different host that at least went to the effort to steal their SSL key).

Re:This is stupid

[jeroen94704]

Agreed, and well said: Encryption and identity verification are both purposes of certificates/SSL. However, in this day and age, the latter is by far the more important one of the two.

Re:This is stupid

[PIBM]

Except that it's actually the secure thing to do.

If you check the probability that the site you are using will get hacked in the lifetime usage of it that you will do, in most case the first usage of the website will be on the valid one, and you will then learn about a Man-in-the-middle attack when it will say that there's a new certificate to accept (every other time it had not asked you).

If you don't accept the certificate, you'll be clicking all the steps everytime for that website anyway, so you won't notice the different MD5/SHA1 hash, and in fact won't even look at it.

If it happened to you that you first used it on a day with an attack, then the next day or so, when it's fixed, you'll have a new certificate, and know that there's been something wrong (site will most probably talk about it) and you will be able to react fast, since you know you were subject to the man in the middle attack.

Anyway ..

Re:This is stupid

[tokul]

So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?

Because it is insecure website that tries to pretend that it is secure.

Re:This is stupid

[Anonymous Coward]

The difference is that people will give out more information to an SSL page. Without a warning, self-signed SSL pages can exude the same level of trust as a root-signed SSL pages--something not as likely to happen with a non-SSL page.

Re:This is stupid

[Urkki]

Self signed HTTPS: "The communication with this site is secure because it encrypts the data you're sending to it. However there is no guarantee that it's owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore."

Wrong.
"The communication with this site is insecure because even though data transmitted is encrypted, you don't know if some hostile 3rd party is intercepting, decrypting, recording and possibly altering data on the way. Additionally, there is no guarantee that the certificate or the web site belongs to the organization you think it belongs to."

Re:This is stupid

[Anders]

Self-signed certs are still strictly more secure that completely unencrypted traffic.

No. If you do not know who you are talking to, encryption does nothing to increase your security.

Re:This is stupid

[Rob_Ogilvie]

So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?

Because it is better to know a connection can be snooped than to believe your connection is snoop-proof and be wrong about it.

Re:This is stupid

[Anders]

A server with a self-signed certificate provides protection against passing (but not active) snooping.

So it helps against those that are not really out to get you. That's not security, and Firefox is right to warn about it.

Re:This is stupid

[kju]

So what? Joe Random Phisher puts the fake website at https://www.citybank.com------------foobarbaz.com/ (or a similar obfuscated address, which is we all have seen before) and gets a genuine SSL certificate for it. To get a SSL certificate for any domain all you need is a credit card number and access to an email-address under the target domain. Joe Random Phisher has both and many people will fall for this trick. If you really beleave that SSL-Certificates involve the trust you are talking about, you are misleaded. Careless and fully automated CAs have long abandoned trust for more profit. As other pointed out its also not too complicated to get phony certificates for the "real" domain. I know automated CAs who only require you to have one of a rather large list of possible email-adresses under the domain, e.g. postmaster@, hostmaster@, sslmaster@, ... In some cases (especially on webmail providers) its possible for anyone to get access to one of these addresses. Hell, some years ago i was even able to get postmaster@do.main from one providers webmail.

Re:This is stupid

[Anders]

Accepting it forever seems a little insecure to me.

Forever is actually better. Accepting the certificate forever (until it expires) means that you only get a warning when it actually changes.

If you always get a warning that you just click through, you will not notice when the site is one day hijacked through a DNS attack, and the warning looks slightly different.

Re:This is stupid

[mxs]

That's a pretty bad point. Are you suggesting that if you can't understand what a certificate is, you shouldn't be using SSL ? If you can't understand what HTTP is, you shouldn't browse the web ? If you can't understand what BGP is, you shouldn't be using HTTP ?

If you can't understand what a self-signed certificate ist, you should only be accepting them once you either a.) learned how to understand it or b.) somebody you trust tells you to or c.) you do not implicitly care about the implications since you are not going to be transmitting private data, anyway.

Re:This is stupid

[shaitand]

'How many less-than-savvy users are trained by their more geeky relatives to check for two things - the httpS and the little lock icon.'

That would be why he said not to put on a lock, just to continued as you would for an unencrypted connection with no notification (including padlock) at all.

'Insecure is less dangerous than encrypted untrusted.'

This is utterly ridiculous. For the handful of geek advised relatives there are MILLIONS who have no idea what the padlock is at all. A man in the middle attack is far more difficult than simply sniffing a connection.

'Getting "trust" established was one of the hardest thing for e-commerce to do.'

If they ever manage it, I'd like to know. Currently you can get a cert accepted in every major browser that claims you are a company you have no affiliation with.

Re:This is stupid

[shaitand]

'So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?'

It goes a step further. It presents two options, HELP GET ME OUT OF HERE and add to exceptions. Then if you try to add to exceptions it blatantly states in bold print that no legitimate site would ask you to do this. In other words, you are about to go to a scammer site, are you sure?

Re:This is stupid

[Talennor]

I'd much prefer to accept it from my current session only. Accepting it forever seems a little insecure to me.

If you're not feeling paranoid there's a thing called "first time trust". This is how you usually accept ssh certs, and can usually work well for internal network use. The idea is that every time you return to that machine it presents the same cryptographic identity.

If you were correct in your assumption that there was no man-in-the-middle attack on your first connection, then keeping that certificate around prevents future attacks. Or if it was different the next time you'd have reason to suspect that first connection and know what data you'd given up.

So accepting a certificate until its expiration has more security features than accepting for a single session.

Re:This is stupid

[click2005]

because users are used to the lock icon and may not understand the concept that confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.

How about 2 icons?

Re:This is stupid

[gauauu]

Great idea....alert box appears once, user looks at it blankly, clicks "don't tell this to me anymore", and goes one with their life, without understanding the issues, and getting their credit cards stolen because they went to www.cidybank.com and saw the httpS, so they figured it was secure enough.

Re:This is stupid

[quantumplacet]

So lets see, you shouldn't accept self signed certificates if you don't understand them unless you
A.)understand them (or EXACTLY WHAT I SAID)
B.) somebody else tells you to (essentially they accept it for you)
C.) You don't care about the implications (which would require you understanding what a self signed certificate is to understand the implications)

I guess I'll give you B as a counterpoint to my original point, but in the end, all 3 of your points simply enforce that Mozilla has done the right thing here. I won't even bother addressing your analogies as they couldn't be farther off the mark. Maybe try using a car? And no, you shouldn't be driving a car if you can't read a speed limit sign.

Re:This is stupid

[freezin fat guy]

How easy do you want to make it for the phisher if he can safely pretend to be https://cidybank.com/ with the lock icon?

Which is why phishers go to the trouble to obtain approved certificates. It is the people with nothing to hide who are wondering why they need to pony up.

Re:This is stupid

[itsdapead]

So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?

Because once it has accepted the certificate or let you set an exception, Firefox is going to tell you that you have a secure connection, and Mozilla corp quite rightly want to well and truly cover their ass before doing that.

Now, if you're using an unencrypted site they already warned you - the first time you filled in an online form - that the bogeyman might get you, so they're covered. If its an encrypted site with a "proper" CA signed certificate, but it turns out that the CA have signed a certificate for FORMER VICE PRESIDENT UHAZBIN PWNED OF NIGERIA, the Wells Frago Bank or www_amazon_com.tv (after scrupulously verifying that someone had written that name on a post-it stuck to a $10 bill) you can go and sue the CA instead, so that's OK, too.

(PS: I didn't say you can go and sue the CA and win...)

Re:This is stupid

[Anonymous Coward]

You do not have to add a permanent exception, you can choose to only temporarily allow the exception by deselecting the Permanently store this exception option.

Re:This is stupid

[wizztick]

This sounds great. But please don't use alert boxes. People gave up on reading them.

The way the message is displayed in Firefox 3 makes that people are reading them. But the message itself is not clear.

Re:This is stupid

[SanityInAnarchy]

Self-signed certs are still strictly more secure that completely unencrypted traffic.

Assuming they're legitimate -- which is, you know, impossible to verify, which is the whole fucking point of a certificate authority -- to give you a means to verify that a given cert is legit.

And if they're not legitimate, depending on the site, it could be a huge warning that you're being subjected to a man-in-the-middle attack. Depending on the site, this could be much more likely.

Let me put it this way -- you go to https://www.paypal.com/, and you get a self-signed cert. Give me one good reason why the user shouldn't get a giant flashing red warning that they're probably about to be phished.

Re:This is stupid

[DannyO152]

A guy knocks at the door and you ask for ID and they show a picture and a name on a business card. Self-certified is less secure than a certification which calls to an authority. As to preferred method of handling self-certs, I vote for Firefox which calls my attention to non-authoritative certs and gives me a choice of not connecting, connecting once, or storing revocable trust of that cert. I would expect that if that cert changes, I'll find out. Safari, which asks every time, won't notice if a cert changes. This feels like a security hole. Any browser which lets a self-cert pass without comment will burn, some day, its users. I say this because the "Security is hard, let's go shopping" attitude has been a source of much misery, fraud, and loss on the web. It is always a mistake to smooth out the speed bumps that precede an exchange of confidential information.

Re:This is stupid

[mapsjanhere]

This comes down to "do you lock your house?"
Of course you can get fake certificates. Just as a professional thief can probably jimmy your lock faster than you with your key. But I still lock the door, in the hope to keep out at least the junkies looking for an easy grab (or the script kiddies on the internet).

Re:This is stupid

[swilver]

I have three choices as a web-site owner.

1) Run unencrypted over HTTP
2) Run encrypted over HTTPS and a bribe to Verisign
3) Run encrypted over HTTPS using a self-signed certificate

You're saying I have only two choices. Since I'm not going to give free money to Verisign, I guess I will just offer an unencrypted service only for stupid people like you who donot understand encryption has value even without Verisign saying it is "ok".

Re:This is stupid

[swilver]

It actually is security, because assuming they're not ALREADY out to get me, I will know once they are out to get me because Firefox will warn me that the certificate changed. That and the fact that it is an order of magnitude easier to monitor plain text communication makes any form of encryption desirable over plain HTTP.

Re:This is stupid

[swilver]

No, actually it is a normal website like any other that offers a service that makes whatever you do on that website an order of magnitude harder to monitor. If every website did this, and you stored their certificates, then you would immediately know when you were being monitored because suddenly all those HTTPS sites have had their certificates magically changed, all on the same day!

Re:This is stupid

[Bill_the_Engineer]

Actually accepting the self-signed certificate forever is safer than current session only. At least with the forever, you will know when the certificate has changed and may indicate a man-in-the-middle situation...

Re:This is stupid

[defaria]

No it's not the *whole* point! It's 1/2 of the point! Which is the whole point to the objection! Proving to a visitor that you are you is only one aspect of an SSL connection. It may or may not provide a little bit of reassurance that the web site is what the web site claims to be - for the visitor.

For the web site owner however he might just want to have encrypted traffic. Nobody is harmed by having encrypted traffic.

Sure tell the world that this SSL cert is not signed and can't be trusted for to prove that the owner is who he said he is. But this is no reason to hamper encrypted communications.

Re:This is stupid

[js_sebastian]

IMHO TFA is very much correct this is a problem. The solution is not obvious, because users are used to the lock icon and may not understand the concept that confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.

The people who don't understand this are not IT people who are going to be futzing with self-signed certs, or are IT people who need to clue up and understand the implications of using self-signed certs.

I'm talking about browser users, who have to decide whether to trust their email account or banking account password to a website based on feedback from the browser GUI. Cannot expect them to have a PhD in computer security.

Re:This is stupid

[bickerdyke]

ok. but FF needs a way to KNOW that your friend told you that his Self-signed Certificate is OK. FF can't tell your friends self-signed-certificate from the middlemans self-signed-certificate. And your mean of teaching to ff you your friends are, is importing their certificates.

Re:This is stupid

[bickerdyke]

May I ask which sites working with self-signed-certificates your parents needed to visit?

Re:This is stupid

[Nursie]

Because firefox 3 knows that on the internet, nobody can tell if you're a dog. or for that matter, if you're *really* talking to your friend.

Now, if you and your friend are savvy enough, he can make his own CA, you import its certificate into fox, et voila - it all works.

But most people are not savvy enough so someone does it for them. CAs. If these guys aren't trustworthy then that's a problem but don't pretend that firefox should treat a connection with at least some verification as equal to one that has none at all.

Re:This is stupid

[Nursie]

"but you can rest assured your data won't leak on its way here"

No, you can't, because anyone could be dong a MITM attack. Encryption can't guarantee anything other than simple sniffing is not effective.

Re:This is stupid

[Sloppy]

The whole point of SSL is to have some assurance that you are connecting to whom you think you're are connecting to.

Nope, that's just half the point of SSL. Encryption is the other half of the point.

self-signed sites are blocked by default

And un-signed sites are not blocked at all, and show no warning of any kind. Face it: that is really weird.

MitM-vulnerable encrypted sessions are at least as secure as MitM-vulnerable unencrypted sessions, and most people would say they're more secure.

Re:This is stupid

[Sloppy]

How many less-than-savvy users are trained by their more geeky relatives to check for two things - the httpS and the little lock icon.

Tweaking the details of the UI is trivial. If you want a lock icon to be "the other side has been certified by someone as being who they claim to be" then simply don't show an icon when you can't verify who they are. That doesn't mean you shouldn't be able to use https, though.

Re:This is stupid

[Anonymous Coward]

A server with a self-signed certificate provides protection against passing (but not active) snooping. This is [...] better than no encryption at all!

Ha, not by much. How many situations are there where people can use passive but not active snooping? Not many, I'd wager.

Also explaining to users something is 'somewhat secure' is a recipe for confusion; isn't unencrypted HTTP over a wired connection also 'somewhat secure'?

Re:This is stupid

[blacklint]

Slashdot car analogy: Do you lock the doors on your car? That helps against those who are not really out to get you. That's not security, as someone who is determined could use a coat-hanger and get in. Might as well not lock your car doors.

For some things, preventing against passive attacks is all that is needed, such as for your Slashdot user account. Currently, the login form is just HTTP, so how could protection against passive attacks be worse? Presenting such as connection in the same way as the verified certificate given to your bank is bad, but by itself, a connection without identity verification isn't worse than plain old HTTP.

Re:This is stupid

[ckedge]

What website were you trying to get your parents to connect to that wasn't using a properly signed cert?

I'm with the others, your parents should never be going through that menu - if they trust you and if you trust a self signed cert and understand the warnings, then they should get you to do it the first time.

(What kind of warnings are thrown up on subsequent visits?)

Re:This is stupid

[mxs]

I'm not arguing that Mozilla is going wrong at all. They should be noting and warning about self-signed certs. I was commenting on what you seemed to give as advice on how to proceed. I'll give you a.), but remain attached to c.). You are not required to understand everything you do. This may be a bit of a user interface issue (the message could give some more advice on how to proceed in that case, for instance), but you do not need to understand the nature of self-signed certs -- you merely need to understand that the vendor of the browser you are using suggests that it may be bad. It is up to you what to do with that information.

As for my analogies, I am SURE I can find some that are even farther off the mark. Don't tempt me. You seem to have misunderstood my argument, so they may have indeed been either too subtle or too blunt :> The general pattern was quite simply "If you can't understand what is, then you should not be using ." driven to the extreme, and assuming you may have heard of but have no idea what it is other than that has some loose association with .

Re:This is stupid

[mxs]

Naturally, Slashdot stripped out my tag symbols ... bah. Insert UNDERLYING TECH and DEPENDANT TECH where appropriate.

Re:This is stupid

[QuietLagoon]

ok. but FF needs a way to KNOW that your friend told you that his Self-signed Certificate is OK.
.

The way FF3 knows the certificate is OK is that I click on the OK button. FF does not need to know about any conversations or information exchange between me and my friend. All FF needs to know is that I want it to accept the self-signed certificate.

Re:This is stupid

[forgotten_my_nick]

"if he can safely pretend to be https://cidybank.com/ [cidybank.com] with the lock icon?"

I think anyone slightly savvy would cop on that it was a phish site and select the "Help->Report Web Forgery" menu option so that they don't have waste their weekend uninstall spyware off their parents machine.

Re:This is stupid

[QuietLagoon]

Because firefox 3 knows that on the internet, nobody can tell if you're a dog. or for that matter, if you're *really* talking to your friend.
.

All FF3 has to know is that I want it to accept the self-signed certificate. Period.

Then FF3 should provide a good UI to accommodate me.

Re:This is stupid

[duffbeer703]

Nope, that's just half the point of SSL. Encryption is the other half of the point.

Encryption is useless without trust. You could use the most powerful encryption system conceived, but if you send the message to the wrong person -- you're still compromised.

And un-signed sites are not blocked at all, and show no warning of any kind. Face it: that is really weird.

Not at all. I don't care about the authenticity of Slashdot posts, so signing or encrypting them is of no value. When I do care about the security and integrity of the data, having some third-party validation of who I am connecting to is essential.

All of the issues brought up against this measure are bunk, laziness, or ignorance of how the trust model works. The system isn't perfect, but its better than the alternative.

Re:This is stupid

[squiggleslash]

You need to identify yourself to the CA before they issue an SSL certificate. Even the cheapest CAs do this.

Honestly, buying an SSL certificate for a phishing site is like breaking into people's homes, stealing their TVs, and leaving a calling card with your full name and address in its place. SSL certificates identify the websites you connect to as genuine by ensuring there exists a chain of accountability.

Re:This is stupid

[squiggleslash]

You can remove the alert box for HTTP, because nobody expects HTTP to be secure in the first place.

I'm amazed, frankly, at the number of "Why is it that the system that leaves the user with a false sense of security gets more warnings than the one the user doesn't expect to be secure in the first place" complaints.

Re:This is stupid

[sricetx]

IMHO, the system in Firefox 3 is superior. While self-signed sites are blocked by default, it is not easier to explicitly trust a self-signed SSL site. In the past, most people would just click past the nag dialog when it popped up.

I disagree. The system in Firefox 3 is crap. The old system just asked if the user wanted to add the cert. The new system on the other hand, presents a scary warning and tries to talk the user out of adding the cert. It basically sets up roadblocks to the user getting their task done because the Mozilla foundation is arrogant and thinks they know better than the user. I use self-signed certs on my own servers (just stuff for personal use) and it annoys the hell out of me when Firefox presents me with these "nag" dialogs.

Re:This is stupid

[Nursie]

"All FF3 has to know is that I want it to accept the self-signed certificate. Period."

Indeed. And it does, but after giving you fair warning that you do so at your own risk.

Not even you can really tell if you're talking to your friend, unless he's given you his certificate ahead of time. Which is why we're having this discussion.

Re:This is stupid

[mounthood]

confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.

Let's do it with alert boxes.

LMAO

Seriously though, just split SSL in two. Encrypted connections can be called "Private" and Authenticated connections can be called "Trusted". Users can understand that, and browsers can make rules about Private being required for all Trusted connections.

Re:This is stupid

[Antibozo]

Honestly, buying an SSL certificate for a phishing site is like breaking into people's homes, stealing their TVs, and leaving a calling card with your full name and address in its place.

No, it's like leaving someone else's calling card. Or do you actually believe that phishers use their own credit cards to set up their scams?

Re:This is stupid

[MrCawfee]

that would be all nice if anyone actually reads what those popup boxes say.

and no, no one ever WILL read what the boxes say. this way forces the user to a) read it, b) understand what it means (because if they didn't, they wouldn't be adding an exception)

Having popup windows with the Yes|No really mean "Click yes to make this message go away"

Re:This is stupid

[Anonymous Coward]

Self signed HTTPS: "The communication with this site is secure because it encrypts the data you're sending to it. However there is no guarantee that it's owned by the organization that it claims to belong to.

be careful with this. i'm sure there are users who would be confused thinking "what do you mean, no guarantee? i thought you said this connection was secure!"

also, i can think of a few users who would stop reading after "this site is secure".

trying to educate uneducated users by using popup boxes or warning messages is a Very Bad Idea.

Re:This is stupid

[LeafOnTheWind]

What are you talking about? They're both insecure and if you give a crap about the data you're sending out you shouldn't use either of them. I'll simplify it - do not use incomplete SSL X.509 certificates or any plaintext transmission if you care about your data. Period.

Firefox has the right idea - their page is meant to alert you that, although you're using https, it is not trustworthy. That said, I believe that the X.509 system may benefit from also accepting publicly signed public key certificates, a la PGP/GPG.

Re:This is stupid

[LeafOnTheWind]

Yeah - looked it up, apparently version 3 does support web of trust. Who knew? Still, no one seems to use it...

Re:This is stupid

[thetoadwarrior]

Usability doesn't mean giving any idiot the easy to trash their own computer without having to think.

Re:This is stupid

[Chandon Seldon]

The threat profile isn't quite this simple.

First, if the attacker controls DNS he can probably succeed without any self signed certificate. All he needs to do is intercept the connection to the insecure bank home page and replace the log-in form with one that posts to http s://bank.com-------fakesite.com/ which he has a valid certificate for.

Second, the browser can warn about these certificate swapping attack by simply warning on every certificate change. This will help protect against MITM attacks for both recognized and unrecognized certificates as long as a user's first connection to a given site is hijacked (which isn't perfect, but it's a security improvement).

Re:This is stupid

[Chandon Seldon]

It's more like you're saying that it should be impossible to get a door without a lock. It gets cold in the winter, I'd like a door. I'd like to be able to have some privacy in my bedroom, I need a door. Sure... that's less secure than having locks on those doors, but saying I shouldn't have the choice is absurd.

Re:This is stupid

[marcosdumay]

"How many less-than-savvy users are trained by their more geeky relatives to check for two things - the httpS and the little lock icon."

So don't show the yellow/green bar and lock when accessing sites that use a non-trusted certificate.

Why does it need to show a scary screen instead of the site contents again?

Re:This is stupid

[DMUTPeregrine]

Users don't read alert boxes. This is a bad idea. A small bar at the top or bottom is better, changing the address bar is best. Say, red background for http, yellow for https self signed, green for https signed by a CA. There, simple system, similar to the built-in anti-phishing, and easy to teach. Red = bad already. Green = good. You could even have an alert bar, like FF3 does for passwords and blocked popups, explaining the colour. That way if you get the 1-in-a-thousand user who reads alerts they'll know what it all means.

Re:This is stupid

[Anonymous Coward]

The step that you neglected is that when Joe Phisher fills out the paperwork to get a valid cert, he has now exposed himself to counterattacks from police and lawsuits.

Re:This is stupid

[squiggleslash]

Or do you actually believe that phishers use their own credit cards to set up their scams?

Whether they do or they don't is beside the point. The question is not "Did they pay for their own computer", but "Did they manage to get an SSL certificate from a CA while keeping hidden enough to ensure there was nothing traceable back to them?"

Re:This is stupid

[Antibozo]

Did they manage to get an SSL certificate from a CA while keeping hidden enough to ensure there was nothing traceable back to them?

Yes, and the answer is, "Of course they did, because they're in the business of trading in stolen credentials. Duh."

Re:This is stupid

[Catiline]

If you can't understand what a self signed certificate is, you shouldn't be accepting them.

If you can't rebuild a gasoline powered engine, you shouldn't be operating any vehicles that utilize them.

Apples and oranges, you say? No - not to 99% of the population.

We're technically minded people — the type who want to know how certificate signing operates — while 99% of the world wants it to "just work". While I would agree with your unspoken argument that trust is significant enough to warrant forcing everyone to know the mechanisms, for most people there is as much interest in understanding the "engineering" aspects of that as there is in understanding internal combustion engines.

Re:This is stupid

[Anonymous Coward]

Out of interest, what sites are out there using SSL that non-techie users like your parents are accessing?

I'd of thought every commercial site using SSL to make money wouldn't risk losing your parents, and I can't think of any other sites non-techie users would usually go to.

Re:This is stupid

[Anonymous Coward]

Like anybody actually reads the pop up alert boxes...

Re:This is stupid

[Anonymous Coward]

This is worse than what a real, trusted-third-party signed certificate provides, but it is better than no encryption at all!

Wrong.

A server with a self signed cert provides exactly jack and squat. Encryption without identity verification is completely meaningless, some would argue its worse than plaintext because you have a false sense of security. Training the public to blanket accept self signed certs will simply make it easier to automate these attacks.

If you call up your server admin and ask what the SSL finger print is, then, and *only* then do you have a secure connection. Quick, raise your hand if you've ever done this. Even once.

People get this confused all the time. It's easy to get wrong. Encryption is worthless if your sending encrypted traffic to an attacker.

You have no confidentiality if you don't know who owns the public key, you have no privacy if you don't know who owns the public key, and you have no identity verification if you don't know who owns the public key. (Obviously.)

It's just that simple.

You have to know who owns the key.

Re:This is stupid

[quantumplacet]

I really don't understand what point you're trying to make here. If you don't understand what a self signed cert is, but do understand that your browser of choice thinks it bad, how can you possibly make a reasonable decision about whether or not to accept it? I would agree with you that there certainly are many instances where you can make good use of technology you don't fully understand, but in this case it just doesn't apply. You can use the web without understanding BGP routing, even though BGP routing is essential to web browsing. Continuing even further, one can effectively use certificates, both self signed and CA signed, without fully understanding how the underlying process works. However, if someone does not understand the difference between a self signed certificate and a CA signed certificate, there is simply no way they can make an intelligent decision as to whether or not to accept a self signed cert. Which is exactly the point of my original post.

Re:This is stupid

[Anonymous Coward]

That's what you get for installing an expert tool like Firefox on your parent's system. Just leave them with Internet Explorer and go back to tweaking on your own system.

Re:This is stupid

[Anonymous Coward]

1. It takes about 10 seconds to add a site to the exception list.

2. It takes longer to downgrade Firefox.

3. It takes even less time to say "Sorry Pops, but the site you guys go to is all F'd up. Maybe you should complain to the company that owns it, or stop using it, or wait another 10 seconds while I allow it in the exceptions"

As to the FA, what the F does this have to do with "net neutrality"? If you're going to throw political buzzwords around at least try to use them more in context than the politicians do.

Re:This is stupid

[calica]

Self-signed HTTPS provide security against passive attacks (eavesdropping) but nothing against active (MITM) attacks. Active attacks are simple and easily deployed (especially a wifi cafe setting).

The problem is an attack against a CA signed HTTPS will look EXACTLY like a self-signed HTTPS. Promoting self signing to the untrained will destroy the ability for CAs to secure the web.

Which leads to what the CA actually provides. They provide the financial papertrail to link the cert to the funding source that paid for it. That is a very important link.

Re:This is stupid

[alexborges]

Where can i get this magicall non-verified certificates everyone is talking about?

Last time I checked, you couldnt get it if you didnt send some ID in for the person paying the bill.

Re:This is stupid

[donny77]

Honestly, you know no one that has ever entered credit card information into a non-SSL form? EVER? The average person that does not expect HTTP to be secure is someone who has had their credit card number stolen before via the web. Most people don't know the difference between HTTP, HTTPS and EV-SSL. I would pay for a Root Cert if I was taking personal information or credit card numbers. But I just want an encrypted (not secure) login to a read only site.

Re:This is stupid

[shutdown -p now]

Insecure is less dangerous than encrypted untrusted. How many less-than-savvy users are trained by their more geeky relatives to check for two things - the httpS and the little lock icon. How easy do you want to make it for the phisher if he can safely pretend to be https://cidybank.com/ with the lock icon? Getting "trust" established was one of the hardest thing for e-commerce to do. Anything that undermines it needs to be stamped out.

It's still a browser problem. Fine, so don't show the lock icon, and insert a red question mark after "https" in the URL bar - is that so hard? There's no excuse for freaking out the user and pretending that every site with self-signed cert is up to nothing good.

Re:This is stupid

[shutdown -p now]

Because it is better to know a connection can be snooped than to believe your connection is snoop-proof and be wrong about it.

Then why not just mark a self-signed cert connection as not snoop-proof (i.e., no lock icon / colored URL bar), so that it looks exactly like a plain HTTP connection?

Re:This is stupid

[kju]

So check again. See the low-cost certificates of Komodo and RapidSSL.

Re:This is stupid

[kju]

What you neglected is the reality in which quite a few CAs don't require paperwork for their lowcost certs.

Most clueless article ever?

[gnasher719]

I think it is. Half of SSL is about encrypting a connection, the other half is about knowing whether you can trust the other side. What the article suggests (that SSL connections when the other side uses a self-signed certificate should give no warning) would completely destroy security of the Internet.

Re:Most clueless article ever?

[Hes Nikke]

There is a "warning," and then there is a "WARNING: YOU MUST CLICK FIVE TIMES TO SEE THIS PAGE." A simple bar across the top of the page with a warning that the sites identity couldn't be verified, but that the connection was still encrypted would work just fine.

Re:Most clueless article ever?

[lukas84]

No, it wouldn't. Users need to be protected from themselves, and the Firefox/IE approach is the right way to do this.

Re:Most clueless article ever?

[Anonymous Coward]

Right. If you have personal reasons to trust the server, you can just add an exception, and if you don't Firefox is quite right to warn you.

Re:Most clueless article ever?

[Omnifarious]

What I would like to see is an ssh-like mechanism where Firefox remembers the key previously associated with a website and complains if you appear to be accessing the same website but it's presenting a different key than it did before. Perhaps the existing mechanism of trusted roots could be kept as well, though IMHO, I would like to see that replaced by my scheme as well with an explanation of who the root is and why you should trust them instead.

I do not like Firefox randomly making a decision that certain root CAs are trustworthy and requiring those CAs to give them money for the privilege of being considered trustworthy.

On reading the article, it doesn't sound like the author is totally clueless. Though I do think self-signed certificates deserve a warning of some kind. I really do think that the whole trusted root thing is a bit of a scam and users should be allowed to make choices about who they consider a trusted root.

Re:Most clueless article ever?

[Anonymous Coward]

There is a "warning," and then there is a "WARNING: YOU MUST CLICK FIVE TIMES TO SEE THIS PAGE."

Seriously? They really do that? If so, that's a major nag screen there.

Makes me glad I stuck with Firefox 2 for now.

Re:Most clueless article ever?

[Culture20]

A simple bar across the top of the page with a warning that the sites identity couldn't be verified, but that the connection was still encrypted would work just fine.

No, it wouldn't. A simple step makes the monkeys learn to click. A difficult set of steps makes them think about what they're doing, and possibly check with the sysadmin to verify the self-signed cert. Even worse than a simple step though, is a mere notification. It would be ignored, and encryption without assurance of sender/receiver is essentially worthless (although it does limit your exposure to one bad guy at a time instead of multiple).

Re:Most clueless article ever?

[mikael_j]

I disagree, IMO one warning should be enough, if you're too stupid to figure out your computer then you should get rid of it. I'm serious, I've dealt with way too many users who had no good reason to use a computer to begin with and who clearly barely had the skills to understand directions along the lines of "Now move your mouse pointer to the bottom left corner of the screen and LEFT-click the big button with a flag and the text Start on it.", this is also serious, I have dealt with people who were otherwise intelligent productive members of society who really couldn't figure things out beyond the start menu and "The big blue 'e' gets me my intarwebs", these people should not be protected from themselves.

/Mikael

Re:Most clueless article ever?

[jgtg32a]

I don't think so, there is nothing inherently wrong with a self signed cert. The issue is if you goto a fake bank site and all you notice that the "security lock" is on and you just trust that lock.

When it comes down to it what the user need to know is, is there 3rd party verification, which is what a CA will provide.

The Lock only indicates that encryption is used, it doesn't indicate 3rd party verification. What's really needed is a different "security lock" that indicates 3rd party verification, because that check is what is really needed for users.

Re:Most clueless article ever?

[Anonymous Coward]

The problem is that the padlock icon was invented to indicate an encrypted connection. Some clueless idiot then decided that it meant a verified certificate.

What the clueless idiot should have done is invent a second icon, a big green tick, to signify a verified certificate in conjunction with an encrypted link.

It's too late to change it now. Maybe the next best thing is for firefox to do away with the warnings and in the case of an encrypted connection display nothing extra. Only display a padlock if a chain/web of trust can be established for the certificate.

Re:Most clueless article ever?

[lukas84]

I disagree, IMO one warning should be enough, if you're too stupid to figure out your computer then you should get rid of it.

Yeah, and i would like it if everyone who disagress with me would be shot. Sadly, this hasn't happened yet, nor will it ever.

It's the same thing that you want - you don't want idiots that are almost to stupid to breathe use a computer. This isn't going to stop either - heck, driving a car requires a license, yet i encounter many stupid drivers daily.

It's how the world is right now - deal with it.

Re:Most clueless article ever?

[Kjella]

I think it is. Half of SSL is about encrypting a connection, the other half is about knowing whether you can trust the other side. What the article suggests (that SSL connections when the other side uses a self-signed certificate should give no warning) would completely destroy security of the Internet.

If self-signed SSL sites were indentified similar to "trusted" sites, then yes. But self-signed SSL certificates are a good step up in security over HTTP. For example, anyone only able to wiretap won't get anything at all. Intercepting streams for a MITM is a much more difficult thing to do, particularly if you're talking large volumes in real time. Also you'd get uh-ohs like "This site is now using a different key than last time" and some would compare fingerprints through some other secure channel so mass MITM would easily be detected. To take a stupid analogy, HTTP is the postcard, self-signed is an envelope and trusted is Cerified Mail. It's rather dumb to block the envelopes because people might be misled to think they're secure...

Re:Most clueless article ever?

[Anonymous Coward]

Users are allowed to decide for themselves who they consider a trusted root. Firefox -> Preferences -> Advanced -> Encryption -> View Certificates. Add and remove root certificates to your heart's content.

Re:Most clueless article ever?

[mikael_j]

So why aren't cars made of rubber and only capable of going 20 km/h? Oh that's right, we've chosen to attempts to educate the idiots and force them to pass tests before being allowed to use a computer^Wcar on public roads

One of those "joke" ideas that would actually be kind of funny would be if in order to sign up with an ISP to get internet access you'd be required to pass a basic test that starts along the lines of "click the red square" and ends with "Is the computer in the picture: a) The box under the desk? b) The big thing with pictures on top of the desk? c) The thing on the desk that prints out text on papers?". it wouldn't even compare to the theoretical exam for getting a driver's license here in .se but I suspect the internet population would seriously decrease... (Yes, in Sweden you actually have to know how to diagnose simple problems with your car and know the names of the different parts. And yes, I miss the days when getting online wasn't something that any idiot could accomplish, sure there were idiots online but the vast hordes of drooling mouth-breathing morons were kept out)

/Mikael

Re:Most clueless article ever?

[Mr_Icon]

I actually have dual feelings. On one hand, it's a good policy to give a warning when a certificate is self-signed. That's expected by everyone, I think -- even though FF3's new "omg-wtf" freakout behaviour is totally excessive. On the other hand, relying solely on an SSL certificate to build the trust in a site is also misguided.

A valid certificate (EV or not EV) is not actually a guarantee that you're safe -- it's just a guarantee that you are a) communicating with a domain owned by "Acme Inc", and b) that the connection between your browser and their webserver is encrypted. With so many off-the-shelf CMS systems available these days, it's common for companies to install a version of Wordpress/Joomla/Wassname and then never patch it, which quickly breeds malware of various degrees of maliciousness. As a result -- yeah, you're talking to "Acme Inc" over a high-grade security link, but that doesn't mean that your credit card numbers in that purchase order are any safer.

With all the work and money being dedicated towards securing the connection and authentication, it's disconcerting to see that nobody is working on communicating to the web client that the application they are accessing was actually deployed by Acme Inc, as opposed to Evil Haxxors. I'm all about strong PKI, but seeing all that effort spent on securing and authenticating the connection makes me wonder when there will be any work done to authenticate the actual code.

Otherwise, it's like building a reinforced door with a card-access scanner, while issuing those access cards to anyone who claims to work for you.

Re:Most clueless article ever?

[caluml]

Yes, that's quite a nice idea. Cache the key fingerprints somewhere, and if they change, that's a much greater sign that you're being MItMing (unless it's within, say, 1 month of the expiry of the original cert). Of course, there's always the chance you got screwed the very first time you connected, but it's minimal.
Perhaps it could be implemented via a plugin - I don't know - I don't know anything about the Firefox architecture, or how deep plugins can reach.

Mod the parent puppy up.

It's been 4 minutes since you last successfully posted a comment. Oh, FFS. Sort it out, Slashdot.

Re:Most clueless article ever?

[Omnifarious]

Yes, and people can remove Media Player and IE from their computers too.

Re:Most clueless article ever?

[gbjbaanb]

why would notification be ignored? We already teach people to check the padlock for secure comms, and that was accepted practice for some time.

If the address bar turned amber instead of red/green then that would be ok - the user can be told, if it turns amber you need to check that its ok. Once a certificate is added via the clickety-click method, then there is no additional warning. So once a user is taught how to do that, they're unprotected. Its a bit like UAC - once you've seen it a couple of times, you start clicking 'yes, I do want the f**' without even looking.

A different notification would be sufficient. People may not be technically savvy enough to understand certificate lists, but they are competent enough to know that a flashing amber address bar means to do their own checking (or call someone).

Re:Most clueless article ever?

[Anonymous Coward]

"if you're too stupid to figure out your computer then you should get rid of it. "

No computer should be so hard to figure out that surfing the net should be a dangerous activity...this is not the fault of users, it is the fault of companies that make software that is 'good enough'.

"I've dealt with way too many users who had no good reason to use a computer to begin with"

You mean other than the fact that it is growing to be the #1 way of getting information, communicating with others and you pretty much can't be employed unless you keep up with the latest systems? Yeah...no good reason to use one.

Beyond that, I believe that folks that cannot figure out the social aspects of life should be removed from the human race because obviously they are too stupid to figure it out from their neural Bayesian algs....and even brute forcing it from simple rules like DON'T BE A FUCKING NERD doesn't work...well, obviously they are too stupid and need to be removed.

Having said this, I don't think you are any more broken than the people that you are railing against, but I do think you have just as many problems. Obviously, while they were learning to interact with each other, you were learning the command line. Maybe its time you put down the keyboard and go outside and look at your own advice from another perspective. I know, I know...it is hard to be an angsty teen (40-year old???) and realize that your snarkiness is just a protection mechanism to ensure that your sense of superiority is intact.

-- Just doing my part to help all the socially inept railing against the system...

Re:Most clueless article ever?

[Anonymous Coward]

hmm, see, I've already stopped paying attention to the warning. My mind just says "oh stupid ff, yeah add an exception" now. click, clickity click click-click and it's done. At first I paid attention, but it happened so much that now I ignore it.

Re:Most clueless article ever?

[mikael_j]

No computer should be so hard to figure out that surfing the net should be a dangerous activity...this is not the fault of users, it is the fault of companies that make software that is 'good enough'

A computer is a general purpose device, if your car was also capable of painting your house, digging drainage ditches and flying to the moon then it would require a certain amount of understanding to operate.

You mean other than the fact that it is growing to be the #1 way of getting information, communicating with others and you pretty much can't be employed unless you keep up with the latest systems? Yeah...no good reason to use one.

Clearly you have a pretty narrow view of the world, I worked in tech support, customer services and helpdesk for a total of about 2.5 years and there are a lot of people out there who essentially use their computer+internet connection to email pictures of their dog to their friends or who use the same piece of software all day every day at work yet they need to call helpdesk at least once a week because they someone forgot where the huge Print button was and got scared. These are people that for the most part don't need to use a computer or the internet, at least not in the sense that one generally thinks of it, a specialised device for exactly what they want to do? Sure. A general-purpose computer? No.

Beyond that, I believe that folks that cannot figure out the social aspects of life should be removed from the human race because obviously they are too stupid to figure it out from their neural Bayesian algs....and even brute forcing it from simple rules like DON'T BE A FUCKING NERD doesn't work...well, obviously they are too stupid and need to be removed.

And here come the troll ad hominem attacks.

Having said this, I don't think you are any more broken than the people that you are railing against, but I do think you have just as many problems. Obviously, while they were learning to interact with each other, you were learning the command line. Maybe its time you put down the keyboard and go outside and look at your own advice from another perspective. I know, I know...it is hard to be an angsty teen (40-year old???) and realize that your snarkiness is just a protection mechanism to ensure that your sense of superiority is intact.

What would the problems I have be? I mean beside the fact that I'm bitter about how so many people seem to think they're entitled to be protected and babied and not have to learn anything?

Also, I have a rich social life, always had. But I also have always been interested in computers and electronics (among other things) and I make it a point to try to understand things that I use on a daily basis.

Interestingly enough both your guesses about my age missed the mark.

/Mikael

Re:Most clueless article ever?

[shaitand]

What kind of arrogant sob assumes he is the one who is superior and knows what choices the users should make?

'The connection is secure but the identity of the site has not been identified.'

Tells the user in non-technical terms what is occurring. The user has then been presented with all the information they need to make an intelligent choice. Assuming your choice for what the user should do is the more enlightened approach is arrogant and presumptive.

Yes, the vast majority of people are morons that doesn't justify babysitting them. They have the right to be morons and to do moronic things.

Re:Most clueless article ever?

[Chutulu]

if you're too stupid to figure out your computer then you should get rid of it

Should you get rid of your TV if you are too stupid to understand electronics and quantum physics?

Re:Most clueless article ever?

[lukas84]

Yes, the vast majority of people are morons that doesn't justify babysitting them. They have the right to be morons and to do moronic things.

As far as i know, even the US has speed limits.

Re:Most clueless article ever?

[Anonymous Coward]

"Clearly you have a pretty narrow view of the world, I worked in tech support, customer services and helpdesk for a total of about 2.5 years"

Wow! With that skillset, you are right. You *ARE* obviously smarter than the rest and obviously able to judge someone's worth. ..Especially when railing against the people that employed you.

I got out of computers 10 years back. I still occasionally take off the white coat and stop down in the IT basement office and hang...I actually fixed a bit of code for one of my friends that couldn't figure out what was going on (it was a simple SQL statement that was hanging the system when we had patient lookups...nothing was indexed, and even if it was, it was way too broad with the application loading everything and sorting from within there). If I were a snarky sort, I would have told my friend he was too fucking stupid to be in the business he was in and should obviously find something new because anyone with a brain knows how dead simple something like JOIN statements are. It isn't like straight C where you have to do your own memory management (seriously, do the schools even teach this skill any more???) But instead, I felt I could teach him something...and when he came back a week later and asked me something almost exactly the same, I helped him again (and realized that what he was doing wasn't that much different, but enough so that it would be confusing).

It is easy to pretend that you are better than others. I know I use to think I was. Switched careers and now a junior member of staff that has to prove himself every day and realize when I have ask for some patient diagnostic code that other can whip off on the chart without thinking, or asking for a second opinion...I realize no matter what field you are in, someone is going to think they know more than everyone else. And I see these people sitting back in their offices talking about how some people just need to die because they just don't get it. Not all...in fact, it is just a few that others just let go on and on without stopping them and making the rest of us look bad.

Every profession has nerds that love their knowledge more than people...and use that knowledge of technology or esoteric information or whatever that no one outside the field has a need to understand to point at those that don't know and act as if they are better.

"And here come the troll ad hominem attacks."

BTW -- when you do it, it is insightful, but others pointing out the same this is a troll attack. Maybe you need to reread what you posted.

Re:Most clueless article ever?

[42forty-two42]

99% of the userbase would ignore that bar, and log into their bank anyway.

Re:Most clueless article ever?

[Anonymous Coward]

Trouble isn't that there's lots of clicking involved, it's that the standard warning message looks a lot like the standard "we can't find this webpage" message and so lots of people won't bother reading it and just assume the site's broken

Re:Most clueless article ever?

[Anonymous Coward]

You may be encrypting the data but it is not safe from a man-in-the-middle attack. So the warning would have to be that the data stream is obfuscated but is still readable by anyone who takes a little trouble beforehand.

Re:Most clueless article ever?

[Haeleth]

No, it wouldn't. A simple step makes the monkeys learn to click. A difficult set of steps makes them think about what they're doing

Um, no. A difficult set of steps makes the monkeys either learn to perform a difficult set of steps, or stop using Firefox 3 and go back to a less secure browser because it's less hassle to use.

This causes real problems.

[Daryen]

I encourage all of my users to use Firefox by including it on our PC images, showing them it's cool features, and letting them know about how it's more secure. I've been running into problems with self-signed SSL certificates though.

I run a router/firewall based on the Untangle software, which in turn is a modified Debian/Knoppix setup. It also does VPN, based on the open source openVPN software, and it uses self-signed SSL certificates for it. While I don't mind adding our firewalls to a safe list, my users freak out with all of the warnings and aren't sure what they should do. I've been telling them to use Internet Explorer, but it makes my skin crawl to say it. Hopefully the Mozilla team will reconsider their position to make their software more open-source friendly.

Re:This causes real problems.

[lukas84]

Why don't you just deploy the self signed certificate to all your users?

Or, if your users vary that much, just buy a certificate für 29$ a year?

Besides, IE gives ugly error messages too when accessing a site without a validated trust chain.

Re:This causes real problems.

[Culture20]

Why not use your own private CA and add that CA to your FF deployments?

Re:This causes real problems.

[caluml]

Speaking of ugly: What is this für currency you speak of? Farsi quarter-rands?

Re:This causes real problems.

[Anonymous Coward]

This is the point that everyone is missing. Money isn't the only obstacle to getting a real cert. When you're a software or hardware developer distributing something with a web-based interface, an authority-signed cert is not even an option.

You could ask users to make their own (yeah right), but that's about it. Such devices (routers & firewalls, for example) are already ubiquitous, and will become increasingly so as more devices become web-connected. The result of Firefox's SSL policy is that:

1) Users will switch to a product that does not use SSL, compromising their security.
2) Users will switch to IE/Safari

I've supported Firefox since way before 1.0, and I still think it's the best browser out there. It makes me really sad that I now have to recommend Safari or IE, simply because of this abusive SSL policy.

Re:This causes real problems.

[lukas84]

I meant to spell "for". The "o" was a typo though, an Umlaut to be specific. Slashdot's broken UTF-8 supported converted it to what you're seeing now.

Re:This causes real problems.

[Anonymous Coward]

Internet Explorer 7 has an even more dire warning about self-signed certificates than Firefox 3 has. Worse, you need to unintuitively click on the red X to proceed to the site (clicking on the green check mark closes the tab), so most users cannot figure out how to ignore the warning. Finally, Internet Explorer 7 gives no easy way for the user to add the certificate as an exception as Firefox 3 does, so they will see the warning again the next time they try to access the site.

If anything, using Firefox makes it easier to access sites with self-signed certificates than using Internet Explorer. Why is it that I keep hearing complaints about Firefox and not Internet Explorer, when Internet Explorer is worse?

Re:This causes real problems.

[Anonymous Coward]

Since you include Firefox in the PC images, you should also include your self-signed certificate in the Firefox profiles. That way your users will never see any scary warnings.

Re:This causes real problems.

[jesser]

Hopefully the Mozilla team will reconsider their position to make their software more open-source friendly.

The problem isn't Mozilla being "not open-source friendly". The problem is the other software you refer to not being Web-security friendly.

Re:This causes real problems.

[Lanboy]

You are a lazy clown. Write the instructions down. Email them.

  You would think that a security admin might have a little bit of gumption rather than saying, use IE.

Re:This causes real problems.

[caluml]

Yep - I guessed it was fur. Just funning with you.

This article should be tagged flamebait

[Anonymous Coward]

"...I've written an article criticizing the behavior in Firefox 3..."

This reads like flamebait.

Yeah it stinks, but

[tphockenberry]

As the article admits, you can import the cert and access any SSL website. It's kinda weird to write an article about using a scary "you are being hacked" warning and then post a scary "firefox 3 doesn't let you use SSL unless you pay" statement.

I'd like to make my own decisions please.....

[ocularb0b]

Yeah this is no good. And its a real shame that it comes from the "good" browser. I'd expect this from safari or IE. All we need is the information about the cert. Let the user decide if he/she is ok with using the site.

Re:I'd like to make my own decisions please.....

[Hes Nikke]

I can't speak for IE, but safari pops up a sheet telling the user that the site has an untrusted cert with 3 options: use the cert once (you'll get the warning again,) always trust this site, and don't load the page. i think this is how firefox should behave (perhaps even loading the page and then warning the user)

Re:I'd like to make my own decisions please.....

[ip_vjl]

i think this is how firefox should behave (perhaps even loading the page and then warning the user)

That would be an absolutely terrible thing to do ("load the page and then warn the user").

A page request can contain variables passed via POST or GET, as well as cookies. If the site is NOT the site you want to visit, passing that information ahead of time would mean your sensitive information is already gone before you've had a chance to stop it.

It's really not that big of a deal. I've added the self signed certs for a few development boxes and one web site and never get bothered again. In fact, the easy ability to add the self signed cert permanently is better than the behavior from FF2 where I would be prompted every time. This at least would warn me if the cert changes (man in the middle).

I understand I am "more technical" than your average web user, and know what I'm doing when I do this. However, your "average" web user is less likely to even encounter a self-signed certificate than I am, as they tend to stay tied to a few larger commercial sites. I think the extra warning is a good thing as it may cause them to ask someone more knowledgeable what to do.

Re:I'd like to make my own decisions please.....

[paziek]

That would be an absolutely terrible thing to do ("load the page and then warn the user").

So you have been already fooled to send some data to some site that you know shit about, and you believe, that FF3 will protect you from delivering that data to that next scammer site, that is actually using SSL encryption?
And this assumes that this next scammer site IS using SSL encryption, since if it doesn't, then FF3 will gladly send the data.
Why all that effort? I mean.. just make it send data to the site this idiot is already in and voila! Yet another moron scammed.

And hey! Do you really check source of all those forms that you fill, before sending it? You know.. to make sure it has https:/// in its action value. And why would you fill those forms in the first place?
And no, Cookies won't be sent to a different domain, that they originated from. Unless you were attacked via XSS, but thats different story

btw. my point is not telling that CA or SSL is useless, this post is entirely related to parent post.

Damn right you are.

[w4rl5ck]

For some small sites, we need to encrypt traffic to protect consumer data from being "spyed on" by misconfigured switches, WLAN eavesdropping, and so on.

For those sites, buying a certificate is possible, but the costs are high compared to the gains (as this is *only* about protection of the data, not about "being sure this is site XY). Based on the certificate IDs/hash it's possible in this environment for anyone to compare whether the certificate is a trustworthy one, or not. The certificate identification is, in this case, possible.

But it's a lot harder to explain why this really, really scary message (it scares the HELL out of customers) appears now and then, when someone moved to a new computer or something.

The old FF2 behaviour was "better" in this respect.

I also see benefits of the efforts made to clarify this encryption/identification stuff for normal users, like the green address bar. That's really a gift, showing the user "everything all-right with your banking application or amazon store".

But this behaviour marking "self-signed" certificates as something über-evil out of the deepest depth of hell, is crossing a line a bit to far, in my opinion.

A short warning with a better explanation, or even a yellow bar - encrypted, but not "that secure" - might have been a better way.

Well, patches welcome, I hope :)

Still better than just praying the 2012-expected Internet Nightmare 9 misteriously replacing the old behaviour with something worse. You know what I'm talking about, are you? ;)

Re:Damn right you are.

[Culture20]

For those sites, buying a certificate is possible, but the costs are high compared to the gains (as this is *only* about protection of the data, not about "being sure this is site XY).

If my data needs encrypted, you'd better be sure as a client I want to know it's going to the right place. As the server, you probably don't care (but you should). You don't want to spend $$ to get a cert with a browser pre-installed CA? Fine, but please provide a way to contact your company through the yellow pages or some other non-website contact info that allows people to call a real person and verify the SSL cert. 99.999% of people won't, but sysadmins will.

Re:Damn right you are.

[DMUTPeregrine]

"If my data needs encrypted," well, there's your problem. And I'm not talking about the grammar error, I mean that you think there is a good reason any data transmitted over the internet shouldn't be encrypted. Your data, all data, should be able to be encrypted, and should be encrypted by default.

Average user and security

[RomSteady]

The average user doesn't notice any security feature unless it is in their face.

Given the number of phishing sites out there, it could be argued that every additional slap to the face that a user would have to get through in order to get to a phishing site (known phishing site, self-signed SSL, acknowledge that you are a fucking retard for bypassing the last two warnings, etc.) may be worth it.

Just remember that just because the precepts of net neutrality (all bandwidth is equal) means that we should let a user shoot themselves in the head doesn't mean that we shouldn't at least make a passing effort to put a safety on the gun they are using.

Re:Average user and security

[TheVelvetFlamebait]

Given the number of phishing sites out there, it could be argued that every additional slap to the face that a user would have to get through in order to get to a phishing site (known phishing site, self-signed SSL, acknowledge that you are a fucking retard for bypassing the last two warnings, etc.) may be worth it.

That makes perfect sense, except, when it comes to things we don't like here on slashdot, we don't allow half measures. If it doesn't 100% eliminate phishing, then all it does is piss off legitimate users, while providing no additional security benefit.

How about a plugin?

[dattaway]

Is it wrong to have quick and dirty arbitrary secure end to end connections?

glowbull WARMongerING execrable bad for all

[Anonymous Coward]

one needs only to pay attention, which is cost effective, & could lead to our survival. see you there? the lights are coming up all over now. conspiracy theorists are being vindicated. some might choose a tin umbrella to go with their hats. the fairytail is winding down now. let your conscience be yOUR guide. you can be more helpful than you might have imagined. there are still some choices. if they do not suit you, consider the likely results of continuing to follow the corepirate nazi hypenosys story LIEn, whereas anything of relevance is replaced almost instantly with pr ?firm? scriptdead mindphuking propaganda or 'celebrity' trivia 'foam'. meanwhile; don't forget to get a little more oxygen on yOUR brain, & look up in the sky from time to time, starting early in the day. there's lots going on up there.

http://news.google.com/?ncl=1216734813&hl=en&topic=n
http://www.nytimes.com/2007/12/31/opinion/31mon1.html?em&ex=1199336400&en=c4b5414371631707&ei=5087%0A
http://www.nytimes.com/2008/05/29/world/29amnesty.html?hp
http://www.cnn.com/2008/US/06/02/nasa.global.warming.ap/index.html
http://www.cnn.com/2008/US/weather/06/05/severe.weather.ap/index.html
http://www.cnn.com/2008/US/weather/06/02/honore.preparedness/index.html
http://www.nytimes.com/2008/06/01/opinion/01dowd.html?em&ex=1212638400&en=744b7cebc86723e5&ei=5087%0A
http://www.cnn.com/2008/POLITICS/06/05/senate.iraq/index.html
http://www.nytimes.com/2008/06/17/washington/17contractor.html?hp
http://www.nytimes.com/2008/07/03/world/middleeast/03kurdistan.html?_r=1&hp&oref=slogin
http://biz.yahoo.com/ap/080708/cheney_climate.html

is it time to get real yet? A LOT of energy is being squandered in attempts to keep US in the dark. in the end (give or take a few 1000 years), the creators will prevail (world without end, etc...), as it has always been. the process of gaining yOUR release from the current hostage situation may not be what you might think it is. butt of course, most of US don't know, or care what a precarious/fatal situation we're in. for example; the insidious attempts by the felonious corepirate nazi execrable to block the suns' light, interfering with a requirement (sunlight) for us to stay healthy/alive. it's likely not good for yOUR health/memories 'else they'd be bragging about it? we're intending for the whoreabully deceptive (they'll do ANYTHING for a bit more monIE/power) felons to give up/fail even further, in attempting to control the 'weather', as well as a # of other things/events.

http://www.google.com/search?hl=en&q=weather+manipulation&btnG=Search
http://video.google.com/videosearch?hl=en&q=video+cloud+spraying

dictator style micro management has never worked (for very long). it's an illness. tie that with life0cidal aggression & softwar gangster style bullying, & what do we have? a greed/fear/ego based recipe for disaster. meanwhile, you can help to stop the bleeding (loss of life & limb);

http://www.cnn.com/2007/POLITICS/12/28/vermont.banning.bush.ap/index.html

the bleeding must be stopped before any healing can begin. jailing a couple of corepirate nazi hired goons would send a clear message to the rest of the world from US. any truthful look at the 'scorecard' would reveal that we are a society in decline/deep doo-doo, despite all of the scriptdead pr ?firm? generated drum beating & flag waving propaganda that we are constantly bombarded with. is it time to get real yet? please consider carefully ALL of yOUR other 'options'. the creators will prevail. as it has always been.

corepirate nazi execrable costs outweigh benefits
(Score:-)mynuts won, the king is a fink)
by ourselves on everyday 24/7

as there are no benefits, just more&more death/debt & disruption. fortunately there's an 'army' of light bringers, coming yOUR way. the little ones/innocents must/will be protected. after the big flash, ALL of yOUR imaginary 'borders' may blur a bit? for each of the creators' inno

four clicks

[Bazman]

In four mouse clicks I've added that site to my exceptions list. It warned me, I read and understood the warning, I acted. I saw the https page and the web site owner didn't have to pay for a certificate.

So, the article is wrong:
"Mozilla Firefox 3 limits usable encrypted (SSL) web sites to those who are willing to pay money to one of their approved digital certificate vendors"

please add 'or click four times to add the site to an exception list'.

Re:four clicks

[urcreepyneighbor]

In four mouse clicks I've added that site to my exceptions list. It warned me, I read and understood the warning, I acted.

Good for you, but people like you - and me and the rest of the people here - aren't "normal". Grandma won't know what the hell to do (besides call you). She might even think "those evil hackers" "got her".

Self-signed certs are a potential problem, but Firefox could have worked out a better way of handling it. A more novice-friendly way.

Basically, we need Bruce Schneier and Jakob Nielsen to marry and have children. We'd better contact Dr. Moreau to work out the breeding program. :)

Re:four clicks

[Anonymous Coward]

And how many times do you plan on phone-walking Aunt Tillie through that procedure?

Come on, I'm an IT professional myself and I understand the importance of secure trust chains, but *four clicks* is at least two too many.

Re:four clicks

[morgan_greywolf]

And how many times do you plan on phone-walking Aunt Tillie through that procedure?

You fail to give Aunt Tillie enough credit. There's a nice big link at the bottom to add an exception. You click that, and then, as you can see from the dialogs, it actually almost forces you to read the certificate info so that you can decide for yourself whether you're still going to allow the exception. The idea is to make you think about what you're doing. I think the author just has a stick up his arse about having to click 4 times when working with test sites/servers, which often use self-signed certs since no one really cares.

Re:four clicks

[Nursie]

"Grandma won't know what the hell to do"

And Grandma doesn't care about getting secure access to your blog.

She cares about reading the news, chatting about knitting on the wool forum, sending email to the grandkids and accessing her bank account. Only the last one requires encryption, and for that you want full third-party authentication.

Streamlining this process or just warning Grandma will leave her with an empty bank account in no time.

Re:four clicks

[darklich14]

Amen! That was my original reaction when I saw the title of the article. Nothing is restricted other than the time it takes to get to page with a self-signed cert.

Some people....

Re:four clicks

[FrozenFOXX]

Good for you, but people like you - and me and the rest of the people here - aren't "normal". Grandma won't know what the hell to do (besides call you). She might even think "those evil hackers" "got her".

A little paranoia is a good thing. If the person can't be bothered to make certain they want to visit a potentially untrusted "SSL-encrypted" site maybe they shouldn't be using the Internet for what they're wanting to do.

I don't know about you, but my grandmother has no problem doing this kind of stuff. My grandmother-by-law does. One uses the Internet regularly, the other uses the postal system and brick-and-mortar stores. It's not the end of the world if a "grandma" as you put it doesn't use the Internet.

Maybe we should worry more about you and me than "grandma."

Re:four clicks

[tepples]

If the person can't be bothered to make certain they want to visit a potentially untrusted "SSL-encrypted" site maybe they shouldn't be using the Internet for what they're wanting to do.

Likewise, if the person can't be bothered to make certain they want to visit a potentially untrusted "unencrypted" site that requires registration, maybe they shouldn't be using the Internet for what they're wanting to do.

Re:four clicks

[DMUTPeregrine]

You read the warning. That puts you in a separate category from 90+% of users. Then you understood it. Now you're in the top 1%. Many UI designers fail to understand that users do not read dialog boxes, warnings, error messages, or anything else. Years of windows "Exception 0xFFEEABA1432534 at 0xFA582446774645 have caused the thingamabob to bignumber2sopbyybasoutb." type errors have made users ignore even clearly written dialog boxes and instructions. Read User Interface Design for Programmers to get a better idea of this and how it matters.

Re:four clicks

[Anonymous Coward]

That is true and I agree with this comment. BTW what do you say about IE7 and it's warning about bad certificate... It is bit more "scary" than it is in firefox.

https

[Anonymous Coward]

fta:
"This is really an issue of the basic principles of internet openness. Everyone has equal access to the features of HTTP or SSH, there's no reason why there should be artifical constraints on access to HTTPS. But that's exactly what the Firefox SSL behavior does."

The above statement makes it sound as if SSH and HTTP(s) are related. Quick summary:

http
ssl
https = http + ssl
ftp
ftps = ftp + ssl

ssh/sftp (they stand alone)

Blocking Self Signed Certificates is GOOD!

[PC and Sony Fanboy]

I'm not sure what the problem here is - If a website claims that it isn't part of the malware revolution with a self signed certificate, it isn't any more authentic than NOT having one.

The only real use for a self signed certificate is for large institutions that already have the trust of the user (ie: universities) - but you have to assume that they havn't been compromised, because it would be easy to have a second certificate, signed by the owner of the hijacked site.

Anyways, firefox 3 does a great job, and it isn't hard to add an exception - and it isn't annoying like UAE...

Re:Blocking Self Signed Certificates is GOOD!

[Anonymous Coward]

and it isn't annoying like UAE...

Why not? Even Vista doesn't cause as many hoops to jump through to make sure the user is sure.

Re:Blocking Self Signed Certificates is GOOD!

[Anonymous Coward]

I'm not sure what the problem here is - If a website claims that it isn't part of the malware revolution with a self signed certificate, it isn't any more authentic than NOT having one.

Yep, and Firefox makes it significantly harder to browser self-signed sites than it is to browse encrypted (HTTP) sites. Umm.. why, exactly? Because their model is broken in assuming everything HTTPS is trusted all the time?

Non-issue?

[Anonymous Coward]

Surely this is the same as has been implemented in all browsers since SSL came along? the only real difference here is in how the message to the user is displayed. Previously, a dialog box would have popped up warning the user, and most users would automatically scan for the OK button and click it without giving it further thought, or indeed reading the dialog box.

Because this message appears where the page would normally appear, people seem to be actually taking notice of it. It's not about net neutrality, it's about trust. There are a number of trusted root certificate people out there, and that number is small for a reason. If everybody could create a trustworthy certificate, then what would be the point. It's a shame users have in the past been so useless at exercising judgement in what sites are trustworthy and which aren't.

At least now, they are forced to consider the implications clicking through, and that can only be a good thing.

trust?

[Animaether]

what do you mean, trust?

An SSL certificate automagically means that it is impossible for the site to be hacker, or some guy internally running away with sensitive data, etc. ?

At best, it will say "Why yes, this -is- the website you are looking for.".. beyond that, there's no more trust than I would give a warezyporn website hosted on a .tk domain.

SSL may not be just for encryption, but perhaps it should be.. or should have been. It should never have served this dual purpose - and the story explains quite nicely -why-.

Re:trust?

[frodo from middle ea]

That was my implied point, the author of the article should be complaining about the trustworthiness aspect of the SSL, and not mozilla's policy about accepting self signed certificates. As things stand today, SSL means 2 things a) encryption and b) trust (i.e. the site is what it claims it is). And to provide the part b, it relies on the concept of CAs. Now whether this is a good thing or just a money grabbing policy by the big CAs is a totally different thing, but what Mozilla is doing is nothing wrong. May be they can have a easier way to import a self-signed certificate, rather than having to go through 3/4 clicks as it stands now, but I sure wouldn't want that warning to go away the first time. I am completely aware that all it takes to buy a certificate is money, but that is not mozilla's or SSL's fault, it is rather the fault of the companies behind the CA business.

Re:trust?

[Urkki]

SSL may not be just for encryption, but perhaps it should be.. or should have been. It should never have served this dual purpose - and the story explains quite nicely -why-.

But SSL (or any communications protocol for that matter) can't be just for secure end-to-end encryption. Simply impossible.

If you don't have a shared secret, you need some kind of certificate authority that is known beforehand by both parties. With self-signed SSL certificate, you have neither, and therefore you don't have end-to-end encryption either. Well, you may have if nobody wanted to intercept your connection, but you have no way to know, and that can be even worse if you falsely believe you have secure connection.

Re:trust?

[shaitand]

No the author has a grip. If you haven't added the root for OpenCA go to www.openca.org with your firefox 3 and look at what you are presented with.

If you try to go forward it presents you with a HELP GET ME OUT OF HERE button an option to add an exception, then on that exception adding window it blatantly says that no legitimate website would require you to do this. In other words, it blatantly accuses all self-signed sites of being a scam.

Re:trust?

[shawb]

Except that unsigned encrypted transmissions are open to man in the middle attacks, meaning that self signed SSL is potentially MORE dangerous than unencrypted as the existence of the encryption layer gives the end user a false sense of security. Hence, the need for certificates in the first place.

Re:trust?

[Nursie]

"If you don't have a shared secret, you need some kind of certificate authority that is known beforehand by both parties."

Not quite true. There are a couple of ways to achieve this.

Public/private key way - Client comes up with a session key, uses the server's (untrusted) public key to encrypt. The server is then the only party that can decrypt it with its private key.

head-asploding mathsy way - Diffie Hellman

When I tried to get my head around DH it was painful, but it *looks* painfully simple. Anyway, there are two ways of acheiving sniffer-proof end to end encryption with no authentication and no third party trust.

Authentication is still very important - with these methods you are still vulnerable to classic MITM attack.

Re:trust?

[Urkki]

Anyway, there are two ways of acheiving sniffer-proof end to end encryption with no authentication and no third party trust.

Authentication is still very important - with these methods you are still vulnerable to classic MITM attack.

If a connection is vulnerable to man-in-the-middle, then it's not really very sniffer proof, now is it...?

Re:trust?

[Nursie]

"If a connection is vulnerable to man-in-the-middle, then it's not really very sniffer proof, now is it...?"

Yes, it is, because you can't decode it from just recording the packets.

I agree that something not MITM proof is a very bad thing, but with DH(E) you can stop people just watching the stream, they have to get involved.

Re:trust?

[Urkki]

I agree that usually just sniffing/recording is at least a bit easier than MITM, and of course MITM will always require a bit more sophisticated software. But these days with switched networks etc, if somebody has the capability to do sniffing (eg. by redirecting data from a hacked switch/router/virtual server host/whatever, or pretending to be a WLAN access point, or plugging a laptop in the middle of a switch/router network cable), then doing a MITM is not really harder. In some cases, network-wise there's no difference between MITM or just sniffing, difference is only in the sniffing software being passive data relay, MITM software being active participant in the connection. And I'm pretty sure plug-n-play MITM software for different cases is readily available at the "black hat" market...

The point is, if you want real security, encryption without authentication is not an option, it's IMHO just wrong to call that security. I guess it could be called obfuscation, to differentiate it from real end-to-end client-to-server security.

Re:trust?

[Kalriath]

I did. OpenCA neither has a CA issuing certificates, nor a root certificate I can download. I was able, however, to get a warning about the certificate on their pages, but you can't solve that because they don't let you get their root.

Re:trust?

[shaitand]

The point had nothing to do with openca and everything to do with the fact that the prompts presented by the browser outright told you the site was not legitimate because it had a self signed cert.

Dont be cheap

[Anonymous Coward]

Dude,

Like has been said, it is mostly saying, yes, this is the person your talking about. Anyway, who really cares? SSL certs arent that fucking expensive, you pay 10 bucks a month for any half assed hosting service anyway, whats an extra 20 a year to have your ssl show up right?

dont be a cheap ass

you cant afford to be too jacobin

[unity100]

"we are programmers and developers, and as a community we think this is the right thing to do" - this does NOT fly. public accepts what they like, they refuse what they dont. this is as simple as that, REGARDLESS OF what they accept or refuse may be good, or bad.

it is utterly stupid to go overly jacobin and enforce something on people 'for improving the security on the web', in an open source project that is made by people FOR the people.

a lot of websites, service owners, businesses using vpn and their clients and their users are going to experience hell lot of problems due to this extreme self righteousness forced upon them, if they go for firefox 3.

to be honest, despite im fighting for free and open internet, linux, open source by the means available to me as much as i can, i will be advising friends and clients to stay away from ff3 because of that certificate issue.

Re:you cant afford to be too jacobin

[Darfeld]

This is ridiculous. No, really it is.

First of all, this is just a warning, like the one in FF2. It's just not in the same place. I really don't understand the issue here. (It is scary? So as long as you don't know the possible danger, it's OK to cross the road?)

Secondly, if a person don't understand this is just a warning and he can bypass it if he trust the site to be safe, I wouldn't let him go without warnings. It may restrain his access for one or two site, but he would be safer until he know better.

Re:you cant afford to be too jacobin

[unity100]

Secondly, if a person don't understand this is just a warning and he can bypass it if he trust the site to be safe, I wouldn't let him go without warnings. It may restrain his access for one or two site, but he would be safer until he know better.

'one or two site' per billion makes millions of websites.

and there is no 'until they know better' for majority on the web. their knowledge of technical matters related to web will stay the same regardless of what is shoved, pushed in their faces.

what kind of thing are you smoking ? or what kind of reasoning is this ?

Re:you cant afford to be too jacobin

[Darfeld]

I don't know if it is optimism or elitism at this very moment.

On one hand I expect anyone capable of learning something as elementary as that, One the other hand I don't want to deal with people who do wan't to.

Still, how many self-certificated SSL site one average person visit in a month? I myself know only two : my school "extra"-net and RTAI webpage. Hardly the kind of site average people cross every day.

Re:you cant afford to be too jacobin

[unity100]

well, the thing is, you can expect a lot of things, but we know that people do what they will do. and both of us know that they wont probably even bother with it.

Bad Article

[MasterOfMagic]

As mentioned on the Firehose comments page about this article (http://tech.slashdot.org/comments.pl?sid=634651&cid=24461415):

CAcert is working to be included by default in all Mozilla Foundation software. CAcert [cacert.org] is based on having certificates for everybody, not just for paying customers. They are already included in many current distro version of Firefox. There's no objection in the Mozilla Foundation to including certificate authorities like CAcert in Mozilla. Mozilla just needs to verify that they are secure - a process that takes a long time and doesn't cost any money - otherwise they could undermine the security of their users. Five minutes of research would have shown this.

For this problem to be solved, the most popular F/OSS browser(s) must accept self-signed certificates. If Mozilla is unwilling to change their policies, it would be worth the effort of trying to create a *more popular* fork with full SSL functionality.

This shows a lacking understanding of computer security practice. Self-signed certificates are something that 90% of users need to be wary of because if you allow them by default, phishing sites will use them to their advantage and steal data, and Mozilla will be blamed for it because they'd be the only one to not warn about self-signed certificates. This is why people are warned and this is why there's already and override procedure in place so if you're one of the 10% of the users impacted by it, you can work around it.

This article seems like an attempt to insert drama where recognized security professionals already have agreed that this is best practice. Wait until CAcert is in Mozilla, and if it gets special treatment by not being treated the same as all of the other CAs, then you'll have something.

If the purpose of the Firehose is to vet articles, it's not doing a good job.

Re:Bad Article

[unity100]

This article seems like an attempt to insert drama where recognized security professionals already have agreed that this is best practice. Wait until CAcert is in Mozilla, and if it gets special treatment by not being treated the same as all of the other CAs, then you'll have something.

'security professionals' do not build the web, or do they constitute the market, or the people.

there are a LOT of community websites (that cater to thousands of people, the smallest one), small businesses, their customers, vpn users, a lot of people that are going to be hurt by this overly self righteous move.

it is easy to be indignant and force stuff upon people, saying 'it is the right thing', while working on an open source project part time, from a secure, corporate level information technology job.

one thinks it seems right for you, and therefore it is probably right for others. of course, all the while clueless about how many people, businesses, organizations and communities use self signed certs throughout the web, just because their isolated position.

Re:Bad Article

[Cutie Pi]

If the purpose of the Firehose is to vet articles, it's not doing a good job.

I don't think the purpose of Firehose is to vet articles. Rather, it's a way for Slashdot to become more Digg-like, and Digg-like content is what we get. Seriously, go back five, even two years ago and try to find front page stories in which some random person writes "I've written a controversial article on X. Click here to see my thoughts". You won't find many, but now you can find them almost daily on Slashdot. And along with the Digg-like content comes the Digg-like users, with all their conspiracy theories, hyperbole, immaturity, and general teenage boy mentalities that has driven away all but said demographic from Digg.

Fortunately, Firehose is only a gateway to the editors, and not a direct route to the front page. Thus, the decline of Slashdot has been more gradual than the decline of Digg. But you'd be hard pressed to find a true geek that isn't longing for the good old days.

And oh yeah, Get Off My Lawn!!

Re:Bad Article

[Nursie]

"there are a LOT of community websites (that cater to thousands of people, the smallest one), small businesses, their customers, vpn users, a lot of people that are going to be hurt by this overly self righteous move. "

Please demonstrate how.

Community websites don't generally need crypto, and if they sell stuff then anyone with half a brain would want 3rd party authenticated comms for doing financial transactions.

A few bucks a year for a cert for their web page won't kill a small business.

If you're a VPN user then it's trivial to set up an in house certification agency and distribute the CA certificate with your client program.

"one thinks it seems right for you, and therefore it is probably right for others. of course, all the while clueless about how many people, businesses, organizations and communities use self signed certs throughout the web, just because their isolated position."

You have a choice -

a) Make and distribute your own CA certificate to those that need it.
b) Pay for a certificate so that you don't have to do this.

Self signed certificates with no prior distribution are DANGEROUS.

Re:Bad Article

[MasterOfMagic]

<flame mode="on">

it is easy to be indignant and force stuff upon people, saying 'it is the right thing', while working on an open source project part time, from a secure, corporate level information technology job.

In all seriousness, fuck you. No, really, fuck you. I am a graduate student. My only support comes from the part time job that I have to pay my tuition and my bills, and a grant for my research. I research computer security. To say what you have said shows zero understanding of computer security, encryption, user behavior, and accountability. Go suck a big fat one.
</flame>

'security professionals' do not build the web, or do they constitute the market, or the people.

This is the ultimate problem with your post. Before I tear it a new asshole (and I'm going to tear it a new asshole - nothing personal, but I hate posts that masquerade ignorance as wisdom), know that the reason that Mozilla is doing this is because security professionals, by and large, do not build the web and are not the majority of the people. This is why they are so picky about security. I have spoken to security professionals and the overwhelming consensus is that accepting self-signed certificates by default is bad. Very bad. Break the whole security and user trust in SSL bad. If user trust in SSL is broken, then we have ultimately failed.

there are a LOT of community websites (that cater to thousands of people, the smallest one), small businesses, their customers, vpn users, a lot of people that are going to be hurt by this overly self righteous move.

Community websites can walk users through installing the proper certificate instead of relying on users to override a secure default for certificates. They can teach the users about the importance of verifying certificate fingerprints (to avoid a man-in-the middle). If they release software, they can bundle their certificate with the software. If there are small businesses, they can install their CA on their user's machines. This then becomes a non-issue. In a secure setup, these entities will generate a self-signed root CA certificate (like any other CA), push that to their users, and then sign the certificate for their website with this CA certificate (thus providing the ability to revoke the encrypting certificate should it become compromised and allow certificate updates/refreshes completely hands-off of the client). <flame mode="on">If you knew anything about SSL, anything at all, you would know this. Instead you assume, and make yourself look like the twit you are. Users hurt by this policy? It's the same policy (a bit more stringent, but the same policy) that the other browsers have.</flame>

one thinks it seems right for you, and therefore it is probably right for others. of course, all the while clueless about how many people, businesses, organizations and communities use self signed certs throughout the web, just because their isolated position.

If they used the certificates securely, understood how SSL worked, and did research, this would be a non-issue. I am not clueless about how people use SSL. I am saying that they are using it wrong, and Mozilla is doing the right thing here. Here's a roadmap for anyone who cares to learn about how to do this properly:

1. Talk to someone who understands SSL, preferably a reputable security professional. I can't speak for the rest of my profession, but I do a first consultation for free because I feel that it's my responsibility as a professional to make sure that people, non-profits, and small businesses are just as secure as the big boys.
2. They will tell you the pros and cons of going with a CA that is trusted by the OS and by the browser by default. They do not, generally, get a kickback for this. They are doing their job. Consider CAcert. It's

Re:Bad Article

[unity100]

its too long a talk to 'demonstrate' these to you, who is someone apparently very uninformed about web communities, shared hosting, privacy issues, and what pricing do the ssl certificate providers ask, for wildcard ssls that many small businesses may need. the web is not only about security, its also about privacy, as it is much more than single standing websites.

Re:Bad Article

[jez9999]

Dunno whether CAcert has anything to do with StartCom, but they offer free basic SSL certs too. I use one for my personal site.

I'd like to have seen Firefox at least treat self-signed certs the same as regular HTTP - that is, at least make it look like a regular webpage with no SSL instead of throwing up a big warning - but with StartCom's certs already accepted in Firefox, you can at least get free SSL that way.

Unfortunately, Opera and IE don't seem to recognize StartCom as a trusted CA. This rather scuppers the idea of free SSL for all.

Re:Bad Article

[unity100]

i didnt read any further than 'fuck you'.

my first, and only advice to you, a graduate student, is this :

learn to speak in proper, civil manner before you rant about ANYthing, if you want to be taken seriously and get your opinion respected on the face of this planet.

there. if i should put in a manner you would be able to understand : now you can shove your flaming and ranting wherever you see fit.

Re:Bad Article

[Nursie]

You have no privacy if you have no authentication, with the current DNS attacks and the prevalence of wireless access, you need authentication more than ever if you want any explanation of privacy.

I work on SSL/TLS professionally, so I'm genuinely interested in your privacy issues and how they are better being served without a certification authority. Because to me, without authentication, you may as well not bother.

Which is why I said you have those two choices. I'm not insisting you pay for certificates - become your own authority by all means - but don't expect to get by without one.

In fact, if you aren't going to run with any sort of authority (internal or external) you may as well not bother with a certificate, as SSL/TLS will still provide you with unsniffable encryption, but leave everything just as vulnerable to MITM attack.

Re:Bad Article

[Anonymous Coward]

If the purpose of the Firehose is to vet articles, it's not doing a good job.
This is a story posted by kdawson. If you look back at the stories that kdawson posts on the front page, you can tell that he has a bad eye for stories.

Re:Bad Article

[Anonymous Coward]

Community websites can walk users through installing the proper certificate instead of relying on users to override a secure default for certificates. They can teach the users about the importance of verifying certificate fingerprints (to avoid a man-in-the middle).

Users don't want to sit through a university-level security lecture every time they open their browser.

What they want to do is visit some website, protected by a self-signed ssl cert, that a friend set up on their home server appliance. That friend doesn't know what an authority is, doesn't want to know, doesn't want to spend money on a cert, and (most importantly) should not *need* to know. Software is supposed to serve users, not the other way around.

This is exactly the problem that the parent post was talking about. My favorite browser, which started out with the goal of making the web easier and more fun to use, is now (apparently) run by people who think users are idiots and need to be "educated" for their own good.

Re:Bad Article

[Matthieu Araman]

No, they are different entities.
I think the problem for CAcert is the Mozilla ask that the ca policy include a 10000$ insurance before allowing the ca with Firefox.
BTW, Startcom has renamed their certificate things to Startssl (https://startssl.org)
For IE, it seems the CA has to pay to be included and this is blocking StartCom as this time.(I believe this is mentionned somewhere on their website)
I don't know for Opera.

Re:Bad Article

[Anonymous Coward]

In the mean time while waiting for CAcert to finish their audit, you can use StartCom SSL www.startssl.com - Free of charge for a CA that is already included in Mozilla, OSX (Safari) and a lot of Linux distributions.

Re:Bad Article

[unity100]

refer to these posts :

http://slashdot.org/comments.pl?sid=634675&cid=24465677

http://slashdot.org/comments.pl?sid=634675&cid=24465741

Re:Bad Article

[Anonymous Coward]

What they want to do is visit some website, protected by a self-signed ssl cert, that a friend set up on their home server appliance. That friend doesn't know what an authority is, doesn't want to know, doesn't want to spend money on a cert, and (most importantly) should not *need* to know. Software is supposed to serve users, not the other way around.

The software is serving you here. Say, someone decides that they are going to man-in-the-middle all SSL traffic. This is not terribly difficult. They just redirect all traffic on port 443 to themselves. This can occur at the ISP level, at any wireless access point not controlled by you, or anywhere upstream from your provider. They substitute their (self-signed) certificate in for your friend's certificate. This is a little more difficult to do, but not impossible. Any proxy server that proxies HTTPS can do this. You see the warning that tells you that you need to double check. You double check, find out that the fingerprint of the certificate that you are receiving does not match the fingerprint of the certificate on your friend's machine, and don't connect. You have just been saved from an SSL MitM.

If Firefox by default didn't stop this, you would have just sent data to the man-in-the-middle. What if you and your friend were exchanging business plans, secret affair love letters, or tax data? Suddenly, this man-in-the-middle has the data and Firefox didn't warn you. Sure, your traffic is encrypted on the wire, but this is useless, because it's not secure from the man-in-the-middle. Someone is still reading your data. This is not security. This is the illusion of security. This is security theater.

This doesn't prevent your friend from using a self-signed certificate, I might add. If you're expecting a self-signed certificate and double check that the fingerprints match, then you're safe now and whenever you connect again. If the man-in-the-middle attack is tried after you've accepted your friend's genuine self-signed certificate, Firefox will now warn you that certificates do not match. You've been saved from another SSL MitM attack.

Re:Bad Article

[Anonymous Coward]

Yes, but the Firehose is wrong. It does cost money to "verify the CA is secure". Read "...provide attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA's internal operations."

"Competent independent parties" are charging CAcert upwards of $10,000, last I read, to do nothing other than rubberstamp. Mozilla might not be the one collecting the fee, but they are certainly complicit in its existence.

Re:Bad Article

[Anonymous Coward]

Funny you can't get past CAcert on secure mode as well. Try this on FF3: https://www.cacert.org/

Re:Bad Article

[Dragoness Eclectic]

Which alternate timeline did you come in from? The Slashdot I remember from 5-10 years ago was *ALWAYS* like this--only back then you had Jon Katz articles, too. Customizing my Slashdot front page to block those really improved it.

Re:Bad Article

[Anonymous Coward]

Users are idiots. Time has proven this to be ultimately true.

Look at all the morons on here making wild claims of what should or shouldn't be done with out of ounce of understanding of the consequences of their actions.

For example I would bet everything I own on more successful mitm attacks if Firefox moved to a bar like the password reminder feature.

What is the reason? People don't know shit. If it isn't annoying and scary they will just *click* *click* *click* until it goes away.

I admit hate that it takes four fucking clicks to allow an exception but it is a necessary evil.

The real problem is *whining* idiots that don't know what they are talking about.

1. Commercialized certificate authorities are flawed. This is obvious and it has NOTHING to do with Firefox's implementation of SSL. If you want to play CA just add the certificate or make your own Firefox package. STOP FUCKING WHINING.

2. CertCA and free CAs not being included are again not the problem. This again has nothing to do with Firefox. There is a certification process and CertCA has not passed and therefore is not included other browsers why should Firefox lower it's standards of security.

3. "restricting encrypted HTTP to paying customers &#226;&#8364;" to a violation of net neutrality" What the fuck is this? Can the moron that wrote the article not figure out the fucking interface? This article is plainly written to push the authors own propaganda.

Finally, If you need to use self-signed certificates it takes a one extra page to explain why you are too cheap to pay for a proper certificate and have the client install the certificate.

If they can't be bothered to do this (90% of users are too stupid) then you need a certificate.

Re:Bad Article

[Abcd1234]

Umm... tough shit? Security is hard, deal with it.

Besides, in general, users *are* ignorant when it comes to security. But I'd rather reduce the odds of someone stealing an ignorant person's credit card details, at the expense of making your friend's life a very tiny bit more difficult.

I do not agree on your article

[Anonymous Coward]

Certificates for most domains can be issued by a trusted root if you can get access to one of a few e-mail addresses on the domain. Other certs can be ordered if you commit fraud and uses false letterhead. So the trusted roots are most often not trusted.

If my browser trusts Equifax, then it basicly gives no security at all.

The only way to get SSL working again, and prevent man in the middle, is by zapping all trusted roots in the browser, and let the user individually accept whatever certs he trusts. He will then get a warning every time a server changes vert.

The trusted roots can stay, so the user has an option to see who issued a new cert.

Why would I trust the security of my online banking, creditcards etc to a company in Uruguay ? Everybody does, as it is a trusted narcs^H^H^H^H^Hroot dealer.

CN = SERVICIOS DE CERTIFICACION - A.N.C.
OU = SERVICIOS ELECTRONICOS
O = ADMINISTRACION NACIONAL DE CORREOS
C = UY

There are some majort issues to trusting so many roots, with different validation requirements.

You are dumb

[duffbeer703]

This isn't an IE/Firefox issue. It's about you being too cheap to buy a validated cert while simultaneously being too dumb to force your users to accept your certs.

If you are running your infrastructure with self-signed certs, just put the certs on your clients.

Re:You are dumb

[Daryen]

If you know of a way to push out certificates to user's home computers that you have no control over I would be very interested to hear it.

Or do most of your users choose to VPN into their work account when they're already at work?

Also, some of us just don't have funds. If I want certs for my organization, they'll have to come out of my own pocket.

Re:You are dumb

[TravisO]

You want him to purchase a certificate for his own firewall for internal users?!?! So you're saying his users shouldn't trust their internal firewall until a commercial license is made with the outside world.

This is where I have to agree with other people on here that for some people, SSL is only about encryption and this "trust" scenario you believe in is horse poo poo. Nor is it valid in this scenario therefore the problem is the browser, not the cert.

Re:You are dumb

[Lanboy]

E-mail the cert to all valid users with instructions on how to put the cert into the cert db for firefox and ie.

Mozilla is right

[rlp]

People who know what they are doing can easily add an exception for a test or in-house cert. People who don't know what they are doing are less likely to be taken in by a phishing site using a self-signed cert. So, what's the problem?

it is stupid anyway

[unity100]

its basically letting go of half of the security for improving the other half.

lets see, what are proponents of this are saying ? they are arguing "ssl is not just about encryption, its also about knowing that you can trust the source"

well, thats basically an entirely stupid approach, when you consider that a LOT of websites who are now using self signed certificates will be just removing ssl encryption rather than pay yearly fees to a 'certified' vendor or annoy their users with the HORRIBLE 'youre being hacked !' style ssl warning in ff3.

what happens ? basically you will have let half of the security go while improving the other half. net gain ? zero.

utterly stupid.

Re:it is stupid anyway

[maxume]

End to end encryption to an unknown host doesn't increase security. It increases privacy (by limiting access to the communication to the connected parties), but it doesn't do anything to prevent hijacking.

Re:it is stupid anyway

[BZ]

> rather than pay yearly fees to a 'certified' vendor

There are CAs that offer up certs for free.

Re:it is stupid anyway

[unity100]

one word : browser recognition rates.

ok its more than one word.

Re:it is stupid anyway

[BZ]

We're specifically talking about Firefox in this whole article, so the only recognition that would matter is whether Firefox recognizes it. In other browsers you'll certainly be no worse off than a self-signed cert.

Re:it is stupid anyway

[unity100]

wrong. ff has a big market share now, even nearing 20-30%. if ff pushes something like it, you can be sure that it will become a standard for the other browsers too.

Re:it is stupid anyway

[BZ]

That's simply false as far as UI goes. Heck, IE had 90+% market share, yet other browsers didn't exactly blindly copy IE's UI decisions.

If your issue is that other UAs might tighten up their security without adding free CAs, that's a concern for sure, but there's nothing Firefox can do to bring it about or prevent it.

Re:it is stupid anyway

[unity100]

firefox is not ie. other browser developers do not hold the same antipathy they hold for ie, for ff.

Re:it is stupid anyway

[BZ]

That may be the case, but neither do they have any particular desire to copy Firefox UI.

Mozilla is correct

[Antibozo]

I think the author makes Mozilla's case for them, by not appearing to understand the risks, especially at a time when DNS cache poisoning has become unusually feasible. E.g., the statement

Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.

is simply not true for clients of unpatched DNS servers. It's much easier for an attacker to get a remote user's traffic redirected to a host of his choosing than it is for him to snoop on that user's traffic. Volume-based attacks on DNS become increasingly easier as bandwidth increases, and people who operate botnets have a good chance of poisoning a cache even on patched nameservers, simply through brute force. Meanwhile, that smaller class of attackers who are in a position to actually snoop on traffic are also in a position to use an arp spoofing attack. Encryption is simply not useful without knowing whom you're encrypting to.

If you're feeling lucky, you can always add the exception. You can also sign your certs with a CA cert, and import that into your certificate database. Of course, anyone who trusts that CA cert also trusts you not to generate bogus certs for bankofamerica.com, etc... The solution to the problem is not to make the browser more trusting by default; it's to migrate away from X.509 to a PKI that allows domain owners to generate certs at no additional cost, such as a DNSSEC-based PKI.

I think Mozilla has it 100% right.

Re:Mozilla is correct

[cmat]

In fact, even without the DNS poisoning issue, it's STILL easier to get users to got a specific web page and dump their personal information into it (as is shown by "Phishing" attacks). In fact, I would bet that it's very unlikely that an average attack would be carried out via a wire-sniff method, purely because that requires a targeted attack which will require active attack methods. This is simply just a pain in the ass, and more attackers would rather the data come to them, and so phishing web sites were invented.

Of course, the real solution is not to mix SSL (or TLS) with x.509 authentication such that they can be used separately. :)

Re:Mozilla is correct

[Anonymous Coward]

>> Snooping a connection ... is much easier than any of the impersonation attacks
> is simply not true for clients of unpatched DNS servers

That's not true. There are millions of botted PCs whose traffic can be easily snooped far, far more easily than poisoning a DNS cache.

Re:Mozilla is correct

[Antibozo]

There are millions of botted PCs...

Obviously, botted PCs are already compromised. All attacks are easy for those systems, including putting a keystroke logger on the system, subverting the browser, adding entries to a local hosts file (thus subverting the DNS), etc. You don't appear to understand the risks any better than the author of the article.

Re:Mozilla is correct

[Rapacious Nimron]

This is the winning post. It says it all, correctly, in a few short paragraphs. I'll be donating 50,000 Cronkites to a charity of your choosing.

Self signed certs

[cdrudge]

So add the issuing server to the list of authoritative CAs. Only do this if you have secure control of the machine but it gets rid of the whole need to add an exception.

The best post in this story

[Anonymous Coward]

So the argument is that encryption should be encouraged but that the current error message can only be avoided via 1) unencrypting traffic or 2) paying money to a trusted cert provider.

Encouraging encryption is good but unfortunately no one can come up with a good way of encouraging encryption whilst avoiding phishing sites (and other attacks). Infact stopping phishing is so bad that it was deemed more important than encryption.

So what's your proposed solution to distinguishing between these two things? Well there isn't one. The closest you get is to say that "Obviously it shouldn't show a green address bar [like a trusted cert]".

The usability problems of expressing a 'dangerous site' are many and until you come up with a way of clearly expressing the distinction between encrypted sites and phishing sites then you won't get far Nat. Firefox 3 made a the right choice for the majority of users who are non-technical.

Non-profit issuer the solution?

[SplatMan_DK]

Perhaps establishing a non-profit issuer is a possible solution?

Similar to the concept of OpenDNS it could be a free (as in freedom) and very cheap alternative to the large commercial certificate issuers?

If I wanted to undertake such a project myself, thereby contributing to the community, what would it involve? (I am ready to pull some cash out of my pockets, but I am no millionaire, just a tech-geek, so be realistic). And do you have the expertise to help establish such an "openCertificate" service?

- Jesper

Re:Non-profit issuer the solution?

[corychristison]

Take a look at CAcert. They are working to get included in the default FF install... most Linux distro's already package it in for you though.

Re:Non-profit issuer the solution?

[Urkki]

How would it work? Would it be just completely automated service, where anybody can send certificate details, and then receive a signed certificate in email? Surely you realize that this kind of certificate would be completely worthless...

So I presume there would be some kind of checks, so that just anybody couldn't ask for any certificate. Can you explaing what kind of checks and verifications there would be? What would be verified about a random certificate request? How would the signed certificate be delivered to the recipient?

Re:Non-profit issuer the solution?

[Anonymous Coward]

Perhaps establishing a non-profit issuer is a possible solution?

Only if you can place ads in certificates ;-)

No, it is not considered bad for the web.Blogrant.

[mxs]

I originally meant to post this as a comment to the blog post, but apparently the author does not care about testing their commenting feature. This alone should already tell you stories about how much thought he puts into this stuff.

-+-
Why in the world are you singling out Mozilla in this ? Every browser has this policy.

Every browser has avenues to add new root certs, too (I can just create my own CA, offer the certificate file on the web, and let users install that; all future communication with a site that has a certificate signed by that CA will not be bothered with these error messages). This may not be 100% convenient, you are correct. But it's not as if it was hard to do if you want to give your users the option of using encrypted sessions.

Oh, and there IS a way to get your shiny new non-profit CA into the main Firefox builds. All you need to do is comply with their procedures and requirements -- which include policies on how you verify the identity of the certificates you sign, how revocations work, etc., and requiring specific minimum requirements in these. If you think you can run a proper CA for free for everybody with proper identity checking and day-to-day operations, do it and get it added !

The default position Mozilla takes is quite simply that the CA should verify the identity of the entity the certificate is being issued to. You may not think that it is important for this to be such a prominent user interface feature, but many people do. Every user can add an exception for your site, you can add a CA of your own, you can get certified by a nonprofit CA (good luck finding one; I agree that most of them are scumbag operations that try to extract as much money from you as possible, but I have yet to see a proposal which both ensures identity checking and revocation management while being completely free ... Maybe you'll find a way).

This has nothing to do with network neutrality. Nothing at all. A more proper comparison would be comparing this situation with that of 2nd-level domain names. You can't get a .com domain for free, either. Nor a .net or .org or most of the country TLDs. You can open up your own Registrar (but will still have to pay dues for domains registered), just as you can open up your own CA. It'll be a rocky road, and it'll not be free -- least of all in work required.

My sites work just fine with SSL certs signed by my very own CA. Firefox displays them just fine (either by adding the root cert of my CA to it, or by simply adding an exception). All other browsers work fine, too. If you have visitors or customers that require validation of your certificate by a third party, you are SOL. But then again, you also would be were the warning worded differently (and there SHOULD be a warning for a certificate that is not signed by a trusted CA or one which you explicitly told the browser to trust. No matter what. Self-signed certs are alright for encryption, sure, but I want my browser to have a default setting of warning me when something is happening that very well could be an attack; especially when I have taken care to add a specific trusted CA (say, the one by my university).
-+-

Firefox 3 forgetting SSL certs

[Idimmu Xul]

We use a lot of self signed certificates for a lot of our internal, non customer facing sites, things like Nagios, Munin, etc. etc. most of our IT department are all running the latest Ubuntu Hardy with Firefox 3 and whilst Firefox's initial behaviour when it sees a new site using one of our certs is as described, it's not the end of the world as you just click through it and save the cert.

The real bitch is every few days everyone's Firefox instances are forgetting the cert, so we're having to go through the process every couple of days. I don't know if this is a bug, or new behaviour (aka a feature) but it's really annoying and driving me mad.

Re:Firefox 3 forgetting SSL certs

[Anonymous Coward]

Then you should run your own CA and import the root into all your Firefox installs. If you're using a lot of self-signed certificates, it's well worth the effort.

SSL with unsigned certs makes little security sens

[Anonymous Coward]

I've written an article criticizing the behavior in Firefox 3 [...]restricting encrypted HTTP to paying customers

Unfortunately, self-signed SSL certificates are vulnerable to man-in-the-middle attacks - for example, dodgy coffee shop WiFi, airpwn, DNS cache poisoning, corrupt ISP employees, ISP/government conspiracies, and so on.

Now, if it's just you and some friends using your server you can e.g. memorise the key fingerprint. But then, you can also add the self-signed key at whatever computer you happen to be using.

If you're facing a larger audience, however, self-signed certificates do not provide sufficient security as, though they protect against passive snooping, they do not protect against the very real risk of active (man-in-the-middle) snooping.

If you think Mozilla should have redesigned the SSL security model into a web of trust that's all very well, but frankly beyond Firefox's scope IMHO.

Why not use a startSSL cert then?

[Anonymous Coward]

For those sites, buying a certificate is possible, but the costs are high compared to the gains (as this is *only* about protection of the data, not about "being sure this is site XY). Based on the certificate IDs/hash it's possible in this environment for anyone to compare whether the certificate is a trustworthy one, or not. The certificate identification is, in this case, possible.

I don't understand this. You want to be sure that the data transfered is protected, but you're happy to have it redirected to any site.

As to the cost/benefit, how about a cert from startssl? This has the cost of $0 and the benefit of being supported by Firefox. It's not supported by IE unless the user installs a root cert by hand, but then it wasn't IE you were complaining about. Firefox actually seems to be ahead of IE in this regard.

Re:Why not use a startSSL cert then?

[Matthieu Araman]

I completely agree with you.
What Mozilla do is have a policy to include CA by default (ie being sure that there is a policy and they ask for a certificate assurance, revocation infrastructure and so on).
I don't think they make the CA pay something. This is why StartSSL can make certificates for free which work with Firefox.
So there's less and less excuses at this time to not declare Internet ssl site with real certificate.(one of the remaining pb is shared ssl site with only one ip but I think there's a protocol extension for this but which will take time to be deployed on real sites)
Self signed certificate are really a false security and it's a good thing to make it more difficult to access these sites as this will add pressure from users to make the admin configure their servers correctly...

HTTPS better than HTTP, always

[Frol]

In my opinion the main point the article makes is:
- HTTPS with a self signed certificate is in no way worse than HTTP.

With HTTPS you are protected against all attacks that simply snoops your traffic. You are not protected against a man-in-the-middle attack, but they are much harder to perform. Thus, I believe a HTTPS connection should be showed exactly as a normal HTTP.

Also, think of the new law in Sweden that will allow a government agency to SNOOP all traffic transitioning the Swedish borders. They are not allowed to alter your data, and thus cannot fake a man-in-the-middle-attack.

they provide encrytpion and that matters

[unity100]

EVERYthing on the web is susceptible to various attacks. yet, we are not mandating anyone to pay to some 3rd party source for a 'fix' in any of them. yet, it is the case of ff3 and the self signed certs. how come ?

so you people are basically arguing that because there can be man in the middle attacks, we should be forcing EVERYONE into the lap of verisign ?

how populist, how public minded, how democratic.

Re:they provide encrytpion and that matters

[Rakishi]

No one is forcing anyone since you don't need encryption to run a website. Likewise there are numerous CA authorities that you can use and I believe a free one is being added to mozilla (verification takes a while for such things). The point of https is to prevent snooping and man in the middle attacks. It's idiotic to use a scheme that doesn't prevent those instead of a scheme that does.

Re:they provide encrytpion and that matters

[Urkki]

I call "liar". I don't think FF3 forces anybody to use Verisign, and I don't think it's impossible to use self-signed certificates with FF3. Why are you claiming something that is not true?

Re:they provide encrytpion and that matters

[Anonymous Coward]

Mozilla doesn't mandate the use of any type of cert, they have simply made the process of adding an exception (the same as in previous versions) require a little more effort. This is because there was evidence that people ignored the previous warning page and were susceptible to phishing attacks.

Mozilla certainly doesn't force anyone towards Verisign! Check out the long list of supported CAs, these include CAs like startSSL.com who offer free certificates which work with firefox (though not with IE).

Accept self-signed certs and I hack you in no time

[rpp3po]

When do people finally realize that self signed certificates don't work? If I share your WLAN access in a public cafe it's really no big deal to play man in the middle and exchange the presented certificate for my own. Ok, it's more work than without, but not much (about 5 minutes). The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store. If your first check of a certificate's validity happens to be while I'm attacking you (maybe because you are visiting the site for the first time) you will "verify" my hacked one. And don't tell me about hashes on webpages. Maybe 1 in 1000000 users checks this once in a while for pure curiosity, but not more.

Am I missing something here?

[itsdapead]

TFA seems to imply that Firefox won't let you connect to a HTTPS server using a self-signed certificate. Not so.

Having just successfully connected to a self-signed HTTPS server using Firefox 3, I really can't see how it differs from (say) Safari or Internet Explorer.

All of these browsers pop up a warning dialogue that might scare off an uninformed user.

All of these browsers also allow you to connect anyway. Look at TFA, you can see the "add an exception" link in the screen shot from Firefox? Click that, and firefox will bug you no more.

So what is the argument? Is the Firefox dialogue box somehow scarier than the equivalent scary warnings in Safari and IE? Is it the little icon of the Customs guy making users worry that if they click on "add an excecption" they'll hear the snap of the rubber glove?

Agree w/Mozilla: crypt w/o authentication useless

[Anonymous Coward]

Hello,

without some assurance who you talk to (authentication), encryption is useless, since an attacker can insert themselves in the middle (called 'man-in-the-middle-attack -- MITM') as done by some chinese ISPs) without you noticing. Mozilla is 100% correct in their approach, some crypto-faschists would even go farther and not allow an exception through only 4 clicks.

Please learn some crypto before you complain about it.

Best regards,

os10000

no it does.

[unity100]

It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.

there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.

also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.

therefore many small service providers, businesses, communities that would not afford a decent certificate will be hurt in all respects, not to mention many users.

excuse me, but this is a very stupid, self righteous and jacobin move.

that is the EXACT kind of thing slashdot criticizes almost EVERY government, country, organization, corporation for, yet, you people are actually applauding it in this case.

Re:no it does.

[spottedkangaroo]

SSL isn't meant just for encrypting pages, it's meant for verifying identity also.

There are two solutions to this problem.

1. create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode). It's really not much trouble to set up your own CA.

2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.

Without the above, the ff3 presentation is correct, the certificate is bad and should not be trusted. Otherwise you're in real danger of man in the middle attacks.

Re:no it does.

[_bug_]

there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.

Find five. There's nothing disastrous in that message. The icon doesn't even have a red exclamation point. It states quite clearly what's gone wrong and offers the option to get past that. If a small business needs to self-sign their certs then a little education of their users prior to switching over to the SSL channel would quickly remove any reservations they might have about proceeding.

Furthermore, I want to know when I'm encountering a self-signed cert. A man-in-the-middle attack over SSL via self-signed certs is trivial. Spoofing the real, CA signed cert is a bit more difficult. So by notifying the user about the state of the SSL cert Firefox is doing good.

that is the EXACT kind of thing slashdot criticizes almost EVERY government, country, organization, corporation for, yet, you people are actually applauding it in this case.

Slashdot criticizes stupidity. Mozilla has not been stupid here. The problem is a lack of understanding why people SHOULD be notified about self-signed certs before they use them and the security implications thereof. Those who use self-signed certs that are angry at Mozilla should probably do a little research before they start throwing stones.

Re:no it does.

[Kludge]

SSL isn't meant just for encrypting pages,

But that is all many of us need or use it for, just the encryption. Just because we do not need the identity verification, should our users have to step through three separate extra clicks, where each of those clicks carries a more dire warning against doing so than the last, including one that says "Help! Get me out of here!".

Re:no it does.

[t0tAl_mElTd0wN]

I second this. I bought a signed certificate from them and indeed it was about that much. No fancy subdomain or multidomain features or anything or that, just enough to get browsers to shut up about self-signed certificates. And it makes the site feel ten times more professional. Really, it's worth the investment for a basic signed cert if you're trying to run any sort of non-personal website.

Re:no it does.

[norton_I]

SSL isn't meant just for encrypting pages, it's meant for verifying identity also.

As the article says. SSL does both. FF3 in particular makes the first completely unusable for no good reason. The web would unquestionably be more secure if all http servers switched to using self-signed SSL certificates in place of unencrypted connections.

2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.

The $10 certificates have essentially no value over a self-signed certificate. The only reason they even exist is that browsers make it so hard to use self-signed certificates.

Without the above, the ff3 presentation is correct, the certificate is bad and should not be trusted.

The correct behavior is to allow self-signed certificates with no warning at all, but not display the yellow bar/padlock that CA verified SSL certificates do. Then they should drop support for all signing authorities that have only an automated check for domain ownership, since they are of next to no value. Warnings should still be generated for expired certificates and probably those signed by unknown CAs.

Re:no it does.

[andymadigan]

The issue isn't quite identity verification, the issue is that without a trusted certificate another server masquerading as yours can connect to your server and retrieve the data the user is requesting without either party noticing. That's what a man-in-the-middle attack (is simple terms). There's simply no way to secure the link without that. There may be other ways to have a signed certificate system, and that is where you should be looking.

Re:no it does.

[dollargonzo]

What's the point of encryption if you can't protect against man in the middle attacks? It might as well be security by obscurity at this point... what exactly are you getting out of your encryption if you can't guarantee that no one is sniffing your packets?

Re:no it does.

[unity100]

Find five. There's nothing disastrous in that message. The icon doesn't even have a red exclamation point. It states quite clearly what's gone wrong and offers the option to get past that. If a small business needs to self-sign their certs then a little education of their users prior to switching over to the SSL channel would quickly remove any reservations they might have about proceeding.

that is to you. a registered slashdot user, who is probably working in an i.t. related field, or geeky enough.

i hate to break it to you pal, but we dont constitute the majority on the web. we are at best a noticeable minority. web is comprised of billions of internet users that cant tell firefox from ie, leave aside recognizing that 'there is nothing wrong' with that message.

to average web user, that warning would mean 'youre being screwed, run away from this website asap', REGARDLESS of what technicalities the contents of the warning says. they wont understand a zit about those technicalities anyway.

Re:no it does.

[PastaLover]

SSL isn't meant just for encrypting pages, it's meant for verifying identity also.

By all means, suggest to us a way to encrypt a website that doesn't involve SSL.

There are two solutions to this problem.

1. create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode). It's really not much trouble to set up your own CA.

Right, so you'd favor asking users left and right to add CA's from potentially very insecure sources (how well does the average website secure their root cert?). If this would actually catch on I'd predict the entire system to crumble in a few years.

2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.

Without the above, the ff3 presentation is correct, the certificate is bad and should not be trusted. Otherwise you're in real danger of man in the middle attacks.

I'd agree it's not that costly. However FF3 did go a little bit over the top on self-signed certificates. I need to use those from time to time and having to click through like 5 times before even getting to the site is a major hassle. Sure show a warning, show some visual cues, but there's something like too much of a good thing. If a user really can't tell the difference between a self-signed certificate after giving them a warning and using completely different icons/colours from other SSL-sites, perhaps that user needs his head examined.

Even if I make allowances for stupidity, I can't see how FF3 is now more secure. If someone is willing to ignore all those visual cues and warnings, they're probably equally willing to accept a scammer's word that their browser is buggy and they just need to click through five times "because of a configuration bug" or something like that. Phisher mail could start including detailed instructions on how to bypass firefox's warnings, I bet they will at some point.

Re:no it does.

[Anonymous Coward]

Couldn't find the $10 offer, can you show me the way?

Btw, just looking at the site make me want to ban them from being a valid CA.

Re:no it does.

[lukas84]

therefore many small service providers, businesses, communities that would not afford a decent certificate will be hurt in all respects, not to mention many users.

If your service provider, business or community can't afford 2000 / year for an EV SSL Certificate, you've got a lot of other problems to worry about.

Re:no it does.

[Anonymous Coward]

The problem is that people just want it to magically work somehow and don't care about the technicalities.

When somebody points out to them that distributed trust isn't a simple problem and they haven't thought through the implications of allowing anyone to easily claim to be anyone else they throw their dummies out the pram.

They'd be the first to complain about how ff3 is insecure when somebody duplicates their website and scams all their customers because it doesn't enforce the concept of authentication correctly.

Best ignore them because you can beat them with a clue stick all you like but they'll just never get it.

Re:no it does.

[shaitand]

From the article:

'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'

You are acting as if security is an all or nothing affair. There is no such thing as totally secure. Every step just raises the bar.

Also, there is an open CA that Mozilla doesn't include either. It performs the same domain verification that godaddy and others perform, checking that you have control of the DNS for the domain.

Re:no it does.

[unity100]

SMALL service provider.

in order to put ssl certificates to a small farm of servers or some number of vpsesyou are using, you need to buy a wildcard ssl. do you know the wildcard ssl prices ?

you dont.

Re:no it does.

[Anonymous Coward]

I agree with your view. It's unprofessional to ask a novice user to understand a warning he possible can't understand. That warnings requires from the user to know about certificates, encryption, authentication and of course security in general.

Instead of telling the user that it's good to have some sort of security, meaning having encryption, firefox tells him it's bad to have ANY kind of encryption.

Or do you need to add each http (read: non-ssl) site to your "allowed to be viewed" list of webpages? No you don't. So why make it harder to add security for the end user?

I wouldn't care if my self signed certificate would not be green inside the navigation bar, but making it red or making it harder to connect to a (half) secure site than to a secureless site is just wrong.

Re:no it does.

[Z00L00K]

Man in the middle still imposes a directed attack on you. In many cases SSL is sufficient to just obscure information like passwords used at public sites like Slashdot.

I someone does a man in the middle on that it means that they really are out to get me and my password, but in that case they have already invested enough to also cause other problems so the Slashdot password is a minor problem. The encryption will do fine to avoid it being snooped while transferred over WLAN.

But of course - I would be pissed if someone did get my Slashdot password and abused it.

Re:no it does.

[bickerdyke]

Warnings should still be generated for expired certificates and probably those signed by unknown CAs.

Thats exactly what SELF SIGNED certificates are. (signed by unknown CA, namely the certificate holder himself)

Re:no it does.

[iuyterw]

But that is all many of us need or use it for

NO ONE uses SSL strictly for encryption on the client side, which is what's being discussed here. Firefox is exhibiting a perfectly reasonable behavior for a client that is supposed to provide encryption and ID verification. This entire discussion is just noise from admins of sites that use self signed certs and are tired of getting "site is down" complaints from confused users. Yes it's annoying but it's plain that Firefox's behavior in this instance is correct.

Re:no it does.

[wasabii]

A 'decent certificate' costs less than $100. If you can't deal with that, your web site probably isn't worth using SSL.

Re:no it does.

[Kludge]

Is my ISP going to set up a man-in-the-middle-attack just to snoop what I'm downloading so it can provide targeted ads? I really doubt it. MITM attacks are much more sophisticated than the majority of snooping that happens on networks.

I am not saying that users should not be informed that a site is not "certified". I am saying that Firefox should not say that my site is "not legitimate" because I do have encryption, but no commercial certificate.

Re:no it does.

[brunascle]

By all means, suggest to us a way to encrypt a website that doesn't involve SSL.

If you're only worried about form values, e.g. passwords, and dont mind if it's javascript-only, you can use a javascript implementation of public key encryption. I used this RSA one on our site until we got SSL working.

Re:no it does.

[lukas84]

If you have a whole server farm, i doubt that the ~1000 / server / year matter much. Again, this for an EV certificate - used by Online Businesses and such.

Less validated certs can be had for much less.

Re:no it does.

[passthecrackpipe]

do you know the wildcard ssl prices

yeah - an unlimited server, unlimited domain wildcard cert is like $400 per year or something. EV's are like $500.
No big deal, really.

Re:no it does.

[Omnifarious]

SSL isn't meant just for encrypting pages, it's meant for verifying identity also.

We have another application in which this is also the case. It's called ssh. Why can't Firefox act more like ssh? ssh is perfectly secure and good at verifying identity without buying into the root CA scam. Why wouldn't Firefox be just as good?

I realize there are some differences in the intended audience's of the two applications and other details of how and when they're used. But still, ssh is pretty secure against MITM attacks without relying on some bogus and stupid 'trusted CA' concept.

Re:no it does.

[Anonymous Coward]

Cheap certificates exist, but I think that you are arguing that root-signed certificates are inconvenient--take too much time to set up.

The certificate model attempts to prevent MitM attacks by providing a chain of trust. Taking away the model of root-signed certificates makes it easier to produce hijacked sites.

When thinking about this, think of two things: this is analogous to SSH warning about new or changed keys, and whether it is better for a user to have more or less scrutiny on the Internet. It is great that users are no longer clicking "accept certificate" each time because, hopefully, it will reduce a type of snooping/phishing-hijack attempt and encourage those who are using SSL incorrectly to change. Why use a self-signed certificate if you can't trust its authenticity? As one poster stated, it's five minutes more useful than having no SSL. Without the trust model, the best way for clients to use self-signed certificates is to receive them physically and install them--for the group to have a CD at offices, or for the certificate to be installed in the default image.

The real problem is that the cheap CA's don't do much to establish trust.

Re:no it does.

[cptdondo]

WHat annoys about this is that FF doesn't support CACert, which is an 'Open' certificate outfit.
http://www.cacert.org/

I can buy a BS certificate from Godaddy.com for $10 and that's OK but a verified cert from CA Cert is no good. Go figure.

I run a small sideline business, and my whole yearly income would barely pay for a cert from someone like MS and the like. So I explain to my clients to click through the certificate BS. I'm after the in-route encryption; my clients know who they're connecting to.

Re:no it does.

[Hyppy]

Then go buy a cheap SSL certificate signed by a default CA. Or, start your own CA and contact the Mozilla Foundation to be added.

Re:no it does.

[nmx]

From the article:

'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'

You are acting as if security is an all or nothing affair. There is no such thing as totally secure. Every step just raises the bar.

The problem is, SSL *is* an all-or-nothing affair. If the certificate can't be trusted, you can't guarantee encryption either. Or have you never heard of a man-in-the-middle attack? Without a trusted certificate there is no way to complete the initial handshake in such a way that you can guarantee no one else is listening in. Firefox's "giant red stop sign" is exactly the right thing to do - otherwise, Aunt Tillie, whom we've trained to dutifully look for the SSL lock icon, will think that her connection is secure, when it isn't. I guarantee you she wouldn't pay attention to a tiny warning somewhere on the screen.

Re:no it does.

[Hyppy]

do you know the wildcard ssl prices ?
you dont.

Ours was $500 per year. It's not EV, but it works just fine.

If you can't afford that, then you're in a lot more trouble than whether or not the unwashed masses freak out when they see your page.

Re:no it does.

[unity100]

are you aware that www is not comprised of only western europeans, or americans ? are you aware that there are people with monthly wages of $100 around the world, who also happen to be running amateur communities through websites ?

Re:no it does.

[Talennor]

'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'

SSL does not provide wireless security. WPA and other wireless encryption schemes exist for that purpose. These don't include any false illusion of security that accepting a self signed SSL cert from a remote site would give (encryption != security, as posters above say). SSL is the wrong tool for the job here.

Re:no it does.

[unity100]

$10 a year still a huge cost for many people around the world. i dont know how some of you people can think that internet is comprised of u.s. and europe. there are people living on $100 wages a month and trying to do stuff on the net all around the world.

Re:no it does.

[unity100]

if you can lower your browser acceptance rate, you can go down to $1 a year certificates too.

tell me about geotrust. not even talking about verisign.

Re:no it does.

[unity100]

there are bigger things in regard to safety and security than MITM attacks :

http://slashdot.org/comments.pl?sid=634675&cid=24465677

Re:no it does.

[unity100]

and they will add my ca just like that. is that it. what is the point of doing such stampede, if they are to add countless cas that are going to apply, then ?

Re:no it does.

[Anonymous Coward]

I can buy a BS certificate from Godaddy.com for $10 and that's OK but a verified cert from CA Cert is no good. Go figure.

That's because CACert isn't trusted by Mozilla. CACert's verification procedures aren't trusted by Microsoft. Or me.

I run a small sideline business, and my whole yearly income would barely pay for a cert from someone like MS and the like.

You're not running a business, you've got a small hobby.

If your business can't afford a signed SSL certificate, should I trust you? If your business can't afford an address, a phone number, a business license, sales tax registration, filing cabinets or a desk, I wouldn't trust you very much.

It's part of the cost of doing business.

Re:no it does.

[bconway]

there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.

Then it's a good thing the page tells you what your options are and how to go about them, huh?

also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.

That's the idea. Any "secure" site that can be bothered with the hassle of running legitimately probably isn't worth/shouldn't be visited.

therefore many small service providers, businesses, communities that would not afford a decent certificate will be hurt in all respects, not to mention many users.

Certs are 10 bucks.

that is the EXACT kind of thing slashdot criticizes almost EVERY government, country, organization, corporation for, yet, you people are actually applauding it in this case.

Are you done yet?

Re:no it does.

[SanityInAnarchy]

there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.

GOOD. That means it's accomplished its goal much better than the popup, in which close to a billion people would have just played the game of "Which button do I click to let me into this site?"

also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.

Also good.

therefore many small service providers, businesses, communities that would not afford a decent certificate

That's bullshit -- a Godaddy certificate costs something like $10 or $20 per year. If you can't afford that, how'd you get the domain?

Now, I understand you don't like the affect -- a CA oligopoly controls the market. But if you have a better idea -- one which is actually more secure -- I'd love to hear it.

All I can think of is a web of trust, and if you can't understand the Firefox warning, what chance do you have of understanding a web of trust?

Re:no it does.

[Hyppy]

and they will add my ca just like that. is that it. what is the point of doing such stampede, if they are to add countless cas that are going to apply, then ?

I understand that perfect grammar, punctuation, and capitalization are not require to post on the Internet. Everyone makes mistakes. All I ask is that you at least put in a little effort.

With that said, no, the Mozilla CA approval process is not "just like that." See this page for more details.

Re:no it does.

[Anonymous Coward]

As soon as CACert improves its management system so it can pass Mozilla's auditing process, it can be included in Mozilla products. For now, you can use a free SSL certificate from StartSSL. You can also buy a cheap SSL certificate from RapidSSL Online that is recognized by all popular browsers.

Re:no it does.

[Anonymous Coward]

You never heard of SSH obviously.

Re:no it does.

[lukas84]

How can the $100 a month people afford a SERVER FARM?

It's like "Gas Prices are too high for poor people that drive a Mercedes SUV". Heck, it doesn't matter that they can't pay the gas prices because they can't even pay for the car.

Re:no it does.

[asnare]

SSL isn't meant just for encrypting pages, it's meant for verifying identity also.

As the article says. SSL does both. FF3 in particular makes the first completely unusable for no good reason. The web would unquestionably be more secure if all http servers switched to using self-signed SSL certificates in place of unencrypted connections.

And this is where you're wrong. There's no point to encryption, unless you know who you're talking to.

Anyone sophisticated enough to sniff your traffic can also hijack it without much trouble. If they can hijack it, then you don't know if you're talking to the intended recipient or a hijacker (who in turn is talking to the intended recipient). This is the definition of a man-in-the-middle (MITM) attack.

The very design of SSL and its use of certificates with a chain-of-trust assumes this. Without this assumption, Diffie-Hellman key-exchange is simpler and sufficient. None of the RSA/DSA stuff with certificates would be necessary.

Re:no it does.

[unity100]

That's the idea. Any "secure" site that can be bothered with the hassle of running legitimately probably isn't worth/shouldn't be visited.

thats your decision. the average web surfer has to decide it for themselves, not coerced into making that decision by arrogant self righteous programmers.

Certs are 10 bucks.

what you name as '10 bucks' constitutes 10 days' pay in many countries around the world. i hate to break it to you but the world is not comprised of us, japan and europe. you seem to be an arrogant g8 country citizen that is clueless about the rest of the world.

Are you done yet?

done with you, for sure.

Re:no it does.

[unity100]

if you are proposing godaddy, one of the few shittiest service provider on the web as a solution, pal, you can take godaddy and firefox3, and keep them to yourself.

Re:no it does.

[swilver]

2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.

Oh... is it that cheap to buy security these days? I never realized criminals couldn't afford it.

Re:no it does.

[unity100]

you are not aware of low end (which happen to be constituting a BIG majority of the websites on the net) hosting market do you ?

for, $100 a month people do not need to afford a server farm, they just wont be able to buy a cert for their amateur websites, scuttling whatever foray to the web they are doing.

for small businesses and small entrepreneurs, costs are equally prohibitive. you can rent a decent webserver and host 300 average websites on it for $200 a month, but if you, god forbid, try to remedy the horrible error ff3 is gonna show when they try to connect to their site control panels through ssl, you need to shell out major bucks for a wildcard ssl. same goes for a vps, shared accounts.

i was talking about this - the understanding and vision of the people who force that kind of decisions in regard to internet are so narrow that, they are not aware that how big an audience would be hurt and consequences would be, if they do such stuff. not to mention that some of those kind of people actually shun, belittle such small people, unfortunately.

Re:no it does.

[cptdondo]

Humph.... The last two businesses I sold went for more than many people make in a lifetime. I know a thing or two about running a business. This particular business grew out of a favor for a friend; it has since then attracted a few more customers. It's still in the infancy stage and in the 'personal hobby' stage - I'm not interested in 80 hour weeks on top of my regular job. But since the business is spread through word of mouth by existing customers, trust isn't an issue - people come to me, I don't advertise for them.

So it makes sense for me to have a self-signed certificate. It's just annoying to have to explain to a secretary to click through the 'Click here and you die' warnings spewed forth by FF3 and IE7.

Re:no it does.

[blacklint]

Let's say I have a small website with logins where I can't afford a cert, but want to add a layer of security, so I follow option 1. Now I have my root certificate installed in my users' browsers. If I'm malicious or even just incompetent and lose my private key, now all of my users are more vulnerable to man-in-the-middle and phishing attacks because I can sign anything I want.

Having users get used to installing new CA's seems to be the worst possible idea for security.

And let's face it, do you personally know and trust the maintainer of every site you have a login at? Would a website verified as belonging to my name be any more trustworthy than one I signed myself? Perhaps this isn't the best idea either, because of the aforementioned man-in-the-middle attacks, but the inclusion of a free CA like CAcert could solve all problems but identification. Even then the lowest level of GoDaddy certs is "Verifies domain control & secures your site," which is identical. (CAcert also has a Web of Trust that is probably better than the verification by GoDaddy for a Deluxe SSL, but I won't get into that.) So for verifying identity, as I said, who am I and why should you trust me anyways? Lots of small websites are run by individuals. Better to have a secure end to end link than no encryption at all, which is the way a lot of smaller websites will have to go. By making self-signed certs all but useless and not providing a free alternative, Mozilla is hurting the web. Oh, and I just checked, and the cheapest GoDaddy certificate is currently $29/yr, more than three times my domain registration.

Re:no it does.

[cptdondo]

Well, here's what IE7 has to say about StartSLL's own SSL cert:

  There is a problem with this website's security certificate.
  The security certificate presented by this website was not issued by a trusted certificate authority.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
    We recommend that you close this webpage and do not continue to this website.
    Click here to close this webpage.
    Continue to this website (not recommended).
          More information

Re:no it does.

[Lincolnshire Poacher]

Option 3: Send the certificate fingerprint to the customer via old-style letter mail. The customer checks the fingerprint when first visiting the website and if the cert matches he accepts the cert until its expiration date. The browser stays out of the loop; after all what does it know about digital identification?

If banks took authentication seriously like this then phishing attacks such as c1tibank.com simply wouldn't work. Instead, today, if c1tibank.com's cert is issued by Verisign et al. then the browser silently accepts the cert and the customer loses. Do you think that the Mozilla Foundation will accept liability as a result of such automated functionality in their software? Or the banks?!

Isn't there some way we could serve certs from the zone file using DNSSEC?

Re:no it does.

[nmx]

You never heard of SSH obviously.

Obviously you've never connected to a host for which you didn't have the public key cached. Any half-decent SSH client will warn about this and require explicit permission to connect, just like Firefox does with invalid SSL certificates.

Re:no it does.

[ftobin]

ssh has worked fine for many years without requiring centralized CA system. As long as the initial connection is secured, it is difficult to break later secured communication, even if someone can sniff or hijack the connection.

Re:no it does.

[Just Some Guy]

By all means, suggest to us a way to encrypt a website that doesn't involve SSL.

He never said that SSL wasn't meant for encrypting web pages, but that encryption isn't the only thing it's good for.

Re:no it does.

[Antibozo]

Isn't there some way we could serve certs from the zone file using DNSSEC?

There is a way we could have a superior PKI using DNSSEC, yes. (This should not be confused with the RFC describing a certificate record type for DNS; that simply provides an alternative way for publishing traditional X.509 certs.)

First, DNSSEC may be unworkable until the root is signed (which hopefully will occur later this year), and the important TLD registrars sign their TLDs and provide a way to publish signed DS records for subdomains. There are other strategies, but this would be the the most sound deployment of DNSSEC, from an architectural perspective.

When we have DNSSEC, then a modified version of SSL can be deployed in which domain owners publish public key(s) for each host in the domain. With DNSSEC, there is then a trust chain from the DNS root which validates the public key. There is no longer a general need for CAs in this scenario.

This is superior to the status quo for several reasons. First of all, the current method of acquiring a (non-EV) cert relies on insecure methods for verifying domain ownership, usually, by using clear text email to an address in the domain. This can be subverted by all of the same methods useful for attacking SSL and more, although it only happens once every year or two for each host. With DNSSEC, the analogous problem is getting your zone public key info signed (the DS record), but that only has to happen once every year or two for the entire domain. Once DNSSEC is set up for a domain, that domain can publish as many public keys as it likes, and doesn't have to pay for each one.

Another advantage of a DNSSEC PKI is that domain owners, unlike CAs, cannot sign public keys for hosts that are hierarchically unrelated. With the status quo, if you accept an enterprise CA cert, you implicitly trust that enterprise not to sign certs for other enterprises, because there is no domain constraint on CA certs.

Of course DNSSEC can be used for many other things as well, such as publishing SSH host keys, personal public keys, etc. With the latter ability, we can have mutual authentication and encryption, and effective public-key-based single sign-on.

Something like a CA is still useful in this scenario for doing what the EV certs do, namely asserting that a domain owner is the real enterprise you think it is. This is a completely different problem from distributing public keys, however, and only applies where there is a real enterprise you care about. For Bank of America, you want to know that bankofamerica.com actually represents that business. But for gmail.com, you don't care, because "gmail.com" is actually the identity of the business; we don't do other business with some company called "gmail".

Re:no it does.

[GalacticCmdr]

That's the idea. Any "secure" site that can be bothered with the hassle of running legitimately probably isn't worth/shouldn't be visited.

thats your decision. the average web surfer has to decide it for themselves, not coerced into making that decision by arrogant self righteous programmers.

That is exactly what FF3 has done. They have put control into the hands of the user instead of the programmer. This is neither arrogant or self-righteous - if they were going to be arrogant they would have not allowed any self-signed. Instead they push up a page stating exactly what is happening - giving the user the complete control to decide what to do next - even providing them a click right from that page.

This allows the average web surfer to decide for themselves.

Re:no it does.

[Myen]

1. create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode). It's really not much trouble to set up your own CA.

So, umm, transmitting the cert via encrypted HTTP is safer than trusting a self-signed cert, why? The attacker would just need to clobber that connection instead.

Re:no it does.

[tepples]

A man-in-the-middle attack over SSL via self-signed certs is trivial.

Screwing with a non-SSL connection is even easier. I'm guessing that operators of non-commercial web sites want to use self-signed certs so that their sites are not the low-hanging fruit.

Re:no it does.

[42forty-two42]

there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca. also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.

This is exactly why this is the correct behavior. Consider Joe Bloggs, visiting their online bank from a random WiFi point. Suddenly they get a cryptic popup, something about "SSL" and "self-signed". Whatever, they click ok and login. The next day a few thousand dollars leaves their account.

The self-signing warning needs to be scary, and not just a simple "ok", or ordinary users will click through on autopilot. Given how many people connect through cases where a MitM is possible (open WiFi, unpatched DNS), it's important to protect them from this possibility. If you have need to connect to a self-signed site, you can always whitelist it, as long as you understand the implications of doing so (ie, if you're on an untrusted connection - and 99% of the userbase has no idea how to evaluate that - don't do it).

Re:no it does.

[DavidTC]

THEN DON'T PUT UP THE LOCK ICON ON SELF-SIGNED CONNECTIONS.

Jesus Christ. Is almost everyone here totally stoned?

We want encryption, not authentication. Apparently, at least half the tech population is too goddamn stupid to understand how that could be possible.

Because, apparently, if a car doesn't come with a car alarm and lo-jack and onstar, car companies shouldn't be allowed to provide fucking locks on the door, because that provides 'a false sense of security'.

Re:no it does.

[DavidTC]

Sure show a warning, show some visual cues, but there's something like too much of a good thing. If a user really can't tell the difference between a self-signed certificate after giving them a warning and using completely different icons/colours from other SSL-sites, perhaps that user needs his head examined.

More to the point, if they can't tell the difference, they're probably not looking for SSL in the first place, which means all this yammering about MiM is incredibly fucking pointless. They'll get MiMed just fine, and it won't use SSL at all, at least not on their end.

All this talk about 'users falling for MiM' is pretexted on one, very stupid idea: That people who want to use unsigned certs think they should be presented identically to signed certs in browsers.

There is, rather obviously, no one who actually thinks that. Everyone agrees they should be presented differently.

Presenting them as less secure than an unencrypted site, with huge warning messages to click past, though, is just idiotic. There's no possible way they're less secure, which means, at worst, the site should just be presented as if it's unencrypted.

Re:no it does.

[Deanalator]

By all means, suggest to us a way to encrypt a website that doesn't involve SSL.

The level of encryption means absolutely nothing if you don't know who you are talking to.

Re:no it does.

[Anonymous Coward]

That's because StartSSL is not listed as a trusted certificate authority in Microsoft products. IE7 will give you exactly the same warning about self-signed certificates. Firefox, on the other hand, does list StartSSL as a trusted certificate authority, so will not present a warning.

It's time to start complaining about IE7, as there are no free certificates that IE7 trusts.

Re:no it does.

[Anonymous Coward]

If you're too cheap to buy a certificate for $100 from a respectable CA, or, you're too lazy to create a page that tells your potential customers to your cheapskate site how they are going to see a security exception and that they will need to add you as a trusted site (and, dread, perhaps personalized instructions based upon their user-agent string or something), then you don't deserve the traffic in the first place.

FF3 is doing exactly what it should be doing.
If you don't know what a self signed cert means you shouldn't be approving anything. If a site is too cheap to buy a real cert, they don't want your business very much.

SSL is designed to guarantee to the USER that the SERVER can be trusted - AND - protect the traffic in transit between the two endpoints. For those of you who do not understand this concept, imagine a man in blue pants and shirt coming to your house with no form of ID other than his own word that he is a policeman and needs to see your license, registration, and proof of insurance. Would you trust this man? Now if he had a verifiable government issued ID, gun, and badge, it may seem more trustworthy.

Re:no it does.

[Anonymous Coward]

I work in the IT field, and I recently setup a machine that is for secure communications with our roving users. At this moment, about 80% of them got lost when encountering the FF3 warning. Because of Mozilla it took a simple tutorial into a massive essay about how to use a simple web page while bypassing IE7/FF3 idiotic sirens. Use a warning, a yellow bar, or some such. Don't use a full page error. When your average user sees a full page thing like that, they assume it's an error. Sure they could simply read and figure it out, but that is often expecting too much of the user.

Re:no it does.

[Achromatic1978]

That's because CACert isn't trusted by Mozilla. CACert's verification procedures aren't trusted by Microsoft. Or me.

And that's what's wrong:

GoDaddy's procedures are "you typed in an arbitrary name and address, and the billing ZIP you entered matched the billing ZIP on the credit card you paid for when we billed you, so here you are.

Saying that "You can't afford this, should I trust you?" in situations like the above are solving the wrong problem.

Re:no it does.

[SanityInAnarchy]

If that's your argument, it's pretty pathetic. A quick Google for "Cheap SSL", and within the top ten results is another provider who's under $30/year. Found another at $25/year. A few others are at $60/year -- that's $5/mo.

Godaddy is still the cheapest. Honestly, are you suggesting that they're so bad that you can't deal with them once every year or two?

Re:no it does.

[SanityInAnarchy]

While I'm at it, found someone else for $14.95:

http://www.trustico.com/products/rapidssl/rapidssl.html

Re:no it does.

[undercanopy]

so you're saying that, for the average web user, we should have a smaller, easier to ignore, more innocuous warning? We should teach them to ignore warnings about sites being dodgy wrt identity/security?

Slashdot constantly talks down about the unwashed masses blindly clicking through warning messages and doing stupid things.... you're talking about ENCOURAGING this behavior. Why is that a good thing?

Re:no it does.

[Znork]

the issue is that without a trusted certificate

And with a trusted certificate anyone able to get a CA to sign a certificate can still do the same thing without either party noticing. Which still leaves us with no way to secure the link. The entities with the most capability to engage in MITM attacks, wiretapping, etc, ie, governments, ISP's, etc, are to a large extent capable of inserting themselves into, and corrupting, the verifications process leaving the 'trust' aspect protecting against, eh, exactly who? Phishers? They'll just pick the low-hanging fruit by registering (and getting signed certificates for!) c1t1b4nk.com and figure the idiots they're after wont notice the odd looking letters anyway (the key is there and it looks _trusted!_).

So with little actual extra security offered by ssl either with or without CA signed certificates there is little reason to differentiate between the two to such an extent.

There may be other ways to have a signed certificate system, and that is where you should be looking.

And other ways to initiate trust between two parties; ssh does it in a fairly good way, most often it's more relevant to know you're talking to the _same_ entity you were last time rather than knowing you're talking someone that someone else thinks is the one you should be talking to.

Re:no it does.

[undercanopy]

there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.

yes.. let's train those billion people to pay LESS attention to potentially valid security warnings so that you can save a few bucks on a cert

great plan... Do you Phish for a living?

Re:no it does.

[kisielk]

1. Does not verify your identity in any way whatsoever. Anyone could spoof your site, distribute their own CA root certificate, and use it to sign the SSL certificate their spoofed HTTPS server uses.

2. Is actually not much better. While in theory GoDaddy will verify your identity before issuing a certificate, in reality their process is not very rigorous and I don't doubt that someone could get a spoof certificate from them.

Personally, for anything important, I wouldn't trust a site that does either option.

Re:no it does.

[andymadigan]

The certificate does need to list *that* domain name, so a man-in-the-middle attack by an ISP would only work if they have a signed certificate for that domain name, not just any certificate. The ISP itself (hopefully) isn't a CA.

On the other hand, I'm sure the government could get verisign to make them whatever cert they wanted.

It would probably work better if there was a single, well-known, trusted entity running a database of the key(s) assigned to particular domain, rather than the key containing the domain. This one entity could then have a well known key that it used to sign all of its messages. Thus if anyone tampered with the valid keys for the domain it would be in public view.

The current system does leave it open to silent tampering.

I'm Not A Cryptography/Security Expert, can anyone poke holes in that idea?

It wouldn't have to be just one machine, multiple mirrors could be run, but there should be a high level of trust between the administrators of the mirrors.

Re:no it does.

[marcosdumay]

"There's nothing disastrous in that message. The icon doesn't even have a red exclamation point. It states quite clearly what's gone wrong and offers the option to get past that."

It is an error message diplayed where should be a web page, it has a very technical threatening tone (that stops being threatening once you know what it is about) that provides you with the choice of following just near the "get me out of here!" option and have no obvious comming back once you accept a self signed cert (and, as far as I know, no comming back at all).

Yeah, no problem with it. Things get worse once you acknowledge that plain http pages have the same security that self signed certs, but there is no warning for them. Why are they treated differently?

Re:no it does.

[spottedkangaroo]

more secure if all http servers switched to using self-signed SSL certificates in place of unencrypted connections.

It wouldn't. It would certainly be less subject to people listening in, but it would most definitely be less secure, since you would have no way to know if you were really talking to your bank, or the guy that took over the site using dns poisoning attacks.

Re:no it does.

[spottedkangaroo]

It wouldn't do them any good.

Try to buy a cert for bankofamerica.com, even from a crappy source. I don't think you'll be able to do so.

Re:no it does.

[PastaLover]

You're right I misread it. Apologies to the OP.

Re:no it does.

[norton_I]

Since my bank is not using plain http and would continue to use a signed and verified SSL certificate, that would not happen at all.

The connection to my bank would still be protected against impersonators, plus my communication with slashdot would be protected from passive eavesdropping. While that isn't worth a lot, it is worth something.

I also think it is a bit of a fantasy thinking that you can securely use the internet if your DNS has been taken over, but that is a different discussion.

Re:no it does.

[Lanboy]

I disagree strongly. Setting up a phishing web site with a self signed certificate is far easier than getting access at an ISP and spanning out traffic data to a capture device .

Re:no it does.

[Lanboy]

The certs should be part of dns registration, and cost less than $100. Down with CA.

Re:no it does.

[Anonymous Coward]

That's because it's only used by qualified nerds who act as a CA by collecting generated public keys as they install machines. Until you publish a good known_hosts file, ssh is completely worthless.

Re:no it does.

[Anonymous Coward]

'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'

That is just a dumb assumption.

Snooping some unencrypted connection and reconstructing something usable from that is a lot more tedious and boring than just pretending to be the ISP's dhcp or pppoe server, answering their broadcast packets, and redirecting unsuspecting clients through you.

It's easy to set up a man-in-the-middle attack, should it be just for the fun of it.

There's absolutely no value in 'simple encryption' without authentication. It's just making things a bit slower.

Re:no it does.

[unity100]

the indirect losses in this case will be more than the direct benefit. in such cases, one needs to do what is for greater good.

Re:no it does.

[Kalriath]

Presenting them as less secure than an unencrypted site, with huge warning messages to click past, though, is just idiotic. There's no possible way they're less secure, which means, at worst, the site should just be presented as if it's unencrypted.

Except that it is less secure than an unencrypted site. The reality is, if a user goes to a fraudulent copy of their bank's site, and it has an SSL certificate which is self signed, it SHOULD tell the user that the site may not be passing itself off as what it claims to be. Face it - SSL is used for both encryption AND authentication. Doing anything which involves removing one from the other reduces security for users which, let's face it, are generally morons.

Re:no it does.

[Kalriath]

you are not aware of low end (which happen to be constituting a BIG majority of the websites on the net) hosting market do you ?

for, $100 a month people do not need to afford a server farm, they just wont be able to buy a cert for their amateur websites, scuttling whatever foray to the web they are doing.

If you're paying less than that, you're probably on shared hosting which is incompatible with SSL anyway. No need for a cert, because you can't use it

for small businesses and small entrepreneurs, costs are equally prohibitive. you can rent a decent webserver and host 300 average websites on it for $200 a month, but if you, god forbid, try to remedy the horrible error ff3 is gonna show when they try to connect to their site control panels through ssl, you need to shell out major bucks for a wildcard ssl. same goes for a vps, shared accounts.

Uh, actually that situation is impossible too. Wildcard SSL certificates REQUIRE a domain name (so *.yourdomain.com) and if you're going to do that, just send everyone to panel.yourdomain.com instead.

Re:no it does.

[unity100]

no it doesnt. the warning is SO prohibitive that even for people who knows what it is it creates a sense of foreboding. for less technologically adept people it means a big red sign. NO choice.

Re:no it does.

[unity100]

This is exactly why this is the correct behavior. Consider Joe Bloggs, visiting their online bank from a random WiFi point. Suddenly they get a cryptic popup, something about "SSL" and "self-signed". Whatever, they click ok and login. The next day a few thousand dollars leaves their account.

that joe bloggs will be letting go of his personal information bit by bit in the (now) non ssl using websites in the form of name here, mother's maiden name there, secret question over there. because the websites that were using self signed certs wont be using them anymore, and eavesdropping more than one site in one shot is much easier than a man in the middle attack for a single person's bank account.

you can get a bank account frozen in an instant. you can get a credit card blocked with a call. but you cant get your personal details back, once it goes in the wild.

Re:no it does.

[unity100]

you should research browser recognition rates and 2nd year renewal charges for ssl certs before going wiseass on them.

if you dont think so, i have a certificate to sell you for $1 a year.

Re:no it does.

[unity100]

If you're paying less than that, you're probably on shared hosting which is incompatible with SSL anyway. No need for a cert, because you can't use it

it only requires assignment of a dedicated ip.

Uh, actually that situation is impossible too. Wildcard SSL certificates REQUIRE a domain name (so *.yourdomain.com) and if you're going to do that, just send everyone to panel.yourdomain.com instead.

not only not impossible, but also a reality for many small time businesses providing vpses and control panels to their customers. AND for it to work for even shared hosting accounts, the accounts need to be on the same server, or the same load balanced cluster.

Re:no it does.

[SanityInAnarchy]

you should research browser recognition rates and 2nd year renewal charges for ssl certs before going wiseass on them.

The one I mentioned lists all sorts of browsers, everything from the major ones to "Red Hat Linux Konqueror" -- and while I can't find any extra fees for renewals, I do see discounts for renewals.

Re:no it does.

[unity100]

then ff3 pushes all the web into the lap of rapidssl, which is 'the one you mentioned'. hardly any difference.

Re:no it does.

[42forty-two42]

This doesn't mean we shouldn't try protecting what we can. Just because there's other badness in the world doesn't mean we shouldn't try to stamp out the little patches of badness that are within our reach. After all, if personal information can leak that easily, why use https in the first place?

Re:no it does.

[unity100]

no, it means we shouldnt break other things while trying to protect them in one thing.

as said, sniffing unencrypted connections to get personal details bit by bit is much more easy and has less risk than trying to stage MITM attacks to get bank accounts.

with enough personal details, you can alleviate much of the security questions that you are gonna get asked while trying to get into someone's bank account. which means, you have a very high chance of getting that person's any future bank account. this is huge compared to losing one's access to a SINGLE bank account with a mitm.

Re:no it does.

[DavidTC]

Except that it is less secure than an unencrypted site. The reality is, if a user goes to a fraudulent copy of their bank's site, and it has an SSL certificate which is self signed, it SHOULD tell the user that the site may not be passing itself off as what it claims to be.

I don't know in what universe self-signed sites are less secure than unencrypted ones, or even how that's supposed to work. I can't even imagine how you can be less secure than unencrypted.

Re:no it does.

[Znork]

if they have a signed certificate for that domain name

Or if they can control the domain name. In which case they can obtain the certificate in question. And many more ISPs do DNS than do CA.

It would probably work better if there was a single, well-known, trusted entity

Or multiple such entities that keep redundant information so an attack would have to compromise several parties to achieve a fully trusted forgery.

The current system does leave it open to silent tampering.

Yep, and that's the main reason I don't consider it trustworthy; the ability for a third party to allow silent corruption of the channel encryption makes it worse than various two party or distributed systems.

Re:no it does.

[andymadigan]

The biggest advantage would be that a company could query the system for any valid certificates for their domain (so would anyone else) and detect when their records were compromised.

Re:no it does.

[Kalriath]

I'm impressed at your ability to read only half a sentence while quoting the whole sentence. There's my point attached to the ceiling over there, you might try getting it.

What's wrong with good security??

[traveler007]

I think the following is misleading:

restricting encrypted HTTP to paying customers

It doesn't restrict ssl's to paying customers, it simply warns if the cert is self-signed, but does give you the option of accepting it anyway. What's wrong with putting good security first, but letting the user over-ride.

I smell an ego-fuelled activist.

[julian67]

The entire article is based on a false premise (and some hysterical shrieking), which is that connection to self-certificated ssl encrypted websites is unavailable. It is simply not true and the author is apparently either woefully incompetent or is dishonest. I smell an ego-fuelled activist. I hadn't been aware of Firefox's behaviour so I tried the self certificated example offered. As mentioned by other posters it's 4 clicks to add an exception. What I really appreciate is that Firefox's dialogues explain the situation in layman's terms, i.e clearly and concisely, and let even an uninformed user make an informed decision. This seems to me to be ideal. It is certainly a much better approach than I've experienced with older versions of Firefox, or with Epiphany or IE6/IE7 where it always feels like a roll of the dice when trying to make a quick decision.

Trust no one

[luca]

You're right, it's extremely stupid to defer trust to a group of 3rd parties that have demonstrated in the past that they're not really good at verifying the identity they supposedly certify.
Firefox should just have no preconfigured ca and pop up the warning with every new ca it sees, asking "do you trust verisign/thawte/whatever? Here are some links about their track record."
Alas, users are stupid and they'll just click OK anyway.

Letting go of privacy, for more security

[unity100]

also do not forget that increasing privacy violation, deep packet inspections, surveillance and snooping is a MAJOR problem in every part of the world as of now.

ssl encryption provides the people with increased privacy, and makes it a tad harder for governments trying to peep on people.

yet, with this self righteous ssl cert move, firefox 3 is actually going to DETER the usage of self signed certs, and make it easier for governments or any interested party to snoop on many web users.

great move. very public minded.

Re:Letting go of privacy, for more security

[Frol]

Exactly, you lose nothing by using a self-signed certificate, but gain protection from deep packet inspection and other entities who shouldn't be reading your data anyway.

Re:Letting go of privacy, for more security

[unity100]

precisely so. and i think that is our biggest problem as of now, since many countries from turkey to and even sweden, leave aside usa, has started monitoring everything that passes their countries' networks.

Re:Letting go of privacy, for more security

[cmat]

Privacy is fine, until you ask yourself who you are talking to. If you cannot validate that, then privacy has close to zero value (other than for anonymity, which is even MORE important to know who you're talking to in this case; imagine a scenario where a dissident posts online to a server they think is controlled by another dissident yet their government is actually controlling the server).

Encryption != Privacy by default. It is private communications ONLY with some party. Privacy implies you know/can verify that other party.

Re:Letting go of privacy, for more security

[Nursie]

Err...

What's to stop folks that are using deep packet inspection from using a MITM proxy?

It would be pretty easy too, just grab a list of authorities from popular browsers, check SSL/TLS Server_Hello messages for certificates that are not from the known CAs (at which point it's likely they are self signed and unauthenticated) and then insert yourself in the middle.

if you've got the budget and the tech for DPI, you've probably got it for a MITM too.

Re:Letting go of privacy, for more security

[Frol]

There would be nothing stopping them from performing a MITM attack, no. But if everybody was using HTTPS it would be much more expensive and resource intensive to perform DPI on a large scale.

My point is simply you are no worse off using HTTPS than HTTP, so you should not have to go through all the warnings that will scare a lot of people away.

Overkill...

[david.emery]

A warning to the effect that the site's identity could not be verified is what should be done here. And it should take -1- click to proceed (if you so choose, and with an option to permanently add this certificate to a list of accepted certificates.)

One can argue with the SSL approach that handles both encryption and identity with a single solution, but it is legitimate to use self-signed certificates when all you care about is encryption.

The same behavior should apply to email user agents.

Side issue: Whatever happened to the idea of an 'open source' certificate user? It bothers me that there is a list of closed (and not cheap) certificate authorities.

dave

Exceptions and Options

[Proudrooster]

I haven't tried Firefox v3 or even read the criticism, but isn't this an option that can be enabled or disabled under options/exceptions? I doubt that this would get put in there without the option to turn it off. The reason I 'assume' this is because MANY companies accidentally let their security CERTS expire. If someone forgot to renew their CERT, like GMAIL did last month and there was no way to create an exception, imagine the interruption. It took me awhile to figure out what had happened after I upgraded Firefox last time and couldn't get to gmail.

Number of holes in the author's argument

[bconway]

A.) You don't need to buy certs from Mozilla, you can buy them from any number of CA's, for as little as $10. There are some free CA's, as well.
B.) This isn't in any way related to network neutrality.

Re:Number of holes in the author's argument

[noidentity]

These days people don't care about watering down words. Witness cries of censorship whenever anyone imposes conditions one doesn't like, claims of a bricked device when it's really just a software issue, and now claims of net-non-neutrality when a bad choice is made regarding internet protocols (never mind the lack of profit motive). I find this kind of behavior disgusting, since it destorys the most important tools we have to describe situations where these serious matters are actually occurring.

Re:Number of holes in the author's argument

[xant]

Point me to these free CA's that have root certificates that are actually installed in browsers.

The only one I know of is CACert.org, which isn't a root certificate in browsers by default.

Re:Number of holes in the author's argument

[johny42]

I double the parent's request. Please point me to a free CA with certificate installed by default in the major browsers, or point me to the $10 one at least. All that I know of cost hundrends of dollars for a single year certificate.

Re:Number of holes in the author's argument

[Antibozo]

I don't know of a $10 offering; if there's one from godaddy.com, I would pass, given my past experience with that company. But dynadot.com offers RapidSSL non-chained certs for $19.99 per year.

I like the interface

[nedlohs]

I set up SSL sites as my day job...

I test the setup before the DNS has pushed out using the IP address. Hence I get that message all the time (due to the cert not matching the domain). It's four clicks to getting to the page (and each step gives useful information the first time round) - sure one click would be nicer but it's not something you want to do with a single mistaken click.

I'm perfectly fine with this behavior...

[GuyverDH]

I'd rather see this than something that doesn't stand out, or nothing at all when accessing a site that's self signed.

Yes it can be a nuisance if you visit a lot of sites that are self-signed, however, if you're browsing habits are more corporate style, then it's good to know you're going to be warned if something's not quite kosher.

The author has a point

[Nycran]

Look it's very simple. We'd like to be able to do two things: A) Encrypt data in transit between the web server and the browser. B) Authenticate the owner of the web site. These two things SHOULD NOT be inextricably linked. We should be able to do one without the other. If we had two icons on Firefox, one that indicates encryption in use, another that indicates trust, then that's all we need and everyone is happy. I agree with the author that it's completely ridiculous that we view an encrypted but not authenticated web site as more of a security problem than straight HTTP - that is nonsensical. Let encryption be free for anyone to use on a web site, with or without certificate!

Firefox has some interesting SSL problems as well

[giminy]

I noted a far more subtle problem with SSL in Firefox about a year ago that deals with Client certificates. They allow users to use a non-repudiation certificate for authentication, which is a subtle but bad thing. It ends up giving the US DoD a free pass while messing with the security of everybody else that uses client certificates.

One good thing has come out of it: when I was interviewing for jobs, I brought this issue up with all of my potential companies. It was a great conversation-piece to hear what different companies would do in the Firefox Position: bow to the wishes of the DoD, screw the DoD in the name of the specifications, or something else entirely...

Reid

The reason this discussion keeps coming up...

[Anonymous Coward]

Is because people are too stupid to do any research.

If the article author had bothered to do even the slightest bit of it they would have discovered that there are already trusted CA in Firefox.

Startcom (http://cert.startcom.org) is in Firefox 2, Firefox 3 and Mac OS X 10.5/Safari 3. StartSSL (http://www.startssl.com) is in Firefox 3 and working on getting into Safari.

Startcom/StartSSL got into Firefox by following their approval policies. It is perfectly possible for any other provider to do the same, they merely have to bother to comply.

the new appr

[mstamat]

I totally agree with the author of the article. He doesn't suggest that there should be no verification of the SSL certificates. He just says that the warning message is an overkill because it scares people from using SSL in encryption-only mode. It's kind of a G.W. Bush approach ("You are either with, or against us.") that I wouldn't expect from Mozilla foundation.

IMHO, the new approach of Mozilla to SSL cert handling is flawed because:

1. The displayed message has the look of an error message, while in fact it is a warning message. You have to read the fine-print in order to understand that.

2. The message gives erroneous suggestion for the source of the (perceived) problem. In 99% of the cases, neither of the following is true:

• This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.
• If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.

3. If the Mozilla guys really think that there is something bad going on, why do they have checked by default the "Permanently store this exception" checkbox?

Finally, running running a CA is not an option for many companies. There is a quite heavy administrative overhead (compared to the received benefits) for doing so. Also, what happens with business partners of the company who don't want to trust all of the sites certified by their CA?

I am sorry to say, but this new warning screen is a bad copycat from IE7. I would bet that there is a thread somewhere in /. where the /.-ers moan about the new warning screen of IE7. ;-)

Link to BugZilla discussion

[ThePhilips]

For lazy souls link to BugZilla bug 433422

Brief of discussion:

SecurityNazis: Self-signed SSL is untrusted!!!!
Admins and Users: Untrusted != invalid!!!
SecurityNazis: But self-signed SSL is really really untrusted!!!!
Admins and Users: Untrusted != invalid!!! We do not care!!!!
SecurityNazis: But we care!!!! Though we do not browse WWW - because it is untrusted.

and so on. Not really informative on its own. Essentially, people who do only one thing with Web - exploit trivial bugs and claim credit for doing so, so called "security researchers" - against simple users who do only surf web - intranet and internet - argue with each other, constantly failing to find common ground. Because they, well, do not have one.

same argument everytime

[unity100]

letting go HALF of privacy and security, just to ensure that the other half, the verifying identity part is stronger ?

what kind of logic is this ?

1. create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode). It's really not much trouble to set up your own CA.

first, you are not in communication with potential customers, and they will never communicate with you and become a customer after they see that horrible ff3 warning. you wont even get a chance to tell them what is going on.

second, same goes for many potential website users that are signing up for a community.

additionally godaddy is one of the shittiest service providers on the web. so if the solution you are offering is godaddy, please, keep it to yourself, and even firefox3 too.

Re:Accept self-signed certs and I hack you in no t

[Anonymous Coward]

Except that at work, we're part of the International European Grid network. We use self signed certs for everything, and if anything, our self signed certs are more secure than anything any top level CA will ever generate. ie : We enforce air-gap policies around the server that generates/signs the certificates, and a member of the grid was kicked out a couple of years ago for violating those policies.

Think any of your top level CA's do that?

We've had to start using the occasional top level CA on our more public sites due to Firefox doing this, but I'll take our self signed certs over a top level any day.

I'm going to take this opportunity

[grizdog]

to ask slashdotters for advice in improving the draft of an explanation of cryptography and certificates that I have begun. You can find it at my website

I submit that this is not off-topic, since one point several people have made is that most people don't understand certificates well enough to be able to deal with the warning that ff3 gives, so if we could get some explanations out there, it might help the situation.

To settle one issue...

[rickb928]

Self-signed certificates are both valid and common with internal Web apps.

We use several where I work, and there is even an internal CA that mints certs for several apps.

And Firefox works fine with these internal apps. I know where I'm going, my antivirus and such are still working, and I trust my internal developers. After all, if they screw my machine up, I'm off the hook. It's an approved app, sir. See, I don't even need an exception.

So there is this one good reason to permit self-signed certificates without undue hassle.

Sheesh. Firefox being stupid? What's next, Google exploiting our data for... wait, nevermind.

You can get free certificate

[landre3567]

http://www.startcom.org/ provides free ssl certificates that are supported by firefox That's a free way to remove the scary dialog...

You missed a couple of very important points.

[danaris]

First, I think that the most important line in the article is this one:

But there is absolutely no excuse for it to be significanly less inviting to a normal user than an unencrypted site.

The FF3 behaviour will make most normal users just think, "Oh, the website is broken. I guess I can't go there." They won't even read the error message: they'll just see that there is one, and give up.

Or, depending on IE's behaviour (which I do not know in this particular case), they'll see, "Oh, I can't get to this website in Firefox. But hey, it works fine in Internet Explorer! I guess Firefox is broken, and I won't use it anymore."

Second, and probably more importantly, either you missed a very, very important demographic among those who use self-signed certificates, or otherwise don't want to pay the extortionate fees charged by the corporate CAs, or you severely misunderstand and underestimate the importance of "unprofessional" and "hobbyist" webmasters.

Just because I want to have the possibility of encrypted traffic for visitors to my website doesn't mean that I'm bringing in loads of money by said website, or that I want to spend some not insignificant sum on a recurring basis for what is, for me, just a fun hobby, for which I'm already shelling out a not insignificant sum for hosting.

I'm seriously hoping that your definition of "unprofessional webhosters" means "people running for-profit websites (that actually make a profit) who are just too cheap to actually buy a certificate," and not simply "amateurs," because it is on the backs of those amateurs that the web was built.

Dan Aris

Re:You missed a couple of very important points.

[lukas84]

The FF3 behaviour will make most normal users just think, "Oh, the website is broken. I guess I can't go there." They won't even read the error message: they'll just see that there is one, and give up.

That's good. I'm fine with that. "Secure by default".

Or, depending on IE's behaviour (which I do not know in this particular case), they'll see, "Oh, I can't get to this website in Firefox.

http://projectdream.org/~lb/ie7-unknownca.jpg

IE7's error message and behaviour are slightly different - first, accessing the site anyway is a single click. However, that click will be necessary each time you try to access the site. When you want to make the trust permanent, much more convoluted steps are necessary (around 10 clicks through a variety of property dialog boxes, and even more complicated on Vista).

Just because I want to have the possibility of encrypted traffic for visitors to my website

Encrypted traffic doesn't mean much when everyone can go inbetween you and them. MITM attacks against self signed certificates are easy to do.

Most hobbyists websites do not require SSL - if you host a discussion group or anything similar to that, SSL is not required. MITM attacks are still easy, so you haven't lost or gained anything.

Or perhaps you can enlighten me with a use case for a hobbyist website that requires SSL.

Re:You missed a couple of very important points.

[iuyterw]

I think his definition of unprofessional webhosters probably means those who don't understand what the "extortionate fees charged by the corporate CAs" buys you and why Firefox is doing the right thing here, regardless of the inconvenience to small sites trying to save a buck.

Re:You missed a couple of very important points.

[Anonymous Coward]

Or, depending on IE's behaviour (which I do not know in this particular case), they'll see, "Oh, I can't get to this website in Firefox. But hey, it works fine in Internet Explorer! I guess Firefox is broken, and I won't use it anymore."

IE7 displays a large, red X when you try to access a site with a self-signed certificate. It doesn't "work fine" in Internet Explorer. In fact, Firefox makes it easy to add the self-signed certificate as an exception so the next time to access the site it takes you straight to the site.

Re:You missed a couple of very important points.

[Selanit]

Or perhaps you can enlighten me with a use case for a hobbyist website that requires SSL.

Hi! I have a domain which I acquired solely for the purpose of supplying myself and my family with webmail. I didn't want to have to put up with crappy advertisements, even the politely unintrusive ones in Gmail.

I'd really like to encrypt the log-in sessions for my webmail client. I understand that the email itself is not going to be encrypted once it's sent out. But as it stands, my EMAIL PASSWORD is being transmitted in clear text every time I log in. That sucks. Anyone on any server between me and my web host can get my email password, and they don't even have to go to the trouble of setting up a Man in the Middle attack, because it's completely 100% insecure.

In order to rectify this, I would need to:

1. Pay $2.50 extra per month for a unique IP address ($30 per year)
2. Pay $45 per year for an SSL certificate signed by RapidSSL, the hosting company's preferred SSL CA. They don't accept certificates from anyone else, and I can't install one manually, because I don't have shell access. It's a shared hosting account, which is all I can afford.
3. Install my own webmail client, because I can't install a certificate for the one they provide, which runs on a different server. Self-installed software is not supported, so I would essentially be giving up the technical support I've paid for.

All that just to secure my email password? Screw that. I'll keep doing it insecurely and hope to hell nobody hijacks my email to send out spam.

Re:You missed a couple of very important points.

[Anonymous Coward]

Just configure your own certificate as trusted. Problem solved.

"All that just to secure my email password? Screw that. I'll keep doing it insecurely and hope to hell nobody hijacks my email to send out spam."

Wow. congrats on joining the millions of other idiots all for the want of approximately 10 seconds configuration. I hope your are proud.

Re:You missed a couple of very important points.

[danaris]

OK, thanks for demonstrating IE's behaviour. That does negate one of my points.

It still bugs me.

Dan Aris

Adding CAs

[Anonymous Coward]

I would agree that the solution is not just allowing self signed certs to be viewed without warning. However, there needs to be a way for new / not-for-profit CAs to be added to Firefox, and right now there isn't. Yes I know they have an official policy for adding CAs. There is only 1 CA that tried to be included that I know of, CACert, they app'ed in 2003, and as of July 2008 a decision still isn't made. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=215243

Yet if you look at your own CA list in the Options menu, you can see things like the Taiwan Government CA, the GTE Corp CA, Swisscom Telecommunications CA, the GoDaddy Group, and others which I'm sure all of us would trust a whole lot less than something like what CAcert is trying to build.

Just my $0.2

T-Shirt

[oglueck]

You buy a purple T-Shirt and 6 months later purple is out of fashion. Clearly the manufacturer's fault, right?

Yes, SSL Certificates from a CA *are* expensive. Yes, you can encrypt with a self-signed cert. But that encryption is worth nothing at all. Because anyone (latest DNS vulnerabilities for instance) can easily forge these certificates, you don't know who you are communicating with in the first place. Of what use is point-to-point encryption if the man in the middle is undetectable?

Yes, it 4 clicks to define an exception rule are a pain in the ass. But because it's that painful it will cause people (like the author) to think twice before they use a self-signed cert next time. So making the web safer in the end. Don't make it too painful (will hurt adoption of product), but painful enough so that decision makers get worried. I think FF3 behaves perfectly in that respect.

Re:T-Shirt

[Software]

Because anyone (latest DNS vulnerabilities for instance) can easily forge these certificates.

I agree with much of your post, but the above statement is incorrect. A self-signed certificate can be created by anyone, but they can't be forged. That is, the (self-created) certificate authority you use to sign the certificates won't be trusted by all browsers. Scenario:

1. You create a site and secure with a certificate signed by a certificate authority that you created (aka a self-signed certificate).
2. You have a non-secure page that instructs users to add a security exception for your certificate authority.
3. Users connect to your site, add the security exception for your certificate authority, and use your site. So far, so good.
4. Someone hijacks your DNS and users get redirected to their web site.
5. Users who previously added an exception for your certificate authority get a warning message that the certificate authority is unknown.

So DNS vulnerabilities create no problem for your old users. The bad news is that new users and new browsers (who did not add your certificate authority to their browsers before the DNS attack) will be vulnerable to the attacker. The only defense to this is that the attacker's certificate authority will have a different MD5 fingerprint. In order to combat this attack, you should make sure that everyone knows the MD5 fingerprint for your certificate authority. You have to push this out not just via your web site, but in all your emails and other communication paths.

The other major downside of self-created certificate authorities is that the users have to really trust you. If someone acquired the private key for your CA (or if you turned evil) and decided to hijack DNS and create a certificate for citibank.com, signed by your certificate authority, those users who added a security exception for your CA would be fooled into thinking it was the real citibank.com.

So, as much as I hate Verisign, getting a certificate signed by one of the big CAs is worth the money. It's a lot cheaper than dealing with users frustrated by having to create a security exception.

Re:T-Shirt

[oglueck]

You are mixing up two different things:
- self-signed cert: there is no CA. The public key is just signed with the private key.
- private CA: there is a CA, but the CA cert is not part of the browser's repository.

Yes, DNS vulns do pose a great risk here. Because the man in the middle can easily create (forge) any new self-signed cert for the destination site from an arbitrary privat key. Only if the user verifies the finger print of the key, can he detect the forgery. I have never seen anyone publishing the finger prints of their SSL self-signed certificates. Acutally, CAs were designed to eliminate the need for finger print verification.

For another "nice" example see this post. With a self-signed certificate the user would be completely unable to detect what's going on.

Re:T-Shirt

[oglueck]

Actually, at work we are using a private CA (not self-signed certs) which all communicating parties trust. Also the certificates from this private CA can be issued with longer life-times, which eliminates the renewal pain. That's possible because the secured services are not available to the general public, but just a number of well-known clients. So we can distribute the private CA cert among the clients easily. And save a lot of money and maintenance overhead (cert renewal).

Looks somewhat close

[SplatMan_DK]

Are there any other similar?

- Jesper

Re:Looks somewhat close

[corychristison]

Not that I know of... no.

Without full inclusion in the major browsers though it can scare off customers if you have an online store of sorts... so buying a cert is probably your best bet in the first place.

For closed/controlled use (eg: offices intranet) either self signed or CAcert if you don't know how would be fine.

Wrong conclusion...

[fluch]

"Instead, it shows a [...] warning that requires 4 clicks and an 'add an exception' dialog box to bypass. This behavior means that a public web site basically can't be encrypted unless they are willing to pay an approved vendor a yearly fee for a certificate."

I don't see how the second sentence follows from the first one. If you want security you need to make sure people don't click blindly accept-accept-accept!

Nope, the mozilla policy is correct

[Time_Warped]

When you go to the store to buy beer. You must present an expensive piece of ID to show you are of age, just saying you are an adult will not get you beer. This is not really any different, except the state government not the CA's grants the certificate. Now if you are calling for the CA's to be replaced be a government agency because it might be cheaper, then maybe you are right. But self signed certificates are inherently insecure and should never be accepted. Just like no sane store clerk would sell a 10 year old beer because he shlocked together a homemade ID saying he was 21, so sane user would accept a self signed certificate. END of discussion.

you dont get it

[unity100]

you NEED encryption to provide better security (through encryption), and most importantly, PRIVACY, to your community users, clients, vpn users, whatnot.

especially in an age that almost every government has started snooping and eavesdropping internet connections.

Re:you dont get it

[Rakishi]

If your concern is government snooping then you're hopelessly delusional. That said encryption alone will not guarantee that the data cannot be snooped which was my whole bloody point. Either learn to read or stop wasting people's time.

Sounds like FUD to me...

[jgustie]

If you are to lazy to use the system like it is supposed to be used then you only weaken it. Self signed certs should really only be used for testing. If you don't want to pay one trillion dollars for a certificate, create your own authority and get your users to trust you: Tools > Options... > Advanced > View Certificates > Authorities > Import...

just nice

[crodrigu1]

So what we want a certificate in the first place? Yes you the nerd on the third row! because we want security and how security can be implemented when you need to accept a self signed certificate from bad boys inc boys just chip some money (I know less beers) and buy a certificate And do not blame mozilla because they ARE RIGHT and you are SOOOOOOO WRONG

the warning matters

[unity100]

ff2 warning was just a commonplace warning. not 'YOURE GETTING HACKED !!' style overly alarming one like the ff3.

mod parent up

[user24]

exactly.

It is totally ridiculous that FF makes it easier for users to type in their credit card number on http than self-signed https.

Users conditioned to click to accept everything:

[the_other_chewey]

From http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf :

SSL certificates provide honesty-box security

• Use a $495 Verisign certificate
  - People will come to your site
• Use a $9.95 budget CA certificate
  - People will come to your site
• Use a $0 self-signed certificate
  - People will come to your site
• Use an expired or invalid certificate
  - People will come to your site
• Use no certificate at all, just a disclaimer saying that you're secure
  - People will come to your site

The whole PDF is a highly recommended read full of sad truths.
Unfortunately, it is VERY hard to recondition users. I don't blame Mozilla for
trying (in fact I completely agree with the change), but it will probably fail.

As much as I think this is retarded...

[Talez]

If you really need to use self-signed certs is there anything stopping you from including your own CA cert in a company customized version of Firefox that gets rolled out?

I'm kind of annoyed because I work for a web host and now people who use any sort of domain mirroring are going to be completely fucked rather than having a semi-dodgy box come up when their CN doesn't match the web address.

Maybe the real answer is something else....

[johnlcallaway]

The author assumes that this is a problem that needs addressing by doing what?? Making it easier to accept self-signed certs?

As usual, the he can't see a tree because of the forest. SSL is used for two purposes, encryption and authentication. Self-signed certs, as noted above, fail the authentication test.

So the real problem then is that sites that just want to use encryption have to purchase a cert, or get what is claimed to be an obscure warning.

The issue isn't about SSL, it's about the encryption.

My first thought is that it's so much BS. The odds of someone actually listening in on your HTTP transmission is extremely small, unless you are using a wireless transmission that is not secured. To tap an IP stream would require physical access, and unless someone is an employee at a provider is highly unlikely.

But .. there still is a very slight risk.

So .. why doesn't some numb-chuck come up with a new HTTPX method that just does encryption??? Duh!!!! SSL model without the certificate. Coordinate it so that Apache and Firefox have it available at the same time. Sure, IE won't have it but it has to start somewhere.

So,

[Vexorian]

Is this whole thing about admins thinking that self signing a certificate is actually worth something? If you can't afford this CA stuff just don't have encrypted giberish, ok?

I mean, really. What's the point of a self-signed certificate? Name a real life scenario in which signing your own certificates makes any sense? Why should a web browser trust those sites more than a normal person would trust a guy who has signed his certificates? Because this blog writer and own blog linker has managd to somehow connect it to net neutrality?

its not about guarantees

[unity100]

nothing in the world on, or off the net is guaranteed.

its all about making it HARDER to be put in the place of a victim.

and its not only about government either. one rather eavesdrop a website's connection and get the personal details of thousands of users, than try to hijack 1-2 self signed ssl connections. personal data would fetch much more higher price on the black market.

no. im not delusional. you are careless and uninformed.

addon to allow fast-add-exception of self signed

[pinky99]

here it is: you need to register though...

Anonymous Coward

[Anonymous Coward]

Who runs a business will buy a 10$ cert.

Directly contacting all your users or customers by phone or mail will cost more than 10$.

Not doing one of the above leaves users in danger and not having a clear and understandable-to-the-final-user statement from the browser gives a false sense of security.

it's not "die net neutrality, die" but "go final user security!"

The problem is...

[Spazmania]

Here's the problem with this gentleman's analysis:

1. Without a third-party signed certificate, you're vulnerable to a man-in-the-middle attack.

2. If you accept the connection without a warning (it's no worse than plain http, right?) the user won't notice when a normally signed site (like his bank) suddenly presents an unsigned certificate.

Then again, the user probably won't notice if a normally-encrypted site like his bank suddenly starts using plain http instead of https.

There is probably a middle ground, like creating another URL type (in addition to http and https) which encrypts but doesn't check certificates.

Re:addon to allow fast-add-exception of self signe

[pinky99]

and here is the link... https://addons.mozilla.org/en-US/firefox/addon/6843

It depends who is verifying who.

[Kupfernigk]

I will use a self-signed certificate where the USER needs to authenticate themselves to ME before I will release certain data to them. My box has a valid domain which matches the certificate. The user needs to send me certain data, encrypted, before I will peform certain operations on it, come up with a result, and then present the result to the user. Based on this, the user will make a decision on whether to contact a third party. I'm not going into the application in depth, but you may guess it is to assist a user in a buying decision based on user-selected criteria. It is a paid for application because the decision engine is guaranteed vendor neutral; we have no advertising, no vendor links.

I think it is quite reasonable for Firefox to say something like "the certificate is valid for the domain, but it is not warranted genuine by a third party. If you believe you are accessing a site which is not connected with banking, finance, gambling or on-line purchasing, this is unlikely to be a security risk".

Alternatively, FF3 needs a simple way to import a certificate from a trusted supplier, so I can supply one as part of the new account welcome package.

Re:Accept self-signed certs and I hack you in no t

[jez9999]

If I share your WLAN access in a public cafe it's really no big deal to play man in the middle and exchange the presented certificate for my own.

You can't just snoop the packets, it has to be an active MITM attack with specialized software to do that. Adds a layer of difficulty. Not insignificant.

The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store.

Quite a common scenario. If I frequently visit a website's HTTPS site on my laptop - e-mail provider, small online store, etc. - from home, I'll already have stored its cert. Your attack will therefore be noticed when I access it from the WLAN. It's not as good as proper SSL, but as others have said, it's a mile better than accessing stuff via http://./

Privacy is more important

[unity100]

now, there are a lot of websites, services, whatever you name it, that would not care to (or even afford to) acquire single or (in many worse cases) wildcard ssl certs for their services on the web. they will just probably let go of self signed certs, and dont replace with anything.

it will cause easier snooping of personal details of countless millions for people, because it will be easier without any encryption to make snooping harder.

result ? personal data of countless millions going out to black market.

if you are not still aware EVEN if you get your connection hijacked by a man in the middle attack somewhere, you can freeze a bank account, you can chargeback a credit card charge, you can cancel a credit card and do many other stuff.

but, if your PERSONAL details go out in the open, your name, address, social security number, main email, parents' names, (insert whatever sensitive info as you like), you CANT cancel them or take them back or do ANYTHING to prevent them getting spread in the wild, and used for ANY purpose. there is NO way that you can do that.

excuse me, privacy is more important. this 'security' minded move by some programmers will jeopardize millions of people in an angle they never apparently have thought about.

Re:Privacy is more important

[Anonymous Coward]

if you are not still aware EVEN if you get your connection hijacked by a man in the middle attack somewhere, you can freeze a bank account, you can chargeback a credit card charge, you can cancel a credit card and do many other stuff. but, if your PERSONAL details go out in the open, your name, address, social security number, main email, parents' names, (insert whatever sensitive info as you like), you CANT cancel them or take them back or do ANYTHING to prevent them getting spread in the wild, and used for ANY purpose. there is NO way that you can do that. excuse me, privacy is more important. this 'security' minded move by some programmers will jeopardize millions of people in an angle they never apparently have thought about.

Yes, and if your personal details get out in the open because of an man-in-the-middle because your software didn't prompt you to check the certificate because you were so lazy, four more clicks were a burden to you, you have the worst of both worlds. This is an angle that has been well thought out by people that are much smarter than you and I. Thank you for making the opposition's argument for you. Now kindly cease your fidgiting and let the adults talk.

Re:Privacy is more important

[unity100]

your personal details have a much higher chance of going out bit by bit (because every lesser service asks 'security questions', 'birthplaces' as well as names etc) in a post ff3 environment by eavesdropping than getting taken out by a man in the middle. for, it is much easier to let go of a piece of personal information on any website.

Thank you for making the opposition's argument for you. Now kindly cease your fidgiting and let the adults talk.

grow up yourself first. dont post in a mature discussion if youre not able to cope.

Causes

[kvezach]

This is merely a symptom of the confusion that is inherent in SSL. SSL mixes cryptographic transmission security (nobody can sniff what's on the wire, nobody can alter the data) with endpoint authentication (the server is what it says it is). The result is that web browsers like FF abandon the exchange upon encountering a self-signed certificate, since those can be spoofed and would thus break endpoint authentication, even if you just want cryptographic transmission security.

Ideally, these features should be separated, or even better, data transmission be encrypted by default no matter whether the server is end-point authenticated or not. One could then put authentication on top, be it certificate authority based, trust network or web-of-trust based, or bootstrapped by encrypted key exchange where the key is a password or a two-factor authentication mechanism.

I have to disagree...

[duplicate-nickname]

In a world where phishing is a considerably bigger problem then someone snooping your connection, I have to agree with how Firefox functions here. Self-signed certificates provide no way to authenticate the website which is even more important these days after the recent DNS exploits.

I think Mozilla's large "Failed!" message is much better than a default-accept of self-signed certs with a small warning message that would be ignored by 90% of users. Besides, Firefox will still allow self-signed certs after manual intervention.

Re:I have to disagree...

[Lanboy]

I have to wonder if the original article was written by a phisher. Its either that, or a moron.

encryption means more privacy by default

[unity100]

since it will make it harder for any third party to snoop on your connection and information is being sent. you can get your connection hijacked by only one party at a given time, but more than one party may be snooping on your connection at exactly that moment.

Re:encryption means more privacy by default

[MasterOfMagic]

you can get your connection hijacked by only one party at a given time

Buh? Follow the bouncing ball here, kids:

Crime syndicate wants to get into the online fraud business but doesn't want to be directly involved in the actual identity theft.
Sets up a man-in-the-middle network, MitM's self-signed certificates.
Backhauls this connection into a private network where they charge for access to information for a fee.
Criminals sign up and syphon this information for their own use. It's known good!
Crime syndicate walks away with millions of dollars
Criminals have known good information
Your information, credit, and bank accounts have been compromised.
Simply because you wanted four less clicks in your browser.

Repeat after me the holy incantation:
Security is not a checkbox, it is a process.
Security is not absolute.
Security is only as good as the weakest chain.
Encryption protects payload to whomever has the key.
Authentication tells me who I am talking to.
Without encryption, anyone can see my data in the clear.
Without authentication, anyone can see my data by tricking me with a fake key.
I will verify my endpoints and their keys. I will complain when I cannot do so.
Woe be to any man who does not do so as first connect may bring the wrath of MitM.
It doesn't matter how scrambled my bits are if the bad guys can unscramble them.
It's twice as bad when my software lies to me and gives me the illusion of security.
Heed the advice of the Prophet Schneier!

Thank you, I'll be here all day.

Re:encryption means more privacy by default

[unity100]

its much safer and less risk for identity thieves to acquire one's personal information by eavesdropping (now unencrypted, thanks to lessening usage of self signed certs) many sites than trying to get ONE person's bank account.

a bank account can be frozen with a call, a bank account may not contain any usable cash, a credit card can be charged back. but personal details CANT be retrieved once they are in the wild.

its much more horrible to have a LLC opened in your name and credit acquired for it from a bank, with your stolen identity, than losing $750 or $1000 from a bank account.

and you can shove your wiseass poem in your .... well you know.

We need a new protocol/UI

[jeroen94704]

Joe Average User does not understand SSL, self-signed certificates, or anything else about encryption and security. Even though snooping on a wireless connection is easier, in today's world, the attack Joe will MOST LIKELY face is a phishing email sent by an adversary who ultimately wants to execute a man-in-the-middle attack. Granting self-signed certificates the same status as "verified" (And I agree, the system isn't perfect by any means) would make this kind of attack even easier than it is today.

I can educate my mom to make sure "the little padlock" MUST be locked before she does anything on her bank's website. I can NOT educate her to check the certificate's contents.

For people who want encryption without authentication, the solution is not to grant self-signed certs the same status as verified certs. What we need is either a new protocol for encryption-only connections, or a user-friendly way in browsers to do this using existing protocols, for example HTTP-over-SSH.

The real problem is "trusting"

[mlwmohawk]

In the vocabulary of international politics, we need to "trust but verify." Which means no trust at all.

There needs to be a mechanism where a vendor or site can send you a certificate in a way that can't be spoofed. And can then be verified. Maybe it is an email, maybe it is snail mail?

What I don't like about SSL in web browsers, is that they have ignored the "verify" aspect of trust by abdicating the responsibility to a "pay for trust" regime which is bogus. If they can pay, they are trust worthy, right?

Ideally, I should be able to receive a password in the mail (or some form of communication) to unlock a "key" file sent to me from someone I want to trust. I then unlock and install that key on my system and only keys *I* trust get trusted.

It should be easy and standardized across most platforms. Anything less is broken.

Re:The real problem is "trusting"

[bugs2squash]

I like what you're saying...

I created a small web portal, and the things that led me to use a self-signed cert and Firefox were...

1) Users are more comfortable if they feel the portal is secure, even though the information is worthless to anyone other than themselves and, frankly, does not merit that much protection. It was a feel-good thing to give a veneer of respectability. So I wanted https.

2) The money, even a few $100 would not have been an issue, but the amount of corporate hoopla necessary to get my organization to apply for a certificate would have sunk the initiative.

3) I did not want (another) thing in my name, I'm already the owner of the domain, being the owner of the cert just adds another thing to hand over if I ever leave the company.

4) My lousy CSS was too much for IE when the list of objects got too long, only Firefox, Opera and Safari seemed to render it properly in a finite amount of memory.

I wound up sending out a short pdf with screen-shots showing users how to accept the cert. Fortunately, the users are only a handful of relatively technical people.

I would have liked a better way. After all, these people were already willing to accept that the pdf document came from me, they knew me. It would have been far more convenient to have sent them some link to click that would install the cert with no scary questions asked (just a short warning about not emailing to strangers, similar to what others have described).

It might also have been possible to download a non-mainstream version of firefox that allowed this sort of behavior. After all, many of the users of the portal downloaded firefox just for that purpose.

I can't fault FF's default behavior, but it would have been nice to have had other options.

Re:The real problem is "trusting"

[mlwmohawk]

I can't fault FF's default behavior, but it would have been nice to have had other options.

I fault the infrastructure 100% It is designed around "trust proxies" and not "trust relationships" and that's what's wrong.

Use case for self-signing certificate?

[Anonymous Coward]

If you accept a self-signing certificate without verification, you get private communication with an unknown third party. The author of the article seems to assume that such communication is useful. However if you don't want other people on your network to see the data you are sending, then why would you send the data to some unknown entity? Certainly it's no worse than a plain http connection, but it is also no better, and may provide a false sense of security. If you aren't going to provide any real security, be honest about it, save some resources, and use plain http.

Self-signing certificates are useful if you pre-install the certificate on the clients, but in that case you will not see the warning.

I have actually used self-signing certificates without pre-installing for my own personal servers, but the message is not a problem in this case. I considered the risk and consequences of a compromise low enough that it wasn't worth the effort to pre-install, especially since I can save the certificate and will be notified if it changes. However this scenario of laziness does not further the argument for creating a less severe warning. I can't think of a use-case where general users who would be intimidated by the warning should be accepting a self-signing certificate.

You need some warning

[Chrisq]

2) SSL(self-signed): offers encryption

But unless there is some warning about invalid certificate it is subject to man in the middle attacks. Also, unless you check the certificates every time, allowing self signed certificates would allow man in the middle attacks even against sights that have secure signed certificates.

It made me switch back to safari

[kop]

Problems with FF 3 and online banking and my websites plesk control panel made me switch back to safari as default browser.

Can't please everyone all the time...

[BobMcD]

For this problem to be solved, the most popular F/OSS browser(s) must accept self-signed certificates. If Mozilla is unwilling to change their policies, it would be worth the effort of trying to create a *more popular* fork with full SSL functionality.

That's great, and scratches YOUR particular itch.

What about phishing?

Or did you somehow conveniently forget why this feature was enabled in the first place?

Your solution (to seamlessly, silently accept self-signed certs) opens to door wide open for attacks that impersonate well-known websites.

While providing a security warning isn't the only way to solve the problem, it is in fact a step in the right direction.

Let's weigh the stakeholders, shall we?

A) Site operators that want to save some green not buying certs and rolling them at home.

B) Clueless end users that have effectively been trained 'if you aren't warned about anything, the coast is clear'.

Mozilla chose B), and frankly I think this does the most to serve the common good.

In short, your article could well have another title - "Mozilla SSL policy bad for the Phishing" - and that would be a Good Thing(tm)

SSL is useless without proper CA

[Anonymous Coward]

A self-signed certificate is smoke and mirrors. In any situation where I can listen in, I can arp spoof at least (or maybe I've hacked a router?) to hijack the session. Self-signed certs can be easily spoofed, because they contain the same data and raise the same warning; CA signed certs contain a CA signature and don't raise a warning, or raise warning that the cert has expired.

Replacing an SSL certificate for an active MITM attack is trivial in any case where you could otherwise eaves drop on a plaintext conversation. Self-signed certs make this attack totally invisible in most cases (100% of first time visits, and any further visit where you don't check to see if the cert has changed).

Re:SSL is useless without proper CA

[Todd Knarr]

Could you, though? Sure, you can redirect me to your site and present a self-signed certificate. But are you hijacking the first connection I've made to this site? If you aren't, then you tip me off. I've already put the site's real self-signed certificate in my browser, so I'm expecting not to get warnings again. When the browser pops up the dialogs triggered by your unknown-to-my-browser self-signed certificate, this is something I'm not expecting. I'm going to look closer at the certificate to figure out why my browser's popping up a warning about something it shouldn't be.

Re:SSL is useless without proper CA

[bluefoxlucid]

Look closer all you want, but it'll still say the same thing aside from the key. I can fill in any organization, OU, CN, DN, etc. I could completely reuse the existing cert except with a new pub key and signature.

Waah!

[machine321]

If you want SSL to work without any warnings or prompts, set up your own CA and distribute the root cert. Then you don't get used to clicking through a warning, AND you avoid a potential MITM attack.

Firefox is doing it correctly, the article is wron

[Anonymous Coward]

Firefox should absolutely put up big warning lights and make it difficult to use self signed certificates. Firefox is absolutely doing the right thing. There are lots of reasons for this but the first obvious one is that a self signed certificate is completely vulnerable to a man in the middle attack.

What you really want is something else which I suspect is one of these:

- A different way make an encrypted connection between a browser and a website. This should be completely different from the current SSL/TLS/HTTPS.

- A Certification Authority that is free but does a strong validation (vetting) of who the person, or organization, requesting the certificate is.

One of the points of SSL..

[Kelar]

Is non-repudiation. I think the 4 clicks is excessive, but one of the whole points behind SSL is to prove that the site you're talking to is the one you want to be talking to. Especially today with phishing, dns cache poisoning, etc it's pretty important to be communicating with a site that has a valid certificate.

Self-signed certs are fine for development or personal use. If you're using it for that purpose, you have to only accept the certificate once and you're done.

Anyways, SSL certs aren't expensive now, so if you have a need for one on your site, just go to godaddy and cough up the 30 bucks and quit complaining.

Re:One of the points of SSL..

[Creepy Crawler]

You are a moron.

SSL stands for Secure Sockets Layer. It's a SSH for port 80.

They added in a trust setup so someone you trust signs their key.

The "trusted entity" is a for-pay company who doesnt care about jack shit. They only want you to pay.

Now... Why do you trust them?

Could the browser not use DNS records?

[crimperman]

I am not a DNS expert so feel free to correct me if I am jumping to any wrong conclusions here..

It seems to me that the problem (as TFA discusses it) revolves around the use of third parties to tell your browser whether to accept the certificate in terms of authenticity.

If the concern of browsers is to ensure the server providing the certificate is the real one, why are they/we not using something like the SSHFP or CERT DNS record types. If my reading of those two is correct the system could work thus:

- user requests www.foo.com
- browser is presented with a certificate by the www.foo.com server
- certificate cannot be validated by signing authorities so
- browser validates this against the DNS/CERT and/or DNS SSHFP entries

If by this point the browser still cannot verify the authenticity of the server providing the certificate it can throw up a warning to the user. Okay so a MITM attack could provide false DNS records for particular/any domains but they could the same now and redirect a cert lookup to their own spoofed "certification authorities".

self-signed never good and SSL weakness

[CustomDesigned]

I run sites with no commercial CA. I run my own CA. It is very easy to do with openssl. The key is that the sites are used by limited clients. They are the clients own web sites used by their employees and B2B customers. Man-in-the-middle protection is essential - but the commercial CA is unnecessary. The private CA cert is distributed by other means (e.g. CD) and preloaded in the browser.

The above approach is "self signed" in the "do it yourself sense". But I think people are talking about "self-signed" in the "not signed by anyone" sense which is implemented in SSL by signing a cert with itself. Unsigned ("self-signed") SSL certs are for testing only. There is no reason not to sign your sites. Would you provide your own RPM repository over the internet, and not bother to sign the packages? Use your own CA if you don't want to pay a commercial one.

If the general public will be using your site, and you *still* don't want to pay a commercial CA, then use http://cacert.org./ Your visitors will have to install the cacert.org CA cert first, but that is better than having to preload your CA cert and trusting you to sign *any* site.

And that is the weakness with SSL. Once you load a CA cert, you trust it to authenticate *any* website (separate policies available for email). In a less monopolistic world, any cert I download from momandpop.com, would be trusted to authenticate *.momandpop.com - but nothing else. (There is still the risk of man in the middle on first contact.) I would still trust certs from the likes of Verisign to "authenticate" total strangers (as in they had a valid credit card and controlled the sites DNS at the time of application).

Furthermore, I might want to *reduce* trust in one of the default CA certs - perhaps after reading about some scandal on slashdot. I can delete a CA, but not reduce trust. It is all or nothing.

Sniffing vs. man-in-the-middle attacks

[tepples]

If you do not know who you are talking to, encryption does nothing to increase your security.

Citation needed. HTTP is vulnerable to both sniffing and man-in-the-middle attacks. HTTPS with a self-signed certificate is vulnerable only to man-in-the-middle attacks, which are more difficult than sniffing.

Re:Sniffing vs. man-in-the-middle attacks

[Anders]

Citation needed.

Here

HTTPS with a self-signed certificate is vulnerable only to man-in-the-middle attacks, which are more difficult than sniffing.

Harder does not equal more secure, just more work for the attacker. Once he has your credit card details, you do not really care how hard it was to get.

Re:Sniffing vs. man-in-the-middle attacks

[Chandon Seldon]

Harder does not equal more secure, just more work for the attacker. Once he has your credit card details, you do not really care how hard it was to get.

Different attackers have the capability of executing different attacks. In security, attackers who can snoop and attackers who can hijack are considered to be sufficiently different that they're even given different names in the literature. Being able to defend against Eve is useful even if the defense doesn't help you against Mallory.

If we want to ignore the the capability of executing different attacks then nothing is secure. Everyone can execute the social engineering attack necessary to get access to every root CA certificate for example.

The real CA

[Balau]

Firefox users are more tech-savvy than average. The decision to reduce web usability of self-signed sites could potentially reduce the number of non-tech-savvy user. This could damage Firefox, not net neutrality.

The first Certification Authorithy in this scenario is not Verisign, it is Mozilla. I decide to give my trust to Mozilla. If something like big police-iconified warnings occurs for self-signed certificates, I am free to deny my trust to them and change browser.

Besides, I think that Firefox should display a warning as big as that one also anytime you type a password field inside a non-encrypted site. Coherence.

Real value

[SplatMan_DK]

The real value would consist of actually attempting to verify the identities of those requesting a certificate. Otherwise it would all be pointless, and self-issued CAs would be just a s good.

You ask a couple of good questions, and I have no clear answers for you. I am not already on the CA business - in fact the goal of my original post was to gain further insight and hear suggestions on the matter. ;-)

Having said that, I am pretty sure it would be possible to establish some level of identity checks. The current model relies almost 100% on completing a financial transaction. Or in other words: paying for a certificate will almost 100% guarantee you a valid commercial certificate. I think a dedicated community could do better. And one thing which many enthusiasts are able to contribute to such a project, is TIME. Time spent on validating the identities of applicants.

Suggestions are welcome.

:-)

- Jesper

just drop the lock icon

[tepples]

So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?

Because it is insecure website that tries to pretend that it is secure.

Then why not just drop the lock icon in the status bar for HTTPS sites using a self-signed certificate?

why non-profit?

[TheSHAD0W]

Why does it need to be non-profit? Why can't it just be reasonably priced?

But yeah, the answer to this problem is to create a CA that isn't expensive. What IS the procedure for starting a certificate authority?

You'd have to change the HTTP alert the same way

[tepples]

Wrong.
"The communication with this site is insecure because even though data transmitted is encrypted, you don't know if some hostile 3rd party is intercepting, decrypting, recording and possibly altering data on the way. Additionally, there is no guarantee that the certificate or the web site belongs to the organization you think it belongs to."

Then you would have to change the alert box for HTTP sites in the same way:
"The communication with this site is insecure because it doesn't encrypt the data you're sending to it. Furthermore you don't know if some hostile 3rd party is intercepting, recording and possibly altering data on the way. Additionally, there is no guarantee that it's owned by the organization that it claims to belong to."

Besides, if you accept a self-signed certificate, you at least know that you're communicating with the same party with whom you communicated before. Once somebody starts to snoop a connection for which you have accepted a certificate, the certificate will change, and you'll get another warning. Code signing in Mac OS X takes advantage of this: even if VeriSign doesn't know the publisher of a new version of the program, at least the operating system knows it's the same publisher who released the last version. So we'd have to modify your proposal as follows:
"The communication with this site is insecure because even though data transmitted is encrypted, the site's certificate has changed since your last visit. This could mean that you are actually communicating with a different organization, or that some hostile 3rd party has started to intercept, decrypt, record and possibly alter data on the way."

No particular reason

[SplatMan_DK]

Why does it need to be non-profit? Why can't it just be reasonably priced?

Well, no particular reason. But I personally believe that non-profit organizations are good at focusing on the customers actual needs as well as keeping the price down. The do not need to consider "profit maximization" parameters all the time, and they never deliberately try to cripple their products or devide them into a gazillion different sub-products and product types.

And "non-profit" is not free by default. It could very well be "reasonably priced", where the level of "reasonably" is determined by the actual costs of running the service - minus what ever donations and grants the operation may get from elsewhere.

:-)

- Jesper

This web site is not your bank.

[tepples]

And Grandma doesn't care about getting secure access to your blog.

She cares about reading the news, chatting about knitting on the wool forum

And making sure that her password for the wool forum doesn't get intercepted.

sending email to the grandkids

And making sure that her password for her web mail account doesn't get intercepted.

Streamlining this process or just warning Grandma will leave her with an empty bank account in no time.

Or perhaps the warning for HTTPS using a self-signed certificate could be to the effect: "This web site is not your bank." It could treat self-signed HTTPS much like web browsers treated 40- and 56-bit HTTPS before the United States eased export restrictions at the end of the Clinton administration.

Re:This web site is not your bank.

[Nursie]

"And making sure that her password for the wool forum doesn't get intercepted."

She probably doesn't know or care about the possibility of anything like that happening.

"And making sure that her password for her web mail account doesn't get intercepted."

She uses Gmail, which "Just works". Like MSN and Yahoo.

"Or perhaps the warning for HTTPS using a self-signed certificate could be to the effect: "This web site is not your bank.""

Nobody will take the blindest bit of notice of a warning like that, and if you give them the real warning - "There is no guiarantee that you are talking to who you think you're talking to", then yes it will sound scary.

Perhaps the answer is to scare people even more about unencrypted comms.

Free Certificates from approved authority

[Anonymous Coward]

http://cert.startcom.org/

StarCom offers free SSL Certificates and is included in Firefox 3 as an approved authority.

The obvious solution

[Apaxmai]

So this is my take on all of it. To protect online commerce we need a noob-compatible "trust factor". Like some replies mention, this is achieved with the 'https' and the little lock icon (as well, now the coloured URI bar in IE). However, we also need self-signing to be a valid practice -as it was meant to be-. In this regard the error message itself is incorrect e.g. "cyote.ferrus.net uses an invalid security certificate" a self-signed certificate IS NOT INVALID. An invalid certificate is an expired/revoked/erroneous one; but I digress. The real point here is that we need two levels of trust- not a level of trust and level of distrust. There should be some way to allow a noobie user to easily identify if a certificate is signed by a CA, self-signed, or invalid. Only the third option should present itself with a horrible 5-click error message. The first option should look the "most secure", say with a lock icon and a "blue bar". The second option should have the lock icon but no "blue bar" (replace "blue bar" with whatever have you). As someone who self-signs certificates daily I had really hoped that FF3 would fix this erroneous "error" message.

This is a general problem with SSL...

[argent]

The SSL model of certificates signed by a CA is a huge contrast to the SSH model, using much of the same underlying technology, of concentrating on whether a certificate has changed.

Browsers should let you know about self-signed certificates, but they should only give you a warning the first time you visit a site with such a certificate, or if the certificate has changed. Warning you over and over again about a certificate that you have chosen to trust is a lousy model that actively discourages people from using SSL.

And, while I'm on the subject, they should probably warn you about certificate changes whether they're signed or not!

Re:This is a general problem with SSL...

[Anonymous Coward]

Warning you over and over again about a certificate that you have chosen to trust is a lousy model that actively discourages people from using SSL.

Firefox forces the user to accept the self-signed certificate as an exception before it will let them access the site. Thus, Firefox does not warn you over and over again. IE7 allows the user to go to the site without storing the certificate, and will warn you over and over again if you revisit the site.

Re:This is a general problem with SSL...

[argent]

Firefox forces the user to accept the self-signed certificate as an exception before it will let them access the site.

Which would be an improvement over the existing experience with SSL, but apparently the process of doing so is sufficiently daunting to have caused this article to be produced.

Cool, I can't even sign up with them.

[argent]

It doesn't allow me to use a real address that can be crosschecked with my phone number, because my phone service is mobile and will crosscheck to my PO Box, and they won't accept a PO Box. Why my PO Box? Because I've used my PO Box as my billing address for everything for over a decade. Why? Because I've had too much stuff vanish from my kerbside letterbox, and had several thousand dollars worth of problems from someone using stolen bills to take out a credit card in my name.

Got another alternative?

Re:No, it is not considered bad for the web.Blogra

[Anonymous Coward]

StartCom Certificate Authority (http://www.startssl.com/) offers free SSL certificates, and it's root certificate is included in Firefox 3.

I strongly agree

[Sloppy]

Encryption and authentication, while certainly related concepts, should be treated more separately in the UI.

You should be able to easily -- transparently without the user really even noticing unless they pay attention -- encrypt. No matter what, and totally regardless of whether or not the other side is sufficiently authenticated and whether or not you're vulnerable to MitM.

Remember that when you have an unencrypted connection and the other side is totally unauthenticated, with even less than a self-signed and untrusted certificate, THERE IS NO WARNING. https without authentication should not look any worse, in any way, because it is no less secure.

Anyone who claims that https with an untrusted cert should produce a warning, needs to defend the policy of there not being a warning when there's no cert at all. Good fscking luck.

Any broken security is bad

[Anonymous Coward]

Your problem is a problem with ALL security measures. If they are broken you think they are safe when they aren't. This isn't just a problem with SSL.

To get SSL vulnerable to a MITM attack, you have to be giving your credentials to the other party by the same means as your secure protocol works. If you give the MD5 fingerprint via phonecall they can trust your cert and if they did likewise, you can trust them.

Unless someone has hacked your address book and given you the wrong phone number. Or hacked your SS7 switchboard or something similar.

Then again, if they hacked your OS and changed your CA signatures for IE then you're just as boned.

ONE of the points of SSL

[argent]

One of the points of SSL is non-repudiation.

Let's change the emphasis, a bit?

Only ONE of the points of SSL is non-repudiation.

So, let's throw out everything else and discourage people from providing encrypted access to their servers?

I think that's a bad idea. I've thought that a bad idea for about as long as I've been aware of the way SSL worked.

You would get the majority of the benefits simply by performing the test "is this certificate the same as the one this site provided last time?"... and really, if certificates are cheap... and given that there have been widely publicized examples of fraudulently acquired certificates (including one for a Microsoft domain on one occasion), this test should be applied regardless of whether the certificate is signed.

Re:Accept self-signed certs and I hack you in no t

[SydShamino]

The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store.

And if I just want to use SSL to check my email on my private domain from a public hotspot, and have the certificate stored ahead of time?

Does it work in that case? If so, isn't your first sentence incomplete?

Non-commercial web sites matter

[tepples]

Unprofessional webhosters (good riddance)

Be careful. Would you want to say good riddance to every non-commercial web site? Should every web-based forum have to pay $$$ per year just to encrypt users' passwords on the way to the server?

Re:addon to allow fast-add-exception of self signe

[Anonymous Coward]

You can also set browser.xul.error_pages.expert_bad_cert=true and Browser.ssl_override_behavior=2 to make it easy to accept self-signed certificates.

Warn when the cert for a domain changes

[tepples]

If you are talking to somebody who poisoned the DNS cache, masquerade the site you want to talk to, using a different self-signed certificate, you are absolutely ignorant about it: your experience will be exactly the same.

Try this use case: Start a web browser that properly supports self-signed certificates. Visit an HTTPS site using a self-signed cert. You get a (minor) warning and accept the cert. Then someone starts poisoning the DNS cache using a different cert. You get a major warning that the cert for this domain has changed.

So a man-in-the-middle attack can succeed only in the case that the first visit to a site uses the poisoned cache entry.

Re:Warn when the cert for a domain changes

[kisielk]

Or if you ignore the subsequent warning when it changes. That's the likely case for most users who don't know any better.

HTTP is the elephant in the room

[tepples]

And making sure that her password for the wool forum doesn't get intercepted.

She probably doesn't know or care about the possibility of anything like that happening.

She might if like a lot of Internet users, she uses the same password at her bank and the wool forum.

Perhaps the answer is to scare people even more about unencrypted comms.

Bingo. But the commercial SSL CAs don't want to acknowledge this elephant in the room.

Huh?

[SilverJets]

This behavior means that a public web site basically can't be encrypted unless they are willing to pay an approved vendor a yearly fee for a certificate.

Ummm...no it means that the site is encrypted, Firefox just has an odd bunch of hoops for the user to jump through.

I don't agree with the new Firefox behaviour in this regards, but the author of the article is completely wrong with that statement.

Solution.

[clsours]

The main argument of TFA is that FF3's warning about self signed certs is egregious.

There is not an issue about warning users; users need to be warned.

What is needed is individual warnings in a drop-down bar for individual problems with certificate issues:

*(picture of green 1's and 0's alongside a red face with a line through it) This certificate is self signed; It may not be trustworthy for identification purposes, you should only trust it for data encryption purposes.

*(picture of a green face alongside a red clock with a line through it) This certificate is out of date; it expired YYYY MM DD HH MM SS ago.

*Trusted case: (picture of a green face) This certificate identifies XYZ.com as trusted by CERTCORP.com. Your data is encrypted.

er

[Anonymous Coward]

This is the stupidest article I've read lately. Encryption without knowing who provides that encryption, is useless. It's basically the same as no encryption at all.
For me the question is, should self-signed certificates be allowed at all by default? I think not!

Low-hanging fruit

[tepples]

Citation needed.

Here

Not everybody who reads your comment will be prepared to buy and read the entire book just to reply. Page number please, and preferably a quotation under fair use if you can.

HTTPS with a self-signed certificate is vulnerable only to man-in-the-middle attacks, which are more difficult than sniffing.

Harder does not equal more secure, just more work for the attacker.

Exactly. If your site uses self-signed HTTPS, it is less likely to get hit than someone else's site that uses plain HTTP. It's called not being the low-hanging fruit. The problem here isn't that self-signed HTTPS has a warning but that plain HTTP has no warning.

Once he has your credit card details

Of course you wouldn't put payment on a self-signed site. Third-party payment processors such as PayPal and Google Checkout have EV SSL certificates for that. Public self-signed HTTPS is more about keeping people from stealing passwords on a non-commercial forum or wiki.

Re:Low-hanging fruit

[Anders]

Citation needed.

Here

Not everybody who reads your comment will be prepared to buy and read the entire book just to reply. Page number please, and preferably a quotation under fair use if you can.

Well, lets try page 24: "And if he doesn't know who sent the message, then the message is pretty useless."

Re:Low-hanging fruit

[Anders]

It's called not being the low-hanging fruit.

That may be. I just said that it's not called security.

Restraint of trade and monopoly practices

[Anonymous Coward]

This is very bad for intranets and trust coalitions. If you run a CA that is not eligible for admission to the browsers' distributed collection, then you have a problem. Admission to the distributions requires both an expensive annual audit and persuading the browser vendor that the CA has a compelling business case _for the browser vendor_. In general this includes requiring the CA to "serve the general public" and this requirement is subjective and in the control of the browser vendor.

You either buy SSL certs from the approved list of CAs, or you do without, and you follow the verification practices of that list, whether they make any sense for the business you are in, or not. At least with Windows you can integrate private CA management into AD but this is far from adequate if you have a broader community to support.

Then we have the interesting history of the EV certificate and the self-appointed group of insiders that pushed this development.

This is a lot like the oil & steel trusts of the 19th century - isn't that ironic.

The ability of this architecture to manage multi-level CAs is also very limited. Not sure of the reasons but the scaling problems involved in managing collections of subordinate CAs and providing oversight for their policies may be involved.

Typically the browsers have moved towards supporting more flexibility rather than less, but this is a glaring if tiny exception. What would be the motivation?

If this is a move in the direction of monopoly or an old-fashioned business trust, then one should be able to make some predictions. The lists in different browsers should become identical. The bar to entry should get higher and higher. The criteria for certificates should get higher and higher, increasing costs for verification which have to be passed on to the purchasers of certificates. We're on the path for some of this but not others.

Re:Users conditioned to click to accept everything

[Neva]

Certificates are used to increase trust, self-signed certificates are pretty useless in that sense.

However, as was pointed out earlier, the big problem is that Firefox hasn't imported CACert root certificate in it's trusted database yet.

www.cacert.org offers a distributed verification system and service for making your own certificates using their own root certificate.

You basically need to find 3 members who validate your ID documents and place trust that you really are who you claim to be, and thus can be governmentally held responsible for any online actions you choose to do with the certificates you create. Hence the added trust. Validation can also be done via a trusted 3rd party, such as a bank manager or a notary.

DNS as out-of-band verification solution?

[JSBiff]

I can see the point that people make about encryption to an un-verified certificate (like a self-signed) being, potentially 'false security', but I also think the main article has a sort of point to -

Mozilla has always warned users about self-signed certificates, but I've never liked the warning. I think they are poorly worded and confusing to people, and the latest incarnation is particularly obtuse.

There is a place for self-signed certificates, I think, there just needs to be a way to add those self-signed certs to users browsers in a better fashion. Self-signed certs are perfectly safe if you have some way to verify them 'out-of-band' - that's the tricky part.

I think the ultimate answer to this problem might rely as part of a secure DNS system. We've seen from the recent DNS cache poisoning vulnerability that the current version of the DNS protocol is starting to show it's age. Perhaps DNS needs to be re-designed to include cryptographic verification of the DNS chain, so that you can know you can trust data from DNS.

  If you're defining a new version of DNS anyhow, it might be a perfect opportunity to make CAs less necessary, by allowing webmasters to put their self-signed cert into their DNS records (or maybe, that might add too much data to DNS requests, but you could at least add a secure hash so that the browser could verify the cert that the web server passes it, against the DNS record for that domain). I think there might still be a place for CAs for giving additional verification (e.g. DNS would just allow you to know you were getting the right certificate for that domain, CAs can maybe do additional verifications to make sure that the organization that owns a particular domain and SSL Cert really is who they claim to be, maybe?)

    Let every DNS record be its own Certificate Authority.

Shooting the messenger

[Schraegstrichpunkt]

It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.

No kidding. Using self-signed SSL certificates was never really all that trustworthy, but most people weren't aware of it and so just kept on using them. Firefox 3 simply brings to light what everyone with a clue already knew:

The HTTPS security model is a barely-functional hack.

Not surprisingly, a lot of people aren't happy to find that out.

There are really only two things that can solve this:

1. A self-certifying URL syntax (preferably using something like SPKI so remote servers can delegate their keys); or, if that's not possible,
2. DNSSEC, so we can strongly map the server's public keys to its hostname.

Not more or less secure

[Squeeself]

The problem as I see it is that self-signed certificates are not any more or LESS secure than unencrypted http traffic. There's no reason for an additional big security warning: just treat it like normal http sites. That is, no extra visual cues, the only difference being the https in the URL. Real certificates can then have their visual cues based on their relative authenticity (automated CAs being marked as less secure, etc.) The only visual cues that should come up is big fat warnings if the certificates don't match the last time you visited a self-signed website. The only downside is amateur website creators thinking self-signed is more secure, but it doesn't hamper legitimate uses of self-signed certificates (i.e. situations where you have more direct access to clients). Plus, most amateurs should get at least a sufficient amount of training when setting up SSL to know the difference. Honestly, this would be the best way and I've never understood why there were additional warnings in browsers for something that didn't make a website any LESS secure.

Except that's incorrect

[Anonymous Coward]

The problem with this is there isn't actually anything "wrong" with those certs and they shouldn't be made to appear to have something wrong with them.

Don't be stupid

[wiedzmin]

Firefox's new implementation of handling malformed certificates is a new bold step towards eliminating the most ridiculous concept of our time - security through obscurity. If you are at all familiar with the man in the middle attacks and phishing, you should understand that "this certificate is invalid" warning is not just a way to annoy an end-user - it indicates that the certificate can, or may have already be spoofed, and that your "secure" connection may not be secure at all.

This is equivalent to Apple users believing that there are no viruses for Mac OS or Microsoft users thinking that Vista's security model is annoying. Without realising it, people like you are making hacker's jobs a lot easier with your whining about convenience. Is it not enough that IE users already have a habit of clicking "OK" just to make "annoying" messages go away, without giving a second thought as to what the consequences may be?

If anything - you should be promoting the concept of open source certificate authorities, not pushing one of the best browsers to ignore unsigned certificates... Firefox/Mozilla's new handling of SSL is a breakthrough and if you don't think so - be my guest, ignore the warning message if you get one next time you go to your online banking website.

braindead PEBKAC rant

[v3xt0r]

Just add an exception. Then, you'll get an encrypted connection to the self-signed site. What's the problem?

I agree it's annoying, but this is not 'bad' for the web or it's users, this is good. I'd like to know if I'm being connected to a potentially malicious SSL site that uses a self-signed cert. For instance, if my browser was encountering a URL hijacking attempt to a site like my bank, and it's using a bogus cert, I'd like to know. Otherwise, I'd most likely not know I'm being hijacked.

Re:Most clueless response ever?

[Anonymous Coward]

Parent advocates allowing the encrypted connection to the man in the middle, so that people will feel all warm and fuzzy. Good plan. Not.

Having an encrypted connection to a man in the middle is worse than having a plain-text connection, because at least with plain text there's a chance you won't get pwnt.

Consider: You <=> Man in the middle with self signed cert <=> Your bank

1. You lookup your bank's DNS entry.
2. DNS poisoning redirects you to man in the middle.
3. Man in the middle presents self signed certificate.
4. You create an encrypted connection to man in the middle.
5. Man in the middle decrypts your content and re-encrypts it in a separate conversation between him and your bank.
6. Bank lets him do whatever the hell he wants, because he has your password and he's using SSL.
7. You'll think you just talked to your bank.

More than self-signed certs

[Windrip]

FF3's behavior is utter crap: It's more than self-signed certs.

I've paid for a certificate. I've installed it on a website that uses Plesk, which doesn't correctly install certs.

IE doesn't complain, FF3 does. It's got something to do with the trust chain.

Don't bother posting the inevitable reply: "Google for certs + plesk". I've tried that technique. Fail.

I know: "FF3 developers are just so much smarter than the rest of us, we should just be grateful for their work." Screw you.

Re:More than self-signed certs

[Anonymous Coward]

If you think there's a bug in Firefox, why not file a bug report? Surely it's a much more effective way to get your problem fixed than featuring your rant on Slashdot.

Another rant about it

[rduke15]

Here is another rant about this problem: The Firefox 3 SSL scam. This one takes the angle: how much money did the Mozilla Foundation get from big business (Verisign et al.) to kill self-signed certificates?

Note that in FF2, the dialog was perfectly clear, safe and simple. Nothing needed to be changed.

The same server sent these messages

[tepples]

Well, lets try page 24: "And if he doesn't know who sent the message, then the message is pretty useless."

Nobody can really know who sent the message. Perhaps an attacker learned the server's root password or (gosh forbid) gained unauthorized physical access. All we can know is to some confidence level who or what sent a message. And self-signed SSL gives some confidence that one server sent all of these messages.

Not because they are self-signed

[Anonymous Coward]

All you need for self-signed certificates to work is that they are accepted as long as the private key doesn't change. It's a GUI problem. You can hack wlans all you want if the browser pops up the big red warning signs when you inject a *different* cert for a site.

Which four clicks are those?

[Anonymous Coward]

You going to tell us how you got it to work?

Because I've not been able to the two times it happened to me.

Click on the "Add an exception..." button and all the choices but cancel are greyed out. Very user-friendly that.

Kevin

Firefox 3 is not worth attention.

[Anonymous Coward]

Sorry, but honestly Firefox 3 s*cks. Plugin problems, tons of very nice unsupported addons, unwanted invasive features, makes older version profiles incompatible with the old version, privacy issues, etc.

If I wanted some idiotic silliness of IE I'd take IE, that's it. I'm just one user, but I'll firmly stick to version 2.

Re:Firefox 3 is not worth attention.

[Anonymous Coward]

I agree. All this anti-phishing is nice, but It's QUITE annoying.

I don't need my browser to hold my hand. I have a brain and I know how to work it, thanks.

Re:Accept self-signed certs and I hack you in no t

[Anonymous Coward]

You fail to notice one problem. Who goes to an httpS address first?
Usually when going to, for instance, a bank, a user will type in the name of the bank in the URL bar. They'll get the unencrypted website. They'll then click on the login button and get thrown to the secure site. How may of them re-authenticate the URL at that point? None.
The attack is obvious: buy a cert for a real unrelated URL, intercept the initial HTTP transaction and modify it so that all secure transactions go to your phishing site. No warning messages will be displayed, and the lock will show up just fine.
Does FF attempt to see if there's an https equivalent of the site before looking for an http version? That would most likely do significantly more good then denying self signed CAs

With regards to self signed certs, you are correct in saying that an attack on a first time connection could succeed. That is why the default for these certs should be to permanently accept: this ensures that, for a repeatedly used site, the man in the middle attack would have to be continuously done for the user to not suspect foul play.

Mozilla gets bashed for doing it correctly.

[drolli]

Yes. You can encrypt your connection. Thats pretty worthless if you dont know with whom you exchanged your keys. Especially in the light of the DNS vulnerability or using wireless hotspots it is pretty idiotic to claim that talking to something which you dont know is to be considered private. This screams for man in the middle attacks. And You still have the option to accept the certificate - which will increase your safety. But one should point out to the user that this is something special. I find it highly irritating that a lot of companies don't pay the small amount of money for an ssl key. I work in a company where the admins are signing the ssl key for the mail server by themself (and change it often). Thats completely great. you could hack them without them noticing it, sincer everybody is so used to clicking away trhin innocent gray warning messages . On the other hand, firefox allows the definition of own ca's doesnt it?

FF user interface is exactly correct

[snowwrestler]

There is a "warning," and then there is a "WARNING: YOU MUST CLICK FIVE TIMES TO SEE THIS PAGE."

You might understand the difference between the encryption and authentication uses of SSL, but most people do not. Worse, their ignorance could provide a very effective vector for social engineering attacks.

User interface warnings are for people who do not understand what they are doing. They don't know where the trouble could come from, so the software must help them. Anything that presents a likely avenue of trouble should have a strong warning in front of it.

Those who do not understand potential avenues of trouble should be encouraged to simply stay out them. Those who do understand what they are doing will also understand the warning, and know that is ok for them to proceed.

A simple bar across the top of the page with a warning that the sites identity couldn't be verified, but that the connection was still encrypted would work just fine.

Work just fine for who? It seems to me this "issue" is basically a small number of power users annoyed about having to click an "ok" button a couple times.

Required classes

[pseudorand]

Self-signed certs ok? net neutrality? Mr. Tuck is an embarrassment to The University of Massachusetts Lowell. Obviously they should let him post anything within the bounds of the 1st amendment and academic freedom, but I hope some professor at least makes sure he takes the appropriate classes to straighten him out about how authentication and encryption work and what net neutrality is before they hand him a diploma.

On the other hand, perhaps he's just some freshman posting junk on his university-supplied web page who had no idea it would get such scrutiny on a forum as public as slashdot. In that case, shame on Chandon Seldon for posting it to slashdot and especially shame on the editors for accepting the "story".

I know, I know, "complaining about the editors? I must be new here."

Connections are still encrypted

[cdhgee]

TFA seems to imply that the Mozilla policy degrades HTTPS connections down to plain HTTP - Not only does it make users less secure overall by reducing the number of encrypted connections. This isn't the case - assuming you add an exception for the particular site you are accessing over HTTPS that is using a self-signed certificate, your connection to that site is still encrypted. The only difference is that you don't have the trust element that a commercial HTTPS certificate would give you. IMHO, Mozilla is quite right to add a warning to this effect to protect the masses.

Re:Connections are still encrypted

[grikdog]

Burned all my mod points on Ubertroll, or that would get a +1 for informative. Thanks.

I happen to like the new UI ...

[Anonymous Coward]

It's clear what's happening, and takes a pretty braindead wizard-type approach to importing the cert. The sky is not falling. Move along.

Linksys routers with self-signed certificates

[TwobyTwo]

Many popular Linksys routers are administered by pointing your browser to an https link, typically:

https://192.168.1.1/

The router presents a self-signed cert. These routers were easily administered using early versions of Firefox. Now with Firefox 3 there's lots of confusion, with many users falling back to IE.

Turns out the situation is complicated by the fact that you can easily convince FF3 that you've got duplicate certs; to get past that you've got to do some wizard-level magic to get rid of the dups before you even get to wrestle with allowing the exception for the self-signed cert. After all that, you can indeed use FF3 to administer your router. On good days.

Does using https in this case add to security? In practice, I think the answer is, "yes, to a significant degree." I'd rather have the admin traffic to my router encrypted, even if in principle a hacker with perfect timing could have gotten "in the middle" just as I was accepting the cert.

Anyway, it's another consideration.

Re:Accept self-signed certs and I hack you in no t

[Anonymous Coward]

What you are describing is not self-signed certificates, but a self-run CA. No problems there, in fact self-run CAs are pretty much the way to get around (most) of the problems of self-signed certificates. You sound interested in this stuff; you should talk to the guys who manage it.

How rude

[Anonymous Coward]

How dare Firefox warn me that an insecure site is insecure! They are infringing on my right to have my computer infected with malware and/or have my bank account stolen!

Why MitM-vulnerable encryption still has value

[Sloppy]

You could use the most powerful encryption system conceived, but if you send the message to the wrong person -- you're still compromised.

Which is no worse than sending an unencrypted message to the wrong person. Is it bad? Sure. Is it worse? Make your case. So far, no one has.

Encryption is useless without trust.

This is what I take issue with. First of all, I want to state that I do not belittle the value of authenticating that you have the correct recipient's key. Obviously, that is highly desirable, and I agree that it is necessary when integrity is necessary.

Now let's look at the case where integrity -- being MitM-proof -- is not necessary.

I don't care about the authenticity of Slashdot posts, so signing or encrypting them is of no value.

No value? You would really assign absolutely zero value to that? I can think of two ways it would add some value. Perhaps neither of these is of value to you, but if you think the UI for unauthenticated but encrypted sessions should display a warning while unauthenticated and unencrypted should not display a warning, then apparently one or both of these has negative value to you.

Remember there is a key difference between encrypted-but-unauthenticated sessions (which I admit are vulnerability to a cryptographic MitM attack) and unencrypted-and-unauthenticated sessions: the encrypted one requires a cryptographic MitM attack (whereas the unencrypted one does not). Here are some consequences to that:

1. They must pay a higher equipment cost. Now instead of a copy of every packet going to the NSA's room in the AT&T building, every entire session must pass through that link, with the attacker's computer decrypting each packet with their fake key and re-encrypting each packet with the endpoints' keys. In addition to the added CPU cost (which I don't think is a lot these days, but it is certainly not free and can add up if done on a massive scale) their pipes must be at least twice as big, and their low-latency requirement has just shot up (passive surveillance, unlike active MitM, has very lax latency requirements). You're making the Bad Guy's work more difficult and expensive.
2. If the party doing this is not above-the-law, there is a liability risk. To insert their ads on Slashdot, your ISP needs to forge Slashdot's untrusted cert. They can theoretically get away with that, but they are opening themselves up to criminal and civil liability. At a minimum, their lawyers are going to council "maybe we shouldn't do this."
3. Here is the best part, and I'm amazed you people don't see this one. Trust and lack of trust are subjective!! It is not a blanket truth that a self-signed cert is less trustworthy than a Verisign-signed cert; that is merely the usual case. A MitM attacker DOES NOT KNOW whether or not you have verified the correctness of someone's self-signed key out-of-band or not. Unless they compromise your machine itself (rather than your network), they don't know for sure who is listed in your Firefox's "Certificate Manager" window, "Authorities" tab. That means they can't safely launch MitM attacks between any two arbitrary parties, because eventually they will be detected. They will usually get away with it, but it only takes one person who has validated a fingerprint out-of-band, and then the jig is up.

The more we replace unencrypted sessions with encrypted-but-not-authenticated sessions, the more cost and risk we pile onto attackers. Sure, getting those sessions authenticated is even better. But that first step, the mere use of encryption, has benefits in itself.

The Firefox team should encourage that leap forward. But if they are not willing to do that, then they should at least stop being an obstacle.

Self signed cert. like WEP

[Anonymous Coward]

Self signed certificates are just like using WEP encryption on wireless. It makes people think they are safe, when in fact they are not. When people feel safe, they are easier to persuade to give out details they otherwise would not.

In this sense using self-signed certificate outside of closed communities is provably worse than using no SSL at all. It luls people in a false sense of security, which is the worst thing that can happen.

Yes, it is true that SSL can be used for encryption only, without verification and proof of authenticy. I could just as well use truck to commute every day, without using it's cargo hold, but nobody would ever say that is a good or useful idea(*).

(*) SUV owners might disagree, but they are becoming a dying breed anyway.

Re:Self signed cert. like WEP

[Anonymous Coward]

You are smoking crack. How is using a self signed cert or Verisigns cert *ANY* different for encrypting data ? Oh wait, its not. The only difference is a mild level of verification that the person owned the cert may be who they suggest they are.

When I log into a messageboard that uses SSL to protect my plain text password, being verified by Verisign doesn't offer me anything more.

We need a community based CA, like cacert.org. However, the Mozilla team won't accept them without their "little brief cases". Yes, I think the Mozilla team is requesting bribes for CAs to be included. Why else would they keep rejecting cacert over and over again ?

You missed the point.

[Anonymous Coward]

MitM attacks don't have to be at some point physically between you and your intended destination... just logically.

If I can poison your ISP's DNS cache with a bad resolution for www.your_bank.com and you accept my self-signed cert then I own you.

If I can get you to believe that phishing email that I sent ("Urgent Action required! Update your security details at www.y0ur_bank.com") and you accept my self-signed cert, then I also own you.

Neither of these attacks require me to be on a network segment between you and your ISP,but are indeed MitM attacks.

Tagging this one "moron".

[karmatic]

If you don't verify a certificate against something, it's utterly useless against Man-In-The-Middle attacks.

I take a server, generate my own cert and key, and present myself as that server. I then take your data, and forward it to the server, and forward the response to you.

This leaves me with all of the data, making SSL worthless.

So, yeah, I'm going to go with "moron" on this one.

There's no alternative.

[Anonymous Coward]

My office just got hit with a rogue-DNS oriented MITM attack. Enhancing usability in this manner makes you SERIOUSLY vulnerable to such attacks. Firefox 3's behavior in this regard saved our asses, because it's what alerted us to the problem in the first place. This is no joke.

The proposed solution in the referenced livejournal link is reasonable. But in no way should you make it terribly easy, because doing so would be a lurking disaster.

I speak for many of us when I say that this is ...

[Anonymous Coward]

... all bullshit.

Mozilla has an honest, vested interest in protecting the credibility of the little TSL (artist-formerly known as SSL and/or HTTPS) 'lock icon' in their Firefox browser.

Mozilla wants this icon to mean "by the best of our abilities, the Mozilla Foundation believe that the website you are visiting is who it claims it is."

Allowing anyone to slap the lock icon on their site subverts the credibility, and hence utilty, of the lock icon.

the URL bar colour

[Anonymous Coward]

The browsers are so happy to make the URL bar green when it is a secure site.

Then make it green when the site is verified and encryped.

Make it blue when it's only encryped.

and make it red when it is not encryped.

And make it yellow when only something on the page is encryped.

Re:the URL bar colour

[Antibozo]

There's such a thing as colorblindness, you know. It's not uncommon.

What?!

[djw]

create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode)

How are your customers going to know the cert comes from you? As long as you're serving it from a known address instead of personally installing it your clients' browsers, couldn't the man-in-the-middle that you're so worried about just replace your cert with his own? Or am I missing something?

Re:What?!

[spottedkangaroo]

I'm not worried, I bought a signed one for $10...

If you're worried, it's a solution you could look at.

Re:What?!

[djw]

Fine, good for you.

But please don't continue to suggest your #1 option above. It accomplishes nothing helpful and is in fact worse than an unencrypted connection, because it gives your users a false sense of security. I'll give you an example.

Citibank used to have a login page that was not served over SSL, although the form submitted to an https: URL. This was dangerous because there was no way to be sure the login form hadn't been changed en route. You could be giving your password to anyone.

To reassure their less-informed users, Citibank actually displayed an icon of a lock near the login box, and if you clicked on it, a message popped up explaining that the lock icon meant the page was secure and that you should never submit confidential data without seeing this icon. This message was not just wrong; it was blatant, exploitative disinformation that put less knowledgeable users at greater risk for no good reason. Now anyone with a picture of a lock can pretend to be secure! So thanks for that, Citibank.

Your "solution" #1 is akin to this, but in some ways more dangerous. If you do this, your users are no better off, but you've kept them from seeing a useful security warning. And if your certificate does get spoofed, now they've compromised their browser, and criminals can use the fake cert to forge any site they want to those users. So thanks for that.

Re:What?!

[spottedkangaroo]

If you really think this, I suggest you go back and read about x509, man in the middle attacks, and the reasons why they chose x509 for ssl.

I'm not saying there shouldn't be an alternative to x509, I'm saying that's what we have, no live with it or come up with a new certificateless protocol that doesn't have a serious man in the middle flaw.

Re:What?!

[djw]

The flaw isn't in the protocols, it's in your misuse of them.

The fundamental problem is that you need to be able to prove to someone who's never met you that you are who you say you are. There's just no way to do that, in software or in real life, without reference to some mutually trusted third party.

Say you're picking up theater tickets at will-call: they ask you to show an ID card which 1) you couldn't reasonably have made yourself (hence the third party), 2) has the same name on it that was used to buy the tickets, and 3) is verifiably tied to your physical identity via a photo. You have to provide all three of these elements in order to prove you own the tickets.

The solution you suggested originally -- having the user install your CA cert over a non-authenticated connection -- is like calling the box office before you leave the house to read them your driver's license over the phone. Two out of three elements are completely missing! What if someone else gets there before you do and says "Yeah, I'm spottedkangaroo, I called earlier"?

Re:What?!

[spottedkangaroo]

I'm not the one suggesting we misuse them. I have a signed certificate afterall. I suggested using a self-generated CA because I know that will get rid of the warning. The usual way to do it relatively securely is to fax people the complete footprint, email it to them, or otherwise describe it. It's like 15 characters, they can tell if it matches up.

All I'm saying is that if you try to do SSL without x509, you are susceptible to man in the middle attacks and you'll have no way to detect it. This is particularly true when you temporarily accept the self signed certificate each time you visit the site.

At least with the ff3 warning system you are required to store the certificate so the man in the middle attack either happens the first time and eventually the attack lapses and you'll notice the certificate change, or it happens later and you notice the certificate change.

Either way, SSL without x509 is not secure and to say it is shows a fundamental misunderstanding of the whole process. Man in the middle attacks are the chink in the armor and the flaw needed to be addressed. I'm not saying x509 is good and I really like the whole CA industry, I'm saying it's a necessary evil.

Passive eavesdropping

[tapanitarvainen]

There is a significant difference when the eavesdropper isn't targeting anyone specifically but throwing their net wide in the hope of catching something interesting. If (almost) all net traffic were routinely encrypted, it would be much harder. As it is, encryption rather marks you as an interesting target.

Equalty != Good

[rossdakin]

"It damages the basic principle of equality among web participants." When the web participants are certificate authorities, I don't *want* equality. I want one or two well established and trusted sources. If Verisign and Joe's Cert Auth had the same level of implicit trust, we would be in trouble.

What a joke.

[Slash.Poop]

Earlier comment reads as follows: "I second this complaint."
Nothing else.

The copied post is a perfect example. The person agreed with what the critics laid out but what happened? -1 Troll. What a joke. Who is modding these boards? I guess the message is, don't disagree with the TROLLS that mod these posts. Follow the mantra to the letter or be mocked.

This site is becoming a straight up joke.

Re:

[clint999]

I've successfully bought SSL certificates for companies that I had little or no verifiable connection with, from authorities that are trusted by all major browsers. Now, I obtained these with full permission of the companies in question, as a contractor, but as far as the authority was concerned, I was Joe Bloggs.

*ahem*

[Ant P.]

So which of you complainants is going to be the first to write a gnupg support patch for Firefox?

Get some perspective

[Makoss]

That makes about as much sense as saying that you shouldn't bother to wear a seatbelt, because in a subset of car accidents you will die anyway.

Nope, ssh is vulnerable.

[dacut]

ssh is vulnerable unless you set up the fingerprint of the host you're talking to beforehand.

How many times have you just ignored this warning and allowed ssh to continue?
Warning: Permanently added 'foo.bar.com,23.227.17.89' (RSA) to the list of known hosts.

If you're allowing that, it's trivial for someone to perform a man-in-the-middle attack on your connection. You have no idea if you've accepted the host's actual key or the hijacker's key.

Let the community have the vote

[cmdotter]

A few years ago I griped at mozilla about this argument (about cacert.org's lack of support in fact). I made the suggestion that 'trust' is a community thing and shouldn't be left with any one individual/company. I proposed that a browser could/should a) display a particular websites's trustworthiness (and it includes it's CA) and b) a method for a user to give a site the thumbs up or thumbs down, just like any voting scenario we have. It is an easy system to implement and it would quickly reflect on bad CA's who do not check their client's certification (if at all possible).

No, you missed the point.

[Kludge]

No, you missed the point.

The point is that encryption without certification provides really useful functionality and should not be discouraged.

Encryption with certification IS better (I am not claiming that it is not), though not perfect either. The owners of www.y0ur_bank.com can still obtain certificates, and this has happened in the past.

Re:No, you missed the point.

[Lanboy]

Yes but when you look at the little padlock it says www.y0ur_bank.com, not www.your_bank.com.

Put a notice on the http site that warns and educates your user about your bush league self signed certs.

I love FF3s Certificate handling...

[Anonymous Coward]

What's the deal I love the new method that FF3 uses, using snake-oil and self-signed certificates for quite a few things it's lovely to be presented with a box which in a few clicks can add a permanent exception for this specific certificate.

Ok perhaps if your not quite clued up on things it's confusing, but it's only there to fix the legion of morons who would click though the previous warning and go shopping on a pished site.

Firefox terribly bad UI with SSL situation

[omz]

whatever the reason the mozilla guys had, the SSL messages of Firefox 3 are the worst example of UI behaviour in the history of user interfaces.

Why? because if ( the system ) wants to notify a nearly-fatal "error" just say that:

"there is a grave issue here: blah blah blah...." and don't let the user continue

but here we just have a "self signed certified" situation. What is the no-brainer and correct ( UI science ) solution?:

say the truth, in simple words let the user choose what to do and provide a link to get more info if he want it

Example:

• i) user tries to enter a self-certified site
• ii) firefox popups a message:
  "This site is attempting to use a self signed certificate to provide encryption and authentication. Please read carefully the following alternatives and choose one:
  
  [ ] See more info about self-signed certification
  
  [ ] Cancel navegation to "https://blah.blah.com"
  
  [ ] Continue to "https://blah.blah.com"
  
  [ ] Continue to "https://blah.blah.com" and don't show this message again ( Firefox will remember blah.blah.com certificate )
  
  

And voila,, ready! The user is informed about the situation and he can decide what to do or get more info if he wants it. But if he wants to continue browsing his "dangerous" site without annoying freaking UI artifacts LET THEM DO IT!!!

Who put in Firefox team minds that they must be the SSL superheroes that should keep we ( stupid and ignorant ) users away of the SSL bad guys in the wild wild internet?

IHBT. IHL.

[danaris]

Learn to read, Anonymous Moron. His choices are 1) pay money, 2) pay money, 3) go unsupported. Your suggestion will not work for someone with a simple shared hosting account like his.

Dan Aris

Treat SSL's Two Objectives Differently

[Carcass666]

There are two different issues being tackled with SSL encryption. The first is encrypting the data packets between the browser and the server, which doesn't require a Certificate Authority. The second is confirming the identity of the site, which does require an authority that can verify the existence of the entity in question.

In the case of a self-issued certificate, it would be a lot easier if Firefox and other browser simply said, "Data between you and the server will be encrypted, but the site's identity cannot be vouched for. Sensitive data should not be submitted to this site. Do you want to continue?" as opposed hyperbole about misconfigured servers, end-of-the-world psuedo-hack warnings, etc.

You forgot a very important segment

[Lanboy]

Phishers.

If you don't see a warning for self signred certifcates I can make a ssl website identical to citibank and pound users up the ass.

Stupid stupid article.

So much wasted 'breath'

[hardwarefreak]

I bet the opinions demonstrated in the 1.759 million characters of text in this /. thread are going to convince Mozilla to change their mind and redo the code.

I can't believe that nobody mentioned startcom

[jkorz]

Startcom.org offers free ssl certs that are trusted by default with FF2 and later. You have to prove that you own the domain through an automatic process, but after that, they are just like the pay for ones (except they give an error in IE).

Free Cert Signers etc

[cnf]

http://cacert.org/

Very expensive, yes.

I am really not a fan of firefox, but this it does right. The original author did not put in a lot of research nor a lot of thought.

We seem to be forgetting somthing here...

[Mythicman]

99% of people who are on the web are NOT security experts. They're also WAY more likely to ignore subtle warnings about the identity of a site being questionable. For the average person (not the average /. subscriber) a subtle warning is completely futile in providing any security at all. The new SSL handling in FF3 is going to help....a LOT, imho.

In the overall scheme of things, which is better:

1) Having Joe User think a website is down where it isn't, which will only happen in a VERY small percentage of cases, or

2) Having Joe User provide his credit card info and SSN to a site he thinks is ok because he doesn't know any better?

One must remember that FF is no longer used only by net-savvy techie guys anymore. It has a WAY broader userbase now, and these changes are going to protect a LOT of people.

SSL without Entity Authentication is of no value.

Comment removed

[account_deleted]

Comment removed based on user account deletion

This is actually a good text.

[hummassa]

This website has given us no proof of who they really are. All secure (https) websites are encrypted to protect against eavesdropping, and the vast majority of them also provide proof of their identity. This one is encrypted, but there's no way we can ensure that they are who they say they are.

I would add:

Unless you know beyond any doubt that this website is the one you think it is, do not proceed. But if you do know, click _here_ and add an exception, so you won't see this message again.

Now, all we have to do is send the patch to mozilla... :-) Do you know if there is an already open bug?

Re:Users conditioned to click to accept everything

[BZ]

> the big problem is that Firefox hasn't imported CACert root certificate in it's trusted
> database yet.

Of course CACert hasn't asked to be imported and hasn't provided the information that would be needed to import them...

excuse me

[unity100]

if the warning sign is too prohibitive for the non geek people and if the adding exception process is too much effort (it is), it means that practically ff3 forces usage of paid certs. and if you go for a paid cert, you dont go for less recognized certs like a moron. there are 4 mainstream certs in market, comodo, rapidssl, verisign and geotrust. you cant be sure with the comodo and rapidssl recognition rates, but geotrust and verisign are the most recognized certs. and geotrust belongs to verisign.

so in theory what you say holds true. whereas in practice, it doesnt.

The Kaminsky presentation

[Antibozo]

Kaminsky's presentation from Black Hat makes it abundantly clear that still we have a long way to go in terms of DNS remediation. Until then, man-in-the-middle attacks continue to be quite easy to accomplish.