Yesterday in our dev meeting we agreed to take the HTTPS plunge for all of our web site traffic in as little as 2 weeks time. This means that all web site traffic (not the web service) will be served over HTTPS; if you visit any MusicBrainz HTTP URL (e.g. http://musicbrainz.org ) you will be redirected to the equivalent HTTPS URL (e.g. https://musicbrainz.org ). This will not be applied to our web services, you’ll still be able to access those with HTTP. However, we do encourage all of our web service users to make use of HTTPS when possible.
We have one bug to address before we make this switch. And if we can find a sufficient fix for this in time, we’re going to make the HTTPS switch on 16 September 2013. If we can’t find an acceptable fix, we’ll have to postpone this switchover.
If for some reason you can see that switching all web site traffic to HTTPS is a bad idea, please leave us a comment ASAP.
MetaBrainz Blog 
Doesn’t SSL just slow websites down? What’s the point?]
If someone wanted to intercept my Musicbrainz browsing session I really don’t care lol
I have been testings HTTPS-MB for a few days and I thought it was slower indeed than HTTP-MB.
But maybe the part that was slower was HTTPS-CAA displayed with the FUNKEY CAA userscript (displaying inline mosaic of album covers on MB pages)…
I found out that forcing HTTP-CAA in this script (even if using HTTPS-MB) today, removed that latency problem.
I know nothing but I fuond a blog post listing some tips to avoid slowdowns http://blog.httpwatch.com/2009/01/15/https-performance-tuning/ maybe you guys should look at it to make sure everything is done for the coolest operations.
Could you please tell us the reason behind this decision?
I can’t imagine that the NSA collects data about a music data collection? Maybe I’m wrong?
MB is slow enough now and I am afraid that SSL will slow it down further. Please what are the reasons for this decision?
pabouk: I rather doubt you’ll notice the difference in speed between encrypted pages and not encrypted pages. Our front end machines that will do the encryption are mostly idle, passing along web page content. They have plenty of CPU power to encrypt pages too.
As far as the motivations, some reasons are:
1. No longer send passwords in plaintext across the net.
2. Generally encrypt web traffic — this is generally a good idea and prevents man in the middle attacks, including unfair ad insertion hacks. And, with all of the snooping is going on, we would like to be part of the movement to get all web traffic encrypted.
@InvisibleMan78 – “I can’t imagine the NSA collects data” is going dangerously down the “you have nothing to hide” path. I guarantee you don’t want to go down that path.
@acidcycles: Of course I have things to hide. But MB is not on this list. “Unfair ad insertion hacks” is also not such a big problem IMHO.
I mean: It’s ok to introduce HTTPS “to be part of the movement”. But it would be even better if the MB team would clearly tell us reasons like “protect users from NSA” or “show NSA that scanning everyone, everywhere, everytime isn’t right”.
On the other side: How much will it help to encrypt webtraffic about music metadata?
if the servers who do the encrypting have the resources necessary, great! there are exactly zero reasons which speak against encryption if the servers can handle it. none. even if the data which musicbrainz provides isn’t that sensible that one would necessarily need encryption.
and according to the news in the last few weeks the question isn’t “why would the nsa read this data” but “why WOULDN’T the nsa read this data”. looks like they just ignore the really bandwidth heavy services like youtube, netflix and so on.
and this doesn’t just apply to the nsa, but pretty much every other state with all their agencies
Using HTTPS is not preventing anyone to know what release/artist/etc. you are browsing on… only the POST parameters will be hidden AFAIK. The URL are plain text be it HTTPS or HTTP same same, aren’t they?
But nothing against HTTPS as long as it is (made) as fast as HTTP. 🙂
OK, that is good if the frontend servers have enough free CPU power.
@jesus2099: SSL/TLS is a protocol which in HTTPS sits as a layer between TCP and HTTP. HTTP can run practically unchanged on top of the SSL. Then in the TCP data we have completely encrypted HTTP. A possible attacker can only capture server’s certificate at the first phase of the handshake but the certificate could be requested directly anyway 🙂 The actual HTTP communication starts – only after thes SSL handshake finishes succesfully – in an encrypted tunel.
@jesus2099:
I recommend you to read this article about mechanics of HTTPS: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
About the topic: I think this is a good idea: there is no such thing as “too much of privacy”. I don’t want to sound as populist, but for all the people who are talking about “Special services aren’t interested in my music metadata”, I’d like to remind the story about Wikipedia and the ban of Scorpions’ album image (https://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia ). If such filtration systems use DPI, encrypted traffic may pass. If they don’t… Well, then we are doomed anyway. 🙂 So, if MB’s servers have enough of power to support encryption of the traffic, then I fully support it.
@ruaok/@zag2: HTTPS does make the website slower, not because of CPU usage, but because there are many more network round-trips involved in establishing a connection. Those in the US probably won’t notice much anything since latency to the servers is low, but on other continents it’s noticeable.
But regardless, I fully support this decision, thanks! I’ve been using https-only MusicBrainz for many months now.
You can win back most of SSL overhead if you enable SPDY (now experimental in nginx 1.4.0).
@intgr: Our frontends are in dire need of an upgrade, but once they have been we still won’t necessarily be at a place to enable SPDY, sadly — precise, the most recent ubuntu LTS release, only provides 1.1.19. We may need or want the nginx lua extension as well, however, which might facilitate something more current (though it appears to be in nginx-extras starting with precise). None of that’s strictly decided yet though. Hopefully, however, we’ll be on a new enough version that that’s feasible sometime soon. Sadly, I believe most tests have shown SPDY to not be faster than plain HTTP in essentially any context, but it’s certainly better than vanilla SSL. I’d also love for us to have a mirror, for at least read-only stuff, somewhere in the EU. But that’s a bit more of an engineering challenge for anything beyond a basic static-content-only CDN.
Note that the single biggest reason for using SSL exclusively on musicbrainz, other than the “support the movement!” type notions, is man-in-the-middle attacks aimed at extracting passwords. Originally the ticket related to this talked only about login and registration pages, which is the most straightforward man-in-the-middle attack to recover passwords used on musicbrainz (just listen in, read the POST parameters plaintext, and voila!). It’s far from the only one, however; the next easiest one would essentially be to modify the page to create a fake login page, over plain http, and relay the credentials to musicbrainz to mimic the real login page; this is a vulnerability, essentially phishing, that’s present whenever a site delivers content both with and without SSL. Mostly it just seems lax to ignore this sort of attack, that’s not from a technical standpoint any harder to pull off than the passive listening attack that support was added to mitigate initially. Of course, using SSL across-the-board also prevents lesser attacks like ad insertion, but ultimately that’s just gravy 🙂
One other aside re: upgrades is that upgrading openssl will allow us to enable ECDHE-based ciphers, which a.) provide perfect forward secrecy on more browsers than the DHE ones already enabled, and b.) are way more efficient computationally. (Folks who don’t understand that sentence: don’t worry about it. Crypto-nerdery that can probably mostly be ignored!)
As I don’t live in America, maybe this is why I witnessed a more slower browsing.
Browsing HTTPS-MB is really very OK for me, it is not that much slower (but cool if it can be even better).
It’s **HTTPS-CAA** that is very much slower (I have a latency of 4 or 5 seconds each time I load a set of images). Maybe they didn’t implement a correct [*keep-alive* stuff](http://blog.httpwatch.com/2009/01/15/https-performance-tuning/) (once again, I’m complete ignorant). So I use **HTTPS-MB**+**HTTP-CAA** and it’s OK.
And thank you for taking those great care of us, users.
Because for instance, I don’t like having to change all my passwords as says Ian indeed. 🙂