On (2014ๅนด05ๆ29ๆฅ 23:01), Mike Hoye wrote: > On 2014-05-28, 9:07 PM, Joshua Cranmer ๐ง wrote: >> >> Two more possible rationales: >> 1. The administrator is unwilling to pay for an SSL certificate and >> unaware of low-cost or free SSL certificate providers. >> 2. The administrator has philosophical beliefs about CAs, or the CA trust >> model in general, and is unwilling to participate in it. Neglecting the >> fact that encouraging click-through behavior of users can only weaken the >> trust model. > > 3. The administrator doesn't actually believe SSL certs protect you from any > real harm, and is generating a cert using the least effort possible to make > a user-facing dialog box go away. > > It's become clear in the last few months that the overwhelmingly most > frequent users of MITM attacks are state actors with privileged network > positions either obtaining or coercing keys from CAs, using attacks that the > CA model effectively endorses, using tech you can buy off the shelf. In that > light, it's not super-obvious what SSL certs protect you from apart from > some jackass sniffing the coffeeshop wifi. > > - mhoye
I am using self-signed certificate with full knowledge of pros and cons on a server of my own. (BTW, I have found it odd to call "self-signed certificate" an INVALID certificate. It is a certificate OUT OF widely known CA hierarchies, but not "INVALID" IMHO. Invalid connotates something like a reversed from and to dates, already expired valid period, revocation URL is empty, etc., but I digress.) I would like to add another possibility: 4. A clueless user/administrator: The manual of a useful tool suggests that a self-signed certificate is used (or does not mention explicitly to use non-self-signed certification in a clear manner.) Case in point: ownCloud 5 ownCloud is a very useful open-source version of "do it yourself" Dropbox replacement (well almost). You can configure your own server to act like a Dropbox look-alike. I have been using it for a few months and it is very useful (basically there is no space limit, and free as in free lunch aside from the fee for network connection, PC maintenance, and electric power.) Now, ownCloud server runs as a PHP script that is invoked by web server: in my case, apache. For https: access, it needs SSL certificate, and in my case, I chose the default installation which leads to the use of default certificate (self-signed certificate.) I mentioned the possibility 4 above, because ownCloud version 5 manual never mentioned the demerit or anything of self-signed certificate. It makes sense. If a user stores his/her data in a server operated by an operator of an ownCloud service, then trusting that certificate (self-signed) from the operator is no brainer. Surely the first time you access the server, you are warned by the browser (and ownCloud sync client), but after checking finger printing, etc., you can accept it and everything should be OK. [Now, if the self-signed certificate is signed with a key that is leaked to government snoops is another story, but again it is up to the user to decide how much trusts the operator of ownCloud has. He/she may layer the local encryption before the file is stored on a remote server.] Again, if SSL is used only for end-to-end encryption among (ALREADY) trusting parties that do not share a common key in advance, self-certified cert for SSL is OK. When I checked how to use SSL certificate for Apache under Debian, documents from Debian GNU/Linux are rather scant on the philosophical issues of self-certs. The following is what I checked early during setup of ownCloud server. --- quote from my local copy of /usr/share/doc/ssl-cert/README This is a quicky package to enable unattended installs of software that need to create ssl certificates. Basically, it's just a wrapper for openssl req that feeds it the correct user variables to create self-signed certificates. --- end quote Debian Wiki: https://wiki.debian.org/Self-Signed_Certificate does not mention any demerit at this level. It explains the proper openssl command line to produce a self-signed cert. (Maybe the pages in the higher level may discuss the pros and cons of self-certs vs certs signed by widely known CA. But google search finds the above on the first page.) So I suppose someone, who was interested in ownCloud and uses Debian GNU/Linux, never had bothered to setup Apache for services that would require https:, and unfamiliar with cryptography may opt to use the defaults suggested by these packages and documentation, and ends up with self-cert by following the commands and instructions. To clear the name of ownCloud developer community, I hasten to add that ownCloud version 6 (six) manual (released in the last month or so) clearly mentioned the demerit of self-signed cert and a way to obtain a free ssl certificate. --- begin quote Apache Configuration Enabling SSL An Apache installed under Ubuntu comes already set-up with a simple self-signed certificate. All you have to do is to enable the ssl module and the according site. Open a terminal and run: sudo a2enmod ssl sudo a2ensite default-ssl sudo service apache2 reload If you are using a different distribution, check their documentation on how to enable SSL. Self-signed certificates have their drawbacks - especially when you plan to make your ownCloud server publicly accessible. You might want to consider getting a certificate signed by an official signing authority. SSLShopper for example has an article on your options for free SSL certificates. --- end quote I think there is no philosophical problem of using self-cert for small scale user community, but of course, if one is in a position to release a product that is used by millions of people in a day or two, the support cost of answering "What is this warning I get about the certificate (?) when I try to access https://xxx.yyy.zzz site?" may become certainly a burden. But the support cost is something that is NOT directly related to self-cert. Like some posters mentioned it is up to the service operator's manual to clearly state the issues that occur when you first access the service by modern browsers, and tools. Just a thought. PS: It used to be that https://www.gnu.org/, a widely visited site, used self-cert. (Or maybe https://savannah.gnu.org/ ) But come to think of it, I don't think I have seen certificate warning anymore. Using page info -> security, I now learned "GANDI SAS" is the publisher of cert to *.gnu.org. Maybe the amount "What does this warning mean?" forced them to abandon self-cert. I think the cons for self-cert is more on the support cost of educating users of browsers. I don't believe there is any fundamental problem of using self-cert for services. If people have blind faith in a CA in the hierarchies of CA's, then to be honest, I think self-cert is no worse or no better. Ask the users of Danish CA, DigiNotar, which had a big problem. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
