[Pidgin] #15280: Upgrade webserver for pidgin.im and consistent ssl support?

[Pidgin]

#15280: Upgrade webserver for pidgin.im and consistent ssl support?
----------------------+-----------------------------------------------------
 Reporter:  ioerror   |        Owner:  datallah
     Type:  task      |       Status:  new     
Milestone:            |    Component:  trac    
  Version:            |   Resolution:          
 Keywords:  sysadmin  |  
----------------------+-----------------------------------------------------

Comment(by ioerror):

 Replying to [comment:6 kstange]:
 > The problem with doing this is for each hostname we have, it requires a
 separate certificate or a wildcard certificate, and possibly multiple IPs.
 SSL certificates cost money

 I'm familiar with the problem. StartSSL offers free SSL certificates -
 this may be of interest to you:
 https://github.com/ioerror/duraconf/blob/master/startssl/README.markdown

 >, and we are a non-profit with no wish to spend money where it is not
 needed.

 It is absolutely needed. There is absolutely no way to securely install
 pidgin. Combined with the lack of a secure way to fetch (#14565) GPG
 signatures, which are free, I think users are unable to safely bootstrap.

 > We also have pidgin.im and developer.pidgin.im on different hosts,
 there's no SSL configured at all on the former.

 Two certificates isn't really impossible. I mean if the free SSL certs
 above, which work in all major browsers, aren't good - hold a fund raiser.
 I'll gladly kick in some cash if you have such a fund raising. I know a
 lot of pidgin users would as well.

 >
 > I am in favor of protecting trac generally and I think the consensus is
 that we will do this when we upgrade our server, which we hope to do soon,
 but I don't think protecting pidgin.im really gains much.

 What's blocking that? It sounds like a fund raiser is really in order
 here. Protecting pidgin.im is important as it prevents attackers from
 spiking your downloads. You could easily set HSTS (in the Chrome preload,
 HTTPS-Everywhere) and really ensure people only get Pidgin and related
 components over HTTPS.

 >SSL-enabled servers are easier to overload due to the higher resource
 requirements of an SSL transaction and pidgin does not have a very
 powerful infrastructure, given it's entirely provided by donation.

 This is pretty much not true anymore. Adam Langley has written about the
 real costs of SSL/TLS and I think it's not reasonable to just rule it out
 without some numbers:
 http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

 I mean, sure, if someone attacks you, you're in trouble. I think that is
 the case anyway though - have you tested your servers for issues lately?
 Does ''timber.py'' still work?

 > SSL is good, but I don't think HTTPS-Everywhere is reasonable or even
 helpful.

 The EFF plugin? Or on your sites?

 > SSL where you submit data is a good practice, but when your data has no
 security implications, what does it matter?  What does it matter if
 someone MITM's someone submitting an open source patch to our publicly
 visible tracker?
 >

 Well, for one, it means they could tamper with the patch. I mean, there
 are other examples. What does it matter? It matters because it means that
 alice knows that she is talking with bob and bob can reasonably guess that
 it is alice, as she has authenticated, etc.

 > I'm being overly simplistic.  We certainly care if someone has managed a
 man in the middle attack in front of our server, but it isn't a
 universally harmful situation and not everything needs to be encrypted.
 >

 When only special things are encrypted, forgotten or overlooked special
 things are not.

 > If you are indeed just looking for trac to no longer redirect to HTTP,
 that is something we'll look to resolve, but I don't think the rest is
 critical.

 That would be nice as I have to disable HTTPS-Everywhere to use your bug
 tracker.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/15280#comment:7>
Pidgin <http://pidgin.im>
Pidgin