Google Music transfers tunes insecurely, exposes your files

If you use Google Music, you should be aware that the downloads coming from Google are not secure and could be sniffed out by those on your local network. While not the largest breach of security in Google’s history, it is quite surprising that Google would not use a secure protocol to transfer the content.

The issue is that Google Music does utilize HTTPS while browsing the store, but when it comes to downloading the music, Google uses HTTP, instead of HTTPS. The S denotes the use of SSL, which is a security mechanism for safely transporting content between two points.

The absence of HTTPS in file transfers means that anyone on your local network could easily identify the music you are downloading or even steal the files too. Sure, this isn’t going to ruin you financially but the fact it can be done easily is a bit alarming. More so, if you had private audio files stored on Google Music, they could be intercepted too.

In the image above, you can see that a file is being downloaded from Google Music and using Wireshark, the file was intercepted during transmission. You can also see that Google is using HTTP to transfer the music in the WireShark screenshot.

It’s a little flaw for the music store and if you use Google Music and don’t want your friends to know of your endless love for Justin Bieber, you might want to consider switching music services.

Thanks for the tip Artem S. Tashkinov

Report a problem with article
Previous Story

iPad Air catches fire in Vodafone store

Next Story

Panasonic's 20 inch Windows 8.1 tablet coming to U.S. in January for $5,999

34 Comments

Commenting is disabled on this article.

the explanation of https and its value is out dated. its not the protection it was once. https has been compromised since paypal was. that was when it was first reported many years ago and since then our nsa buddies have been trashing it regularly. HTTPS is no longer a protection except against choir boys. i would not change services over this. wring your hands over something else.

Come on. I come here for Windows and Microsoft platform news and information. Not for posts bashing every little thing Google does.

This article is trivial and FUD.

AmazingRando said,
Come on. I come here for Windows and Microsoft platform news and information. Not for posts bashing every little thing Google does.

This article is trivial and FUD.

Why not, Google scan your email to target you with ads and treat Windows Phone like crap compared to iOS so, IMHO, they deserve everything they get!!

However, as others have said this is trivial at best, music is not sensitive data and so doesn't require an SSL connection to the server when downloading.

Cute James said,
Does Brad ever post articles that are not pro-Microsoft/anti-Everythingelse?

It's no different to some of the writers on here being pro-Google/anti-Everythingelse!!

who's going to steal bit stream of music files over the internet? packet one may come your way, the next packet may routed else where. just go torrent sites, that's the proper way to steal.

Non-issue. Who cares if people can sniff my music? Besides if I had anything that was even remotely sensitive (as far music) then it wouldn't be on the internet,

Hmm no-one cars, and if you feel the need to defame someone over music he/she listens to, you need to go back to the hole you live in and wake up in the modern world!

This isn't a security vulnerability in any real manner. HTTPS doesn't encrypt everything. A person listening on the wire can still see what web addresses you're going to even if they can't see the content of he pages directly.

I'm not sure what value encrypting this would add. It would add a lot of weight to Google's servers and to the client side bandwidth needs as well. I'm sure Google omitted this for that reason. There really isn't a huge gaping security hole by sending the file itself over HTTP.

If this were sensitive personal information I would agree, but this doesn't seem to be anything worth caring about.

LogicalApex said,
This isn't a security vulnerability in any real manner. HTTPS doesn't encrypt everything. A person listening on the wire can still see what web addresses you're going to even if they can't see the content of he pages directly.

WRONG.

n_K said,

WRONG.

HTTPS can encrypt the page itself, but it can't encrypt the fact you're at Google.com. Otherwise, how will the underlying HTTPS transmission get started?

LogicalApex said,

HTTPS can encrypt the page itself, but it can't encrypt the fact you're at Google.com. Otherwise, how will the underlying HTTPS transmission get started?


Again, WRONG.
The only thing it doesn't hide is the IP you are communicating with, and if you connect to that IP directly, yes, you can get an SSL certificate which lists the domain it is for (or the list of domains as of wildcard/multiple SSL domain certificates). That means absolutely nothing though, I can self-sign myself an SSL certificate for google.com and stick it on my IP, and if you HTTPS'd to my site/IP, you'd see it'd say you were connecting to 'google.com' (and it'd give you a warning that the site URL and cert URL do not match).
Ergo, no URL data is exchanged ergo wrong.

n_K said,

Again, WRONG.
The only thing it doesn't hide is the IP you are communicating with, and if you connect to that IP directly, yes, you can get an SSL certificate which lists the domain it is for (or the list of domains as of wildcard/multiple SSL domain certificates). That means absolutely nothing though, I can self-sign myself an SSL certificate for google.com and stick it on my IP, and if you HTTPS'd to my site/IP, you'd see it'd say you were connecting to 'google.com' (and it'd give you a warning that the site URL and cert URL do not match).
Ergo, no URL data is exchanged ergo wrong.

n_K, how exactly do you plan on encrypting SSL traffic from Google.com using your own self-signed certificate?

Nas said,

n_K, how exactly do you plan on encrypting SSL traffic from Google.com using your own self-signed certificate?

Missing the analogy by 100%...

n_K said,

WRONG.

Wouldn't you be giving away your unencrypted DNS requests anyway before HTTPS begins to matter at all?

Nas: a Man in the middle attack. Add a host entry on your computer (or worse, the DNS server you point to) that says google.com n_K's server IP, and he's prepped with a certificate presenting itself as google.com. He could then proxy the traffic to the real google.
So the communication would look like this:
You <---> n_K (fake google <--> (real) google.com
And the encryption would look like
You (encrypt) ---> n_K (decrypt, read plain text) (encrypt) ---> google.com

n_K said,

Again, WRONG.
The only thing it doesn't hide is the IP you are communicating with, and if you connect to that IP directly, yes, you can get an SSL certificate which lists the domain it is for (or the list of domains as of wildcard/multiple SSL domain certificates). That means absolutely nothing though, I can self-sign myself an SSL certificate for google.com and stick it on my IP, and if you HTTPS'd to my site/IP, you'd see it'd say you were connecting to 'google.com' (and it'd give you a warning that the site URL and cert URL do not match).
Ergo, no URL data is exchanged ergo wrong.

Uh... What? How would your browser know how to get to Google.com if the DNS request isn't first sent unencrypted? If it could pull that off... Why do we have a DNS system at all?

Secondarily, the server will be sent the domain name in plain text to ensure compatibility with Host Header addressing...

http://www.moserware.com/2009/...-milliseconds-of-https.html

Obviously, HTTPS would protect the contents of the HTTPS transmission, but I still can't see the importance of this for a music file which has no personal information and is probably sitting on a file sharing site anyway.

cybertimber2008 said,
Nas: a Man in the middle attack. Add a host entry on your computer (or worse, the DNS server you point to) that says google.com n_K's server IP, and he's prepped with a certificate presenting itself as google.com. He could then proxy the traffic to the real google.
So the communication would look like this:
You <---> n_K (fake google <--> (real) google.com
And the encryption would look like
You (encrypt) ---> n_K (decrypt, read plain text) (encrypt) ---> google.com

Except unless the user is completely stupid, the browser will be telling you straight away that the certificate is dodgy by informing you that it wasn't signed by a trusted certification authority, and typically, preventing you from loading the page in the first place.

If you're willing to go through all the barriers that get put up and continue to pursue this path, then yes, it'll fool you, but by this point you're too far gone to be worth saving.

The only way to avoid that would be to have a trusted certification authority give you a certificate for the domain, but then the issue is with the certification authority not doing their job properly.

Ideas Man said,

Except unless the user is completely stupid, the browser will be telling you straight away that the certificate is dodgy by informing you that it wasn't signed by a trusted certification authority, and typically, preventing you from loading the page in the first place.

If you're willing to go through all the barriers that get put up and continue to pursue this path, then yes, it'll fool you, but by this point you're too far gone to be worth saving.

The only way to avoid that would be to have a trusted certification authority give you a certificate for the domain, but then the issue is with the certification authority not doing their job properly.

There is also the issue of malicious code getting onto the computer to install a forged/dodgy certification authority cert into the browser.

MIM attacks can get pretty ugly.

I think all of you guys are forgetting that the Internet is not a big truck. It's not something you just dump something on. It's a series of tubes.

!? I wasn't saying fake being google.com by hacking or whatnot, I was saying I can make a self signed SSL certificate with ANY domain on it, and stick it on my server and if anyone visited it, it'd say the URL was google.com.
SSL-DNS exists and caching also exists. There is pretty much 0% security risk from anyone knowing that you visit site X from DNS, they can't see any information you send or receive nor any of the URLs nor any of the headers if you're using SSL.

n_K said,
!? I wasn't saying fake being google.com by hacking or whatnot, I was saying I can make a self signed SSL certificate with ANY domain on it, and stick it on my server and if anyone visited it, it'd say the URL was google.com.
SSL-DNS exists and caching also exists. There is pretty much 0% security risk from anyone knowing that you visit site X from DNS, they can't see any information you send or receive nor any of the URLs nor any of the headers if you're using SSL.

As I have already shared there is information shared before the TLS connection is established to help that connection be established.

Either way, the sending of an MP3 unencrypted is of no serious issue.

This may even be intentional to reduce server load by not having to encrypt on the fly, since music is not considered sensitive material.

If Google has an agreement with the companies to distribute this over unencrypted channels, or nothing has been said to begin with, I don't really see a problem.

It is music, who cares. And I am sure Google will change this now as well. How Microsoft and others fix a lot of their problems...someone finds it, reports it, company fixes it. Business as usual and not only related to Google.

Hmmm. As long as its not data related such as Login, credit card, and similar details I see no problem on doing so.

Seriously, this is nothing new. Quite a bit of traffic is not secure at all. It's been this way the whole time but until the NSA got caught it wasn't news.

I suspect that if someone is actively sniffing my local network traffic, I have potentially far bigger problems than them knowing what music I'm listening to...