23

I was doing some cross-origin requests to Soundcloud's oEmbed and I noticed some strange behaviour.
When doing a request from my localhost, which is on a regular HTTP connection, everything worked fine. However, when the code got pushed on our HTTPS test server, I got the following error from my browser:

[blocked] The page at 'https://example.com' was loaded over HTTPS, but ran insecure content from https://www.soundcloud.com/oembed?url=https://soundcloud.com/gwatsky/pumped-up-kicks-remix&format=js&callback=JSON_CALLBACK: this content should also be loaded over HTTPS.

The request URL is //www.soundcloud.com/oembed?url=https://soundcloud.com/gwatsky/pumped-up-kicks-remix&format=js&callback=JSON_CALLBACK. Note the "www.".

I tried specifying the protocol to HTTPS and removing/specifying the protocol in the url parameter, but I kept getting the error.

In the end I removed the www. from the URL and everything started working fine.

tl;dr Why is having www. in this HTTPS URL considered a security risk?

Improve this question
7
  • 23
    As David pointed out, SoundCloud is redirecting requests at https://www.soundcloud.com to http://soundcloud.com. Since https is dropped, your browser will complain of insecure content.
    – Question Overflow
    Aug 24, 2014 at 7:33
  • 5
    It seems that the issue has been resolved by soundcloud by now.
    – Yogu
    Aug 24, 2014 at 21:21
  • 3
    Web security strongly relies on hostnames. And a hostname www.soundcloud.com is not the same as soundcloud.com -- browsers and SSL certs are very strict about this. (And there are right and wrong ways to configure servers to handle these discrepancies. Sometimes mistakes, like a faulty 301 redirect, cause errors like this.)
    – Matt
    Aug 25, 2014 at 3:57
  • 4
    It should be noted that the Chrome error message is rather bad too, because it complains about loading insecure content from what looks like perfectly valid secure URL without mentioning the bad redirect anywhere.
    – Jan Hudec
    Aug 25, 2014 at 6:21
  • 12
    You know nothing.
    – Lightness Races in Orbit
    Aug 25, 2014 at 12:50

3 Answers 3

Reset to default
86

I think you are making a huge assumption with your question:

Why does Chrome consider the "www." in an HTTPS url as a security risk?

as this is simply not the case.

What is happening is that SoundCloud is forcing users from www.soundcloud.com to soundcloud.com with a 301 redirect. The problem is that they are redirecting all traffic to http://soundcloud.com regardless of the originating protocol.

This is simply a configuration issue with the Soundcloud website and has nothing to do with browser or web security standards. There is no inherent risk with the www subdomain to a website.

The solution as you have already figured out is to remove the www in order to avoid the redirect. You might want to make the site's administrators aware of the issue if you are so inclined.

Improve this answer
1
  • 3
    Alright I'll rephrase the question.
    – Jon Snow
    Aug 24, 2014 at 6:56
15

Your browser is showing this warning because Sound Cloud apparently has incorrectly configured redirect for the following URL:

https://www.soundcloud.com/oembed

redirects to:

http://soundcloud.com/oembed

Notice the normal "http". This is why the browser is raising a red flag when embedded inside another https-based website/page. Whereas,

https://soundcloud.com/oembed

is not getting redirected and thus remains on the secure side of http.

Improve this answer
0

The observation and behavior is correct, but the conclusion is wrong. The SSL certificate is issued in two ways

  1. To the site. In your case soundcloud.com . As per the naming convention, soundcloud.com and www.soundcloud.com are two different names. Hence https site accessed with www.soundcloud.com, it denied saying the certificate is not issued to www.soundcloud.com . This does not mean there is issue or it is unsafe. The data is still going over SSL layer and provides same protection when accessed over soundcloud.com.

  2. In corporate sites, the certificate is issued to wildcard domains. But the wildcard certificates are very expensive and hence, most customers avoid going with wild card. In wild card case, the certificate is issued to *.domain. In your case if the certificate is issued as *.soundcloud.com then www.soundcloud.com or soundcloud.com all will work. even w3.soundcloud.com anything.soundcloud.com will also work.

I appreciate you brought a very good topic for discussion, but one need to understand the entire SSL certificate, domain , naming behavior in this case.

Many times, improper configuration of root certificate chain in server leads to error as well.

Improve this answer
1
  • It is true example.com and www.example.com are different for cert name matching. But the error message here was clearly mixed content, not cert name mismatch. And the cert for this site (from GlobalSign DV SHA2 G2) has SubjectAltNames specifying BOTH soundcloud.com and *.soundcloud.com. Further, *.foo matches www.foo and 'w3.foo` and 'anything.foo` but not plain foo; see RFC 2818 and serverfault.com/questions/447222/… .
    – dave_thompson_085
    Aug 27, 2014 at 8:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .