| |||||||||||
Firefox security statusFirefox security statusPosted Jun 7, 2007 10:59 UTC (Thu) by ekj (guest, #1524)Parent article: Firefox security status
The Mozilla-mechanism is unsane though. Requiring updates to be served from SSL-sites has numerous drawbacks, for example it requires you to have a server on a separate IP-adress, which costs extra for many using shared hosting. And it requires you to purchase an SSL-certificate, which is also extra hassle for no benefit whatsoever. There exists a well-tested, secure, easily implementable, no-server-impact solution for installing updates, while being certain that they come from who they claim to come from. It's called a digital signature. Package-managers have had them for years. Sign packages, ask on first installation of a module if you also want the issuer for providing updates, if yes, auto-install updates, but only if they have a good signature from the same developer. This also allows you to get the updates packages from anywhere, so it allows mirroring of plugin-update-sites without sacrificing security, something that is NOT possible with the "use only HTTPS" solution.
(Log in to post comments)
Firefox security status Posted Jun 7, 2007 11:43 UTC (Thu) by hawk (subscriber, #3195) [Link] The problem that is "solved" with a certificate handed out from a trusted authority is obviously proving who the software came from in the first place. (So I wouldn't say that the hassle of buying a certificate is for no benefit!)
I do however agree that having this security on the HTTP layer is not really the right choice. On the other hand, having the extensions signed with a certificate handed out by a trusted party seems like a good idea to me.
What you describe (as your description does not seem to involve getting such a certificate) will only be able to tell whether updates come from the same source that you got the initial version from, which still leaves a big whole.
On the other hand, how do you know who to trust in the first place anyway....
Firefox security status Posted Jun 8, 2007 21:54 UTC (Fri) by ekj (guest, #1524) [Link] Sure, a certificate signed by one of the CAs that say Firefox trusts by default indicates *something*. Nothing that is useful for deciding if you trust software delivered from that host though. A Verisign-signed certificate for "foobar.org" shows that Verisign is convinced that the person who they at one time sent the certificate too is the same entity that owns foobar.org. This helps very nearly not at all.
Firefox security status Posted Jun 7, 2007 15:48 UTC (Thu) by erwbgy (subscriber, #4104) [Link] Requiring updates to be served from SSL-sites has numerous drawbacks, for example it requires you to have a server on a separate IP-adress, which costs extra for many using shared hosting. I agree that signing updates is a better approach, but it is not necessary to have a separate IP to run both an SSL and non-SSL web server on the same host, since they can (and usually do) use different ports - 80 for HTTP and 443 for HTTPS by default. Using Apache IP-based virtual hosts you can even have both in the same instance.
Firefox security status Posted Jun 7, 2007 18:18 UTC (Thu) by Thalience (subscriber, #4217) [Link] The issue is that each IP address can host only one SSL site. IP(v4) addresses are a scarce resource, and hosting providers naturally pass the costs associated with this along to their customers.
Not that this is an issue for Google, of course.
Firefox security status Posted Jun 7, 2007 19:49 UTC (Thu) by Los__D (subscriber, #15263) [Link] Not true anymore.
The problem originally was that the certificate needs to be served before the headers can be decoded.
If you use the same certificate for all sites (now possible by having them all mentioned in the certificate using subjectAltName), there's no problem.
Firefox security status Posted Jun 8, 2007 18:11 UTC (Fri) by jengelh (subscriber, #33263) [Link] Do it the Sourceforge way. One certificate for "sourceforge.net"/www.sourceforge.net, and one for "*.sourceforge.net" that works for all the user projects.
Firefox security status Posted Jun 8, 2007 21:19 UTC (Fri) by Los__D (subscriber, #15263) [Link] I can't see how that would work with one IP/virtual hosts?
Before knowing which certificate to show, it'll need to know the hostname, before it can get to the hostname, it needs to decrypt, before it can decrypt, it needs to show a certificate, before knowing which certificate to show, it... And so on, and so forth...
Firefox security status Posted Jun 8, 2007 21:32 UTC (Fri) by jengelh (subscriber, #33263) [Link] The ten or so web servers that serve the projects' pages (http://yourproject.sf.net/) all serve exactly one certificate, which certifies "*.sourceforge.net" (yes, this literal string with an asterisk, w/o quotes). Most browsers support this wildcard.(Minus the fact that project pages are not reachable over https right now...)
Firefox security status Posted Jun 8, 2007 21:40 UTC (Fri) by Los__D (subscriber, #15263) [Link] Of course, but you'd still need a seperate IP for the www.sf.net cert(and another for www.sourceforge.net and *.sourceforge.net), if you didn't use subjectAltName
Firefox security status Posted Jun 8, 2007 21:56 UTC (Fri) by jengelh (subscriber, #33263) [Link] I never claimed projects.sf.net is the same as www.sf.net. You would have found out by running /usr/bin/host anyway.
Firefox security status Posted Jun 8, 2007 22:02 UTC (Fri) by Los__D (subscriber, #15263) [Link] We were discussing if one will need more than one IP for several hosts, I thought that your www.sf.net/*.sf.net suggestion was about using one IP, also for www.sf.net.
I was obviously mistaken.
|
|||||||||||