Virgin Media Community

[DreamOfCheese]

As I've stated further up, it's most certainly not blocked by VM as it's also returning a 403 on EE and on a UK based VPN.

Virgin would also not be able to display a web page whatsoever on a HTTPS URL without a certificate error displaying as they'd be unable to get a signed certificate for the domain name. This 100% confirms that the error page being shown is on a server controlled by the domain owners.

[Wezza]

Just use another web browser like torproject.org !

[davebinman]

Seems it really HAS BEEN BLOCKED by VM and others:-
https://www.reddit.com/r/Piracy/comments/azb09m/zippyshare_ip_ban/

[DreamOfCheese]

The people in that thread coming to a conclusion that it's blocked are incorrect, even using the blocked.org.uk they're referencing proves them wrong.

https://www.blocked.org.uk/site/https://zippyshare.com here's the HTTPS version of the site which won't be blocked by ISP child/websafe filters, as you can see it's showing the site's fine but 403 Forbidden.

HTTPS uses TLS/SSL, due to how this works the only way for a web page to show without a certificate error is for a certificate authority to sign a certificate, they will only do this for the verified domain owner. Virgin Media or any other ISP could not get a signed certificate for zippyshare.com in order to show a 403 Forbidden page, this would break the chain of trust and the certificate authority found to have signed this for them would be removed from the root store.

Further proof that this HTTPS 403 Forbidden is not a UK ISP block is the fact that my German server returns the same certificate as my VM connection:

Server - 

Spoiler

[server ~]# echo | openssl s_client -showcerts -servername zippyshare.com -connect zippyshare.com:443 2>/dev/null | openssl x509 -inform pem -noout -text

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            **:**:**:**:**:**:**:**:**:**:**:**

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=BE, O=GlobalSign nv-sa, CN=AlphaSSL CA - SHA256 - G2

        Validity

            Not Before: Nov  1 21:47:01 2018 GMT

            Not After : Dec  2 19:49:37 2020 GMT

        Subject: OU=Domain Control Validated, CN=*.zippyshare.com

[server ~]# curl -I https://zippyshare.com

HTTP/1.1 200 OK

Server: nginx/1.10.3 (Ubuntu)

Date: Mon, 11 Mar 2019 11:50:07 GMT

Content-Type: text/html;charset=UTF-8

Connection: keep-alive

Set-Cookie: JSESSIONID=7125A1D19E2DAA69806C7506B9C544F3; Path=/; HttpOnly

Set-Cookie: hazelcast.sessionId=HZ18BEAFC9CD6348F49D5B5D3272A48D74; Path=""

Set-Cookie: ziplocale=en; Domain=.zippyshare.com; Expires=Thu, 08-Mar-2029 11:50:07 GMT; Path=/

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

VM - 

Spoiler

[laptop ~ ]$ echo | openssl s_client -showcerts -servername zippyshare.com -connect zippyshare.com:443 2>/dev/null | openssl x509 -inform pem -noout -text 

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            **:**:**:**:**:**:**:**:**:**:**:**

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=BE, O=GlobalSign nv-sa, CN=AlphaSSL CA - SHA256 - G2

        Validity

            Not Before: Nov  1 21:47:01 2018 GMT

            Not After : Dec  2 19:49:37 2020 GMT

        Subject: OU=Domain Control Validated, CN=*.zippyshare.com

[laptop ~ ]$ curl -I https://zippyshare.com

HTTP/1.1 403 Forbidden

Server: nginx/1.10.3 (Ubuntu)

Date: Mon, 11 Mar 2019 11:49:37 GMT

Content-Type: text/html

Content-Length: 178

Connection: keep-alive

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

As you can see, both of the returned certificates have the same serial number, they're both the same certificate. You can also see the 'curl -I' response which returns HTTPS headers from the connection, both my laptop and my German server return the same server information string "nginx/1.10.3 (Ubuntu)" however my laptop on VM gets a 403 Forbidden.

EDIT: Apparently the forums removed the certificate serial number, I guess the MAC address matching they use is not designed to only expect the 6 segments of a MAC address. The command I used is in the spoiler though, so you can recreate it if wanted.

[landsberger]

So

From reading around, it's filtered out to the rest of UKInternetland that almost all ISPs can't access Zippyshare, so the permission (or lack of it) doesn't lie with individual ISPs, but Zippyshare themselves.

It's still not clear whether Zippyshare are doing this at the behest of Her Majesty's Learned friends, but I strongly suspect this might be the case. A "mistake" doesn't take 3 days to sort out, weekends notwithstanding.

[DreamOfCheese]

Considering all major UK ISPs have the infrastructure in place to respond to court ordered blocks that would be the protocol that would be used if the UK government or a copyright holder in the UK tried to get the site blocked.

It's very unlikely they'd go straight after Zippyshare and get them to add a geolocation based block to their frontend, considering Zippyshare has no UK presence and the rest of the EU is unaffected.

As I've mentioned and given conclusive proof of in prior messages the 403 error page is being served by the same server that's serving the rest of the world, a server hosted in France using OVH.

Currently the ball is entirely in Zippyshare's court to either fix the issue that seems to be prejudiced against UK connections and only UK connections, a very odd issue to have unless they have some region based CDN configuration that's gone awry, or for them to come out and tell everyone that for some reason or other they've blacklisted UK IP addresses.

[philpotty]

I just set Browsec at USA and have no prob with zippyshare
[Browsec is a free VPN app]