Closing in on three years after stating that “We’re going to take the HTTPS plunge!”, we’re actually really going to do it now. 🙂
Most of our sites have forced HTTPS for some time (metabrainz.org, critiquebrainz.org, bookbrainz.org, listenbrainz.org), but there are still a couple of stragglers, notably musicbrainz.org and acousticbrainz.org.
For MusicBrainz, our beta site is now all HTTPS, web service and all. The main, non-beta musicbrainz.org will be going HTTPS-only except for what’s under /ws/ (ie., the web service) to allow taggers and other programs not currently using HTTPS some transition time. We do not currently have an ETA for when we will make the final jump to HTTPS-only on the MusicBrainz web service, as that partly depends on feedback from our web service users, which leads me to:
If you’re currently using the MusicBrainz web service, please try and switch your program to using beta.musicbrainz.org and see whether your program breaks or not and let us know the status of it. We are aware that some Python versions and MusicBrainz libraries do not support our setup, so while your program may fail now, it might simply be because of dependencies of your program not being updated yet and you might not need to do anything specifically on your end – however, some programs/libraries might need some updates, so the more people test and report back, the better we’ll be able to judge when we can go all-HTTPS-only on musicbrainz.org.
For AcousticBrainz, we now have a shiny new Let’s Encrypt certificate on https://acousticbrainz.org thanks to our systems administrator Zas! As a result, we are going to start redirecting all HTTP traffic to HTTPS on the AcousticBrainz website, including API queries.
In order to give everyone time to verify that their scripts correctly recognise and validate our Let’s Encrypt certificate, we are going to delay the redirect until July 1, 2016. On this date, any HTTP query will automatically be redirected to HTTPS. We will also enable HSTS, so that compliant browsers will redirect to HTTPS on the client-side.
If you have any questions about either the MusicBrainz or the AcousticBrainz transition, please ask.
MetaBrainz Blog 
How does this step affect the next virtual machine (after the schema change)?
Short answer: It doesn’t. 🙂
Glad to finally hear it.
I just tried to use the HTTPS endpoint for AcousticBrainz with a standard Java 8u92 and get this:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
It appears that the Let’s Encrypt CA is not included in the standard Java Runtime Environment. To be honest: That’s a gigantic PITA.
More info can be found at https://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the-default-list-in-the-jdk-jre/134/47
Java 8u101 (not released yet) may contain the right certificates (see https://bugs.openjdk.java.net/browse/JDK-8154757).
If you have a lot of Java clients, I’d consider not turning off the HTTP endpoint, until those folks can easily use the HTTPS endpoint. Saves everybody a lot of pain.
Just my 2c.
Dope! I’ve been waiting to implement this on my musicbrainz mirror for.ev.er. 🙂
I agree with hendriks73 here.
That is one of the real issues still with LetsEncrypt and the like.
I had enough issues at work with a corp GoDaddy SHA2 cert that a business client wanted to connect to us via oracle java. The releases of java are slow to add this stuff and the old java clients are not likely to be updated for years in corp environments.
I am not sure of your client base but maybe your business customers have old implementations of java they are connecting to you on.
A comprise might be have a the http to https redirect rule that redirect if the user agent doesn’t contain the word java for now. Should be straightforward Regex.
I don’t think we have any business users of the AcousticBrainz data (none that I am aware of, anyway), which is the one going HTTPS-only soon. MusicBrainz’ WS will be accessible over HTTP at least the rest of the year. The Python 2 version shipped by e.g., Ubuntu Trusty will also not work for HTTPS, so it’s not just Java we’re waiting on. And apparently coming versions of Java will also acknowledge LE certificates, so the Java issue should dissipate in time. As I said in the post, we’re reaching out to people using the MusicBrainz web service and collecting feedback. We’ll see how the situation evolves.
Is there any chance HTTPS could be enabled on http://tickets.musicbrainz.org/? It still has a login form that’s getting sent in plain text.
johtso: This isn’t really on-topic here. See http://tickets.musicbrainz.org/browse/MBH-393
@johtso, did you actually try it? https://tickets.musicbrainz.org/ “works” for me and I have used HTTPS exclusively for the ticket tracker for a couple of weeks now. See also chirlu’s link.
@chirlu, I’d argue that it very much *is* on topic. 🙂 This blog post is about HTTPS’ing our entire “ecosystem”, not just MB and AB.
Well, if it’s on-topic … Did you read my comment on the ticket? The situation hasn’t changed since.
Do you have http://tickets.musicbrainz.org/browse/PICARD-764 in mind? Basically enabling HTTPs on MB.org will break stable Picard. Fix by zas is already in development version.
Enabling HTTPS will not break Picard. HTTPS for MusicBrainz has been enabled for years. Forcing HTTPS will break Picard… which is why that isn’t going to happen Soon™, as per my comment a few comments up: https://blog.musicbrainz.org/2016/05/19/were-actually-really-going-to-take-the-https-plunge/#comment-129862
@Freso: Thanks for the clarification. Actually I thought forcing HTTPS was what was going to happen.
phwolfer, note that everything belonging to the web service (under /ws) will be excluded from http→https redirection for the next few years (possibly with the exception of /ws/js, but that should not be used by external clients anyway).
Could this be the reason why the freedb server service is no longer available?
Forage: No, that’s an unrelated issue.
As mentioned in my comment above (https://blog.musicbrainz.org/2016/05/19/were-actually-really-going-to-take-the-https-plunge/#comment-129850), there’s a JDK bug report that addresses the issue with Java 8u92.
FYI: The fix for this bug is contained in the recently released Java 8u101/102.
I was able to confirm that one can now connect to AcousticBrainz/MusicBrainz via HTTPS without having to import any additional CA Certs.
Awesome choice let’s encrypt