Slashdot Mirror

The main issues as the moment is that getting a certificate is complicated, expensive and then dealing with setups is not always straightforward. Now, that is just for a basic Apache server. Create scenarios where you have load balancers, Apache servers serving multiple domain names and applications servers fronted by Apache and you have another set of problems.

Which could all be mitigiated.
- Free CA (like CACert or StartCom)
- Server Name Indication (serving several virtual domains, each with its own certificate, but all mapping to the same IPv4 address)
- IPv6 (enabling you to assign 1 different address for each virtual domain)
etc.

But that would require work. Lots of it. And rethinking the infrastructure and reorganising it in a way that actually works better and is more forward upgradeable.

So yeah, expect HTTP to day in the 20s...
2120s...

Are you new to CAcert?

CAcert.org is a community-driven Certificate Authority that issues certificates to the public at large for free.

CAcert's goal is to promote awareness and education on computer security through the use of encryption, specifically by providing cryptographic certificates. These certificates can be used to digitally sign and encrypt email, authenticate and authorize users connecting to websites and secure data transmission over the internet. Any application that supports the Secure Socket Layer Protocol (SSL or TLS) can make use of certificates signed by CAcert, as can any application that uses X.509 certificates, e.g. for encryption or code signing and document signatures.

If you want to have free certificates issued to you, join the CAcert Community .

If you want to use certificates issued by CAcert, read the CAcert Root Distribution License .This license applies to using the CAcert root keys .

Two words: network effect. {...} I installed an XMPP daemon on a home server and made it as easy as I could to get everyone going.

Baby steps. Having them use an existing facility like XMPP interface to GoogleTalk/Google+Hangouts, or the XMPP interface into Facebook would have been a smaller jump, or the SIP provider to their home telephony (if they use a combined "Internet + IPTV + VoIP" package).
(Though some would have complained that facebook sticker don't work currently over XMPP)

Then start handling separately the cryptographic issue.
(Once everyone is used to have Adium on their Mac to chat with Google Talk and Facebook contacts, its easier to "just turn on" crypto).

"If this is so secure, what's this certificate warning about?"

Oh, common. Do some effort on your side. It's not that difficult to use a free CA like CACert.org.
It's even a recognized certificate in some browsers.

"Why do I have to do this?"
"What's wrong with Skype?"
"Oh, you're so paranoid!"

Big thanks to Snowden for making this a tiny bit more obvious to the avrage sheeple.

Until it "just works", nothing is going to change.

In their defense, Jitsi (the only client with OTR and ZRTP, as far as I know) is pretty buggy.

Yup, we need more efforts to have a wider choice of crypto-enabled clients.
Adium and Pidgin are nice alternative (but only support OTR, and only support Skype through some extra 3rd party plugin).
Tor is working into adding Instant Bird (XUL powered) with OTR to their bundle.

You clearly don't do CACert assurance :-p

If your house were to burn down this evening, your bank accounts emptied, and someone hacked the IRS, state, and local government records to show that you have not paid your taxes, how would you prove otherwise?

Or Wikipedia could join CACert.org.

Third link on the top right of the cacert website.

Apologies, but it's a PEM file named .crt (this is correct, i'm just braindead)

http://www.cacert.org/

Or just issue self-signed certificates, and tell your users to verify the fingerprint manually.

It all comes down to weather or not the browser accepts it, and for now it looks like CaCERT is not valided yet. I tried https://www.cacert.org/ and Chrome shows that nice fancy red screen that tells me I am about to do something extremely dangerous, although if you read it it only tells me that they can't validate the owner, encryption is all fine .. .I wish they would make that more clear.

Startssl.com is recognized by all major browsers, checks your identity by a mail and phone callback, and issues as many "simple" certificates as you need. "Simple" meaning no wildcard, and no subject-alt-name. These are valid for one year

If you do need more advanced stuff (wildcard, subject-alt-name), you can have StartSSL do a more "thorough" id check. For this, upload a scan of two government-issued id documents, and send them $49.90 . They'll perform another phone check, and you're ready for "Class 2" certificates, which are valid for two years. You can still get as many as you want during validity of your id check (1 year).

You can't get cheaper than that (except for CaCert, but unfortunately CaCert is not recognized by the browsers by default).

I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't pushing for a free model for certification which cuts the CAs out of the loop, at least for some kinds of certs.

Indeed. Especially since there is a free CA around: CaCERT.

Yes, they failed an audit. But the only reason why they failed it was that they were doing it honestly. Many other CAs which are currently accepted in Firefox would fail the same kind of audit, but they are smart enough not to submit to one.

Other than inertia, is there any reason to give these guys a second chance

You mean, a third chance?

Yes, they are too big to fail. Hey, it worked for the banks...

Maybe CaCert only needs to get 120.000 subscribers on board, and they shouldn't have to bother with that pesky audit either?

1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

For the very same reason some resellers of this pitiful excuse for a CA deliver certificates to you before you've even scanned a single document proving you're authorized to ask for it (yes, seriously): Because it would be Bad For Business[tm]. People want to start their damn online shops Real Quick, and people who make these shops don't want to irk the customer by asking for lots of papers and delaying the setup. Like always, business efficiency and security do not mix well.

2. Why exactly do we still trust Comodo as a CA, when the like of cacert.org cannot meet the "requirements" to be added as a CA in Mozilla products?

According to CAcert, we (or rather, the browser vendors) trust anybody who passes an expensive audit by those guys. The CAs are just like registrars, they've a big incentive to sell as much certificates as they can, they can have resellers even more hungry for business, and everything goes naturally downhill from there. Here's an alternative idea: IRL, who does certify your identity (or that of your business) and has pockets deep enough to handle any liability lawsuit if they made a mistake? Right: Your government. Hence, they're in the best position to know if you can legitimately ask for a certificate in the name of ACME Corp. Let certificate issuing be a public service, then. Personal certificates are already being embedded in some ID cards (IIRC, Belgium provides something like this). Why not getting an account to generate SSL server certs tagged with your identity along with your passport (or the identity of your business along with your certificate of incorporation)? I know I would trust such certificates much more than those issued by a random corporation on the basis of (at best) crappy scans or facsimiles that could as well have been photoshopped in the first place.

As for certificates that are just domain validated and do not embed any identity in addition to the CN, browser vendors should (1) relax the audit procedures so there can be people providing those certificates for a negligible sum (or even for free, at least one real CA already does it) so people can easily encrypt their communications without revealing their identity, and (2) find a conspicuous way to inform the user about the real assurances provided by a certificate. Sorry, but it is now painfully obvious that the nice closed lock in the address bar means absolutely nothing, and I very much doubt most people are paying attention to those blue and green bars after years of having been told to "look at the lock and the HTTPS URL".

My .2 €

1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

2. Why exactly do we still trust Comodo as a CA, when the like of cacert.org cannot meet the "requirements" to be added as a CA in Mozilla products?

There is http://www.cacert.org/ but they are still working to have their root certificate included in Firefox

http://www.cacert.org/ doesn't seem to have any problems with that.

Suuure, they aren't in your browser by default (for some reason. Come on, Mozilla...) but that's easy enough to fix.

Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.

Then I suggest you add the self-signed certificate to their computer, something like this.

There is a free certificate authority: http://www.cacert.org/ . Unfortunately, it's not "official", but the root certificate is installed by default on a lot of free systems. (see ca-certificates package in Debian) I'm sure slashdot users are techy enough to understand it.

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

You can do that just as soon as CACert's free certificates are recognized by the major browsers by default.

Totally agree with this. If I dont want to spend money paying a certification authority I should be able to encrypt anyway without the browser warning the user in big red letters that I am a pirate. Firefox warnings are geting worse in each version and, for the user perspective, it seems that encrypting with a non official certificate is much worse than not encrypting at all. By the way I use cacert to generate my certificates; it should be inlcuded in the default Firefox certification authorities list. I suspect there is money involved in getting into that list though.

How about community driven efforts such as cacert.org? Requires the receiver to import their root certificate, though.

There are "open" CAs out there, the one that I know of is CAcert.org and they are currently trying to get into more browsers/OSs etc. This CA provides signed certs at no cost. http://wiki.cacert.org/wiki/InclusionStatus The way to solve this issue is the same way that we approach the closed-source/proprietary software issue; a free, open, community alternative.

The first problem has already been solved in SSL's successor, TLS. The "Server Name Indication"[1] extension of TLS allows the client to transmit the desired virtual host before the encryption begins. The current versions of most major browsers support this, including: Firefox 2.0 and later, Opera 8 and later, IE7 and later, Chrome, Safari 3.2.1 and later.
Apache, Cherokee, Lighttpd and nginx support SNI on the server side.

Your second problem is not as easy to solve. You could consider CACert[2], a certificate authority based on a web of trust. When I applied for CACert, the assurers were quite serious and checked my identity (ID card, photo and signature) more thoroughly than some ISPs who are reselling commercial certificates. No major browser ships with the CACert root cert but fortunately it's very easy to install!

[1] http://en.wikipedia.org/wiki/Server_Name_Indication
[2] http://www.cacert.org/

I installed CACert on my iPod touch just a few weeks back (2.2.1), and I know that the functionality is on the iPhone too.

I just visited this page in MobileSafari and touched the link for Root Certificate (can't remember which format worked though). Safari is replaced by a certificate review page with the option to install the cert.

Once it's installed, I can verify that it works and that it is removable via the Settings app.

However, IF ssl established encryption, then virtual host, then authenticity (to varying degrees of confidence as configured by the user's trust settings), https wouldn't require a seperate IP per virtual host anymore.

It doesn't. There are several approaches to the problem:

• subjectAltNames and wildcard certificates. Nowadays, certificates can carry multiple site names. Just make a certificate containing all site names (not supported by all CA's, but Entrust and CaCert do)
• SNI (Server Name Indication). This allows the webserver to use a different certificate for different virtual hosts. Soon to be supported by mod_ssl, but already supported (for several years) by mod_gnutls

• . Most clients (browsers) today support it out of the box, only Konqueror seems to be lagging behind, alas!

There are cases (such as a private lan to an internal server) where authentication (particularly CLIENT authentication) w/o encryption may be reasonable.

Client is almost never authenticated via SSL anyways. You're right about the private LAN. Easyest LAN-based attacks are passive eavesdropping, rather than active Mitm. But in most other cases, encryption without authentication of the peer just doesn't make sense. But in a private LAN, you're probably in a position of setting up your own CA anyways, as basically you control your browser's CA lists.

If I am contacting https://argleblargle.nu/ for the first time, I don't have any Idea who that is even if they are authenticated.

But you do know that it's argleblargle.nu, rather than somebody who managed to poison DNS or hijack your router.

What about simply creating a better web of trust?

Congratulations!

You Sir have just re-invented CaCert. CaCert is a certification authority which operates by a web-of-trust model: users certify each other after seeing id, and only users having gathered a minimum amount of assurance points can get a certificate.

Unfortunately, CaCert is not trusted by the browsers (such as Mozilla or Konqueror), who seem to be more hung up about expensive audits and pompous root key signing ceremonies.

Other CA's, such as Comodo/CertStar or RapidSSL/GeoTrust don't seem to have any problems being blessed by browsers though. Thanks to these fly-by-nighters it's still very easy to mount an Mitm attack using your open Wifi honeypot, which will be undetectable, unlike this poser here.

After reading this article, I think that RapidSSL/FreeSSL should stop issuing certificates altogether.

Indeed. This MD5 issue is not the only problem that RapidSSL has. Their biggest issue is that they don't do any effort whatsoever to verify the requestor's identity. All the requestor has to do is:

1. Supply a phone number under which he can be reached
2. Prove that he can read e-mail sent to the domain to which he wants a certificate

The phone number is not verified, and using the number of a pre-paid mobile plan (or a callable phone booth) will work just fine.

Two may be a little bit tougher, until you think against what a certificate is supposed to protect: man-in-the-middle attacks.

So if the perp can get close enough to his target to mount a man-in-the-middle attack, he can also intercept mails sent to that target. Or, if the target is a webmail provider (hotmail, ...), he only needs to create one account out of the many allowed on the service.

Contrast this with other certification authorities, such as CA-Cert, which require a face-to-face verification with at least two volunteers which are trained and can be held responsible for errors.

Granted, domain ownership verification is not any more stringent than with RapidSSL (except for a smaller list of possible admin adresses), but at least in case of fraud, CaCert will have a chain of assurers leading to the perp in case of fraud, whereas RapidSSL would only have the number of a phone booth in a shady neighborhood.

Now, guess who is trusted by most browsers?

Yes, RapidSSL is, while CaCert isn't.

After reading this article, I think that RapidSSL/FreeSSL should stop issuing certificates altogether.

Indeed. This MD5 issue is not the only problem that RapidSSL has. Their biggest issue is that they don't do any effort whatsoever to verify the requestor's identity. All the requestor has to do is:

1. Supply a phone number under which he can be reached
2. Prove that he can read e-mail sent to the domain to which he wants a certificate

The phone number is not verified, and using the number of a pre-paid mobile plan (or a callable phone booth) will work just fine.

Two may be a little bit tougher, until you think against what a certificate is supposed to protect: man-in-the-middle attacks.

So if the perp can get close enough to his target to mount a man-in-the-middle attack, he can also intercept mails sent to that target. Or, if the target is a webmail provider (hotmail, ...), he only needs to create one account out of the many allowed on the service.

Contrast this with other certification authorities, such as CA-Cert, which require a face-to-face verification with at least two volunteers which are trained and can be held responsible for errors.

Granted, domain ownership verification is not any more stringent than with RapidSSL (except for a smaller list of possible admin adresses), but at least in case of fraud, CaCert will have a chain of assurers leading to the perp in case of fraud, whereas RapidSSL would only have the number of a phone booth in a shady neighborhood.

Now, guess who is trusted by most browsers?

Yes, RapidSSL is, while CaCert isn't.

After reading this article, I think that RapidSSL/FreeSSL should stop issuing certificates altogether.

Indeed. This MD5 issue is not the only problem that RapidSSL has. Their biggest issue is that they don't do any effort whatsoever to verify the requestor's identity. All the requestor has to do is:

1. Supply a phone number under which he can be reached
2. Prove that he can read e-mail sent to the domain to which he wants a certificate

The phone number is not verified, and using the number of a pre-paid mobile plan (or a callable phone booth) will work just fine.

Two may be a little bit tougher, until you think against what a certificate is supposed to protect: man-in-the-middle attacks.

So if the perp can get close enough to his target to mount a man-in-the-middle attack, he can also intercept mails sent to that target. Or, if the target is a webmail provider (hotmail, ...), he only needs to create one account out of the many allowed on the service.

Contrast this with other certification authorities, such as CA-Cert, which require a face-to-face verification with at least two volunteers which are trained and can be held responsible for errors.

Granted, domain ownership verification is not any more stringent than with RapidSSL (except for a smaller list of possible admin adresses), but at least in case of fraud, CaCert will have a chain of assurers leading to the perp in case of fraud, whereas RapidSSL would only have the number of a phone booth in a shady neighborhood.

Now, guess who is trusted by most browsers?

Yes, RapidSSL is, while CaCert isn't.

Like this one?

Their root certificate needs to be installed first though.

Well, there's CAcert, but they are not listed as a trusted CA in any browser. StartSSL, which is a commercial company, issues certificates for free and they are trusted by Mozilla browsers currently. But as far as I know, if you want a cert that's trusted by default in all modern browsers, you'll need to pay a few bucks.

A certificate-based login (which you can play with at www.cacert.org) would solve this problem. When you initially set it up with your bank, they should require gobs of information proving your identity (full card number, CCV, address, social security number, and last ATM transaction data should suffice), and then they'll let you generate a key for your browser. This easily qualifies as "something you have" for two-factor authentication without needing anything silly like a USB key that would cost the bank money on a per-key basis in time and resources. (Footnote: This isn't as well documented as it should be; your best bet is to play with cacert.org's free implementation. There's tidbits of it in Wikipedia's TLS article, and cacert's wiki has a decent Client Certs page that says a little more.)

After that, you'll need that key plus the tools already employed. Most banks these days already have interesting ways to prove their own identity to you (they supply you with an image and some secret text you agreed upon earlier), then they have some clever input mechanism that tries to bypass keyloggers and javascript hacks.

Also recall that banks are VERY good about locking your account; a properly protected four-digit number is actually secure enough if you're only allowed two failed logins per day (regardless of source) since the code would take up to 5000 days (13+ years) to crack, and I'm sure there are further safeguards for that kind of case.

To banking software firms: I would immediately switch* to an online bank that performs this configuration. So would others. Don't forget: people like me are consulted regularly by family and social networks for advice about this very topic. (* Assuming the bank is FDIC/NCUA-insured, otherwise well-received and regarded, and fully pays for a few ATM usage fees each month).

If you want to access a website that uses a SSL certificate signed by CAcert, you might get an SSL warning. We are sorry, but currently that's still 'normal' as mainstream browsers don't automatically include the CAcert Root Certificate yet. -- http://wiki.cacert.org/wiki/BrowserClients

Ouch!

Whatever happened to CA Cert and their push to get included in Firefox? They were supposed to be the FOSS solution to the whole certificate problem, yet years have gone by with them being no closer to being included as a CA in major browsers.

Fundamentally, the people at fault here are the so-called professionals who allow their certificates to expire. Why should I trust their site's security if they can't manage a simple administration function like that. Thawte and Verisign provide you with enough reminders that your certs are about to expire, so you don't even need to diarise it yourself.
I do have more sympathy with self-signed certificates.There is no excuse for corporates to be using them, but for small, non-profit sites, self-signed is understandable. Mozilla could help this situation by providing support for CACert and similar organisations, by including their signing certs in their browsers, by default.

The problem is that so few people are set up to read encrypted email, that it isn't useful in day to day work.

Wrong. Anyone who uses Microsoft Outlook or Mozilla Thunderbird is more than set up to read encrypted email. Personally I use Claws Mail, but using something that's not made by an über-corp certainly isn't a step people need to take.

If you want to give up your personal information, you can go to Thawte and start sending signed emails right away, which will enable anyone with Outlook or Thunderbird to begin encrypting emails to you. Some people may find cacert an option, but all-in-all if I needed to ask my friends to install a CA, I figured I'd just roll my own.

You might find these commands handy if you were so-inclined to set up your own personal CA for friends and family to whom you can give the CA in person (and to whom you're probably communicating personal information you want to keep private):

Generate a self-signed CA:
openssl req -x509 -newkey rsa:2048 -days 3650 -keyout ca.key -out ca.crt

Generate a key:
openssl genrsa -out client.key 2048

Generate a CSR:
openssl req -new -key client.key -out client.csr

Generate a certificate from the CSR with the CA:
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
-days 3650 -out client.crt

Generate a PKCS12 key from the key and certificate:
openssl pkcs12 -export -in client.crt -inkey client.key -certfile ca.crt \
-name "client" -out client.p12

While it's too bad that PGP didn't catch on at all (no money in it for big CAs I guess), it's not correct to say that most people are not set up to read encrypted email. Your point about unencrypted email being a postcard is absolutely correct, though. It's a shame, however, that people think that encryption is difficult. It's not difficult; it's just that ISPs don't install a personal key and turn on encryption for you when they set up your hardware.

(Personally, I wouldn't want to use a 3rd-party issued key anyway.)

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.

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?

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.

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.

<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

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.

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.

Actually you can only get a certificate from CACert if you've been assured with enough points, and that's only supposed to happen after in-person ID verification by multiple members.

In other words, a key signing party. As I understand it, those are practical for people who routinely travel between large cities, but that has become more difficult with the quadrupling in fuel prices in the past four years. Worse, key signing party coordination web site Biglumber.com appears to be down (Network Timeout). So other than through key signing parties, how can I meet multiple members within reasonable bicycling distance of my home? Or should I just go the notary route?

Or even better, go here, since the above address is an https and Firefox won't accept its self-signed certificate..

It isn't *included*, but it's definitely *supported*. Just go here with Firefox to install their root cert.

Seconded. go here.

1. Click "Or you can add an exception..."
2. Click "Add Exception..."
3. Click "Get Certificate".
4. Click "View...".
5. Compare the fingerprints.
6. Click "Close".
7. Click "Confirm Security Exception".

http://www.cacert.org/
Discussed on /. http://slashdot.org/yro/04/07/02/0116236.shtml?tid=126&tid=158&tid=172&tid=95&tid=99

Remember the story not too long ago about a XSS vulnerability that essentially let you display your own content on an EV certified SSL page? Even a $500+ certificate can't protect against buggy sites. One of the bigger annoyances with firefox 3 is what happens when you go to a site with a certificate that is not valid (self-signed, untrusted CA, expired, etc). You see a page styled similar to the server not found messages. You then have to click on like 4 things with one of them saying that its really bad to do this, etc before you can continue. The time where "valid" certificates I'd encourage are for sites that do payments in some way. Imagine if your bank was suddenly using a self signed cert for login? I've used http://cacert.org/ for years now for the various admin sections of sites. Browsers still don't recognize it as a real ca but adding them is trivial and they are listed in the latest editions of most Linux distros. Its nice not having to add exceptions for all these certs, but can't make self signed ones that last 10 years either