http://www.*.libsyn.com redirected to non-functioning https of same URL.

[AlanDeSmet]

Type: ruleset/website issue

For libsyn.com hostnames that begin with http://www., HTTPS Everywhere redirects to the exact same URL, but with https. This doesn't work as the available certificate does not include the www. Removing the www. takes me to a working page.

In Firefox 67.0.4, I get errors like this:

ⓘ Secure Connection Failed

An error occurred during a connection to www.thefeed.libsyn.com. SSL peer has no certificate for the requested DNS name. Error code: SSL_ERROR_UNRECOGNIZED_NAME_ALERT

• The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
• Please contact the website owners to inform them of this problem.

Learn more…

☐ Report errors like this to help Mozilla identify and block malicious sites

Examples:

http://www.ludology.libsyn.com/ redirects to https://www.ludology.libsyn.com/ which fails, but https://ludology.libsyn.com/ works. (This is Google's first search result for me for "ludology", so I suspect I'm not the only person running into this.)

http://www.thefeed.libsyn.com/ redirects to https://www.thefeed.libsyn.com/ which fails, but https://thefeed.libsyn.com/ works.

I suspect the correction is to strip the leading www. when present. This does appear to work find for the top-level http://www.libsyn.com.

[pipboy96]

@AlanDeSmet Thanks for notifying us about this bug! I have started working on the fix right now.

[Bisaloo]

@pipboy96, feel free to ping me if you submit a PR for this!

[pipboy96]

@Bisaloo There is some problem, specifically that there are hundreds of subdomains I can't really check in any realistic way. I don't want to just mindlessly redirect *.libsyn.com as the current ruleset does. Any idea what to do?

[Bisaloo]

I think this is fine. We do this in many similar cases, where the ruleset target is a content hosting platform. There is no need to check every single subdomain.

See https://github.com/EFForg/https-everywhere/blob/release/src/chrome/content/rules/Spreadshirt.xml, https://github.com/EFForg/https-everywhere/blob/master/src/chrome/content/rules/TheRoot.com.xml, https://github.com/EFForg/https-everywhere/blob/master/src/chrome/content/rules/Frama.io.xml

The only possible issue is MCB. You can try to find out if some subdomains have active mixed content, in which case the whole ruleset should be marked as platform="mixedcontent".