29 comments

[ 3.4 ms ] story [ 49.1 ms ] thread
This raises the question of: why is Spotify on HTTP for the first seconds? Would it be to bypass the TLS handshake, hence a faster "start" time? Wouldn't a constant connection (à la WebSocket with TLS) fix this?
I'm guessing a constant connection would use more battery/data?
AFAIK the Spotify apps already use a persistent connection to their messaging service to facilitate instant, cross-device changes when you do something like saving a track to your library.
It's pretty concerning whatever the reason is. Either it's worth encrypting the traffic or it isn't.
Is it really that concerning? What's the worst case scenario here? If the worst thing that can happen is you get served audio that you weren't expecting then I don't really see the big deal. I'm not immediately aware of any way that someone might use this as an attack vector, but then I'm not really a security guy..
If say, Spotify used a vulnerable audio decoder (or called into an OS one that was vulnerable), it could be used by an attacker to deploy an exploit against your device.

Now - is that very likely? Probably not, even if such a vulnerability exists modern exploit mitigation tactics often are able to prevent it from becoming very harmful. But it's worst case.

Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.

Ok that makes sense, thanks!
> Android itself has had big media decode vulnerabilities in the past (looking at you libstagefright) but they basically turned out not to be readily exploitable due to ASLR on modern devices.

That's what the optimist says.

The pessimist says, "Android itself has had big media decode vulnerabilities in the past and they only turned out not to be readily exploitable due to ASLR on modern devices".

Haha, yeah, I was actually sort of looking forward to the fallout from an MMS worm, brings back the good ol' days of Blaster and Sasser. Might have beat Android updates into shape too.

Unfortunately that dream never came to light.

Unless the encryption only exists due to a contractual obligation because "someone might steal it".
HTTP works in most places. When the music has started playing, the client can try other methods, versus waiting for a timeout.
HTTPS works in most places too.

Edit: the HTTP vs HTTPS is interesting. My guess is because it is slightly cheaper to use HTTP and they serve a fuck load of music. But this only saves you from MITM attacks. People can still grab music out of their cache. So confusing.

Is the song information unencrypted? If so, it could be a loophole to sell customer data without their consent.
I would like to know why too. Perhaps the Spotify devs should look into another way to secure traffic if TLS adds too much latency (such as the noise protocol)?
Maybe because of captive portals? Anyone connected to hotel wifi for example will just get an unresponsive application if it doesn't try to connect over http before switching to tls. Not sure Spotify should trust that connection as much as it appears to though.

Also, as long as it's only streaming audio over http (no auth details etc) the security risk is fairly low considering the added overhead, so it might not be a terrible decision.

(comment deleted)
Apart from being a very funny, this is a very nice MiTM "Hello World". A real-world application of something that is not very easy and straight forward. I remember trying to learn this stuff a few years ago and could never find a simple way of doing it.

Really great stuff.

I too feel that it's better to try alternate methods once the music starts playing
Tried this both on Android and iOS and can confirm that it works :)
Kind of a lot to ask but I'm fairly new to this kid of stuff (especially mitmproxy) and would love to try it out. Unfortunately the instructions on git hub aren't very in-depth. Do you have any advice for me to learn and execute this?
They could still serve the first few seconds from a CDN at the edge via TLS.
Couldn't the preview always end after N seconds, and the licensed stream always begin at the very next frame? Then it's just a matter of appending the licensed stream to the playback buffer after exhausting the preview stream.
Exactly. This is how you do it. But you'd be surprised how complicated this is.