Setting fix version to next release.

This has been enabled on beta.musicbrainz.org, if it doesn't cause any problems there it should be enabled on production during the release.

I don't know why this is marked as in review, but it's not, so I'm pulling it out

This is in review, but there is no open review. Status update please!

http://codereview.musicbrainz.org/r/2450/

TODO on this ticket:

force SSL for login and registration.

SSL is now available on production. There's at least one issue still, in that https://www.musicbrainz.org (in some situations) will redirect to non-SSL (http://codereview.musicbrainz.org/r/2395/) but the certificate is deployed and ready! SSL Labs test: https://www.ssllabs.com/ssltest/analyze.html?d=musicbrainz.org

The window for shipping this to beta testing has closed, so this will have to wait for the next release.

Sadly there's a little more to do until we can ship this, so I'm pushing it to the next version.

https://www.ssllabs.com/ssltest/analyze.html?d=test.musicbrainz.org is the test page; the BEAST warning has to do with the fact we have a CBC ciphersuite listed first – and browsers have good workarounds for BEAST anyway. So, this is looking pretty good!

(testing: logging in using SSL and then going back to non-SSL does work as it should)

Note to all: test.musicbrainz.org is now running with a non-self-signed cert; MBS-5301 is in review to make gravatars get loaded over SSL, wikidocs are trying to load over SSL but that won't work until MBH-281 is done (yes, yes, I'm working on it...). No bugs opened yet for coverart, which we'll need to switch to use SSL where we can. Other thing we'll need to do is (probably) force SSL for login, and make sure that SSL logins/cookies/etc. still work on non-SSL.

I've purchased the cert and we're pretty much ready to go once we're happy with test/beta. What else do I need to do?

The due date of this ticket is 11/Sep/12. This won't make the next release (2012-09-17) because we're in freeze, so the earliest this can make it is (2012-10-01). I've assigned to Rob to make sure that we get this done!

> TL;DR. Get an 8 to 15 dollar per year standard SSL certificate for musicbrainz.org first, worry about anything else after we've implemented that successfully.

I don't mean to spam here, but I think it's worth considering StartSSL (www.startssl.com).

They offer free 1-year domain-validated certificates, covering the main domain and one subdomain of your choice (e.g. musicbrainz.org and foo.musicbrainz.org); no strings attached – free renewals allowed, too. I think you can get multiple of these to cover all subdomains, although maintenance would be a PITA.

They also wildcard certificates at reasonable prices, $60 for personal validation (e.g. registrant's personal name will be published in the certificate) and $60+60 for organization; these certificates are good for 2 years.

More details: https://www.startssl.com/?app=40

Some of us would have liked to go for https:// all the time, but that will likely break a bunch of stuff (including userscripts). So we must ship with both https:// and http:// working.

Discussion here: http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-08/2012-08-16.html#T09-56-08-127412

Now we need to use scheme relative links to get the site to work. https support is now available for test.mb.org (self signed) and will soon be available for musicbrainz.org (proper cert)

We've purchased a two year certificate and I've turned this certificate over to djce. He's playing with setting up nginx as we speak.

If you're looking at EV certs, Verisign is rediculously expensive - something like $1200 US per cert. However, Steve Gibson has recommended DigiCert; he's had good luck there, and they're far cheaper. http://www.digicert.com/ev-ssl-certification.htm $469 for 2 years for one domain, or $779 for 2 years for three domains. (I think MB would only need the one domain). (Ref http://www.grc.com/sn/sn-359.htm ; search "And this is DigiCert once again.").

I think that ultimately we should get an EV cert if we think it's affordable enough – but starting with a basic one, for mb.org only, would be acceptable IMO for this ticket.

TL;DR. Get an 8 to 15 dollar per year standard SSL certificate for musicbrainz.org first, worry about anything else after we've implemented that successfully.

More detailed:

Ian is correct in saying that a *.musicbrainz.org certificate cannot be used for musicbrainz.org itself. So we always need at least two or more separate certificates or a certificate with multiple names (subjectAltNames).

subjectAltName is supported by all browsers I believe, but may not be supported in all client libraries – so this could be a problem for webservice clients which need to do authentication (considering we don't have oauth yet). For example, the wget in Ubuntu still has issues with it (I haven't tested this myself, the bug report is here: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/733888).

I would prefer a wildcard certificate over a certificate with subjectAltNames for that reason, and it also gives us a lot more flexibility when deploying stuff on new subdomains.

I think we should just start with a standard musicbrainz.org certificate (EUR 12/year at gandi). A wildcard or subjectAltName certificate is usually far more expensive (wildcard at gandi is EUR 120/year, subjectAltName starts at EUR 265/year it seems). Once we have musicbrainz.org implemented on a standard ssl certificate, we can worry about what to do with the subdomains and which certificates we need for it.

To get a better idea for US-based prices, have a look at https://www.namecheap.com/ssl-certificates/comodo.aspx . Namecheap lets you choose from which certificate authority you get the certificate, they're all trusted by current browsers so there is fairly little value in picking e.g. verisign over comodo.

A wildcard of the format

*.musicbrainz.org

would do everything except musicbrainz.org itself (https://en.wikipedia.org/wiki/Wildcard_SSL_certificate). Wildcards also prevent getting EV certificates; I don't know whether or not we care about that. I do agree that we want to secure our subdomains as well though, especially since there are likely so many shared passwords. An option (listed on the linked page) is to manually list all the relevant subjectAltName entries within the certificate.

My vote would be for an extended-validation (EV) certificate using the subjectAltName extension to list our various subdomains (which we should have a list of somewhere, I imagine?).

A good read is also http://www.imperialviolet.org/2012/07/19/hope9talk.html

I would think wildcard, so we can use them on all our other services (forums, tickets, etc). That'd be due to me being in the HTTPS everywhere camp.

Agreed, lets move on this.

However, it is not clear which certificates I should get. Do I get a *.musicbrainz certificate or just a musicbrainz.org certificate? Assigning to warp who seems to have a decent grasp on this.

This is blocked on certificates and stuff, so I'm assigning to Rob who is the only person who can help with that.

Agreed to fix within 3 months by http://scheduling.ocharles.org.uk/results and http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-06/2012-06-11.html

Screenshot shows an example of how an 'intercepted' Musicbrainz login request looks, containing in plain text both the username and password submitted through the login page (helpfully labelled up as such too!)

This sort of thing seems to be in the news again recently with LinkedIn, last.fm & eHarmony. I appreciate there's a difference in how those passwords were seemingly obtained, but in all those cases passwords were at least taken in encrypted form, so there is some protection for those using relatively strong and unique passwords. MBz passwords are still being sent, never mind stored, in the clear so no matter how good a password, if intercepted it's there for all to see. Given that many users reuse passwords, and once logged in the users email address is accessible, although there is little to be gained from accessing a MBz account alone, once a users' email is accessible, access to most websites registered with that email address can be found and/or reset.