|
Sort Order:
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!) Agreed to fix within 3 months by http://scheduling.ocharles.org.uk/results This is blocked on certificates and stuff, so I'm assigning to Rob who is the only person who can help with that. 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. 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. A wildcard of the format *.musicbrainz.org  ). 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 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 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. 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 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. 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) 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 > 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 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! 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? Note to all: test.musicbrainz.org is now running with a non-self-signed cert; (testing: logging in using SSL and then going back to non-SSL does work as it should) https://www.ssllabs.com/ssltest/analyze.html?d=test.musicbrainz.org Sadly there's a little more to do until we can ship this, so I'm pushing it to the next version. The window for shipping this to beta testing has closed, so this will have to wait for the next release. SSL is now available on production. There's at least one issue still, in that https://www.musicbrainz.org TODO on this ticket: force SSL for login and registration. This is in review, but there is no open review. Status update please! I don't know why this is marked as in review, but it's not, so I'm pulling it out I am also removing the fix version – this needs to go forward, but it's definitely not in the next release. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Reopened
Normal
Login page should be encrypted (SSL/TLS)
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.