RTC: Ensure private network requests are made from secure contexts

[winlinvip]

Today I discovered that Chrome updated its security policy in July 2021, which caused the HTTPS player on the official website to be unable to play the SRS stream on the local network. Of course, this does not mean that it cannot be used at all. I will list which ones are working properly and which ones have issues (assuming your SRS local network IP is 192.168.11.172):

• OK: Local HTTP page plays HTTP API, it can also be opened locally for testing.
• OK: Local network SRS HTTP page plays HTTP API, accessing the SRS on the local network is also possible.
• OK: Local network SRS HTTPS page plays HTTPS API, self-signed certificates are also accepted during testing.
• OK: Official website HTTPS page plays HTTPS API, this is the standard practice for providing services.
• FAIL: Official website HTTPS page plays HTTP API, this is because HTTPS pages cannot access HTTP resources.
• FAIL: Official website HTTP page plays HTTP API, this is because HTTP pages no longer support cross-origin requests.

Note: The mentioned "play HTTP API" refers to the API for WebRTC streams, which is an HTTP API. The transmission of the streams still uses UDP.

The last point is about playing SRS streams from an internal network using the official HTTP player. This issue is related to the security policy update made by Chrome a few months ago. If you open the console, you will see the following error message.

Ensure private network requests are made from secure contexts

A site requested a resource from a network that it could only access because of its users' privileged 
network position. These requests expose devices and servers to the internet, increasing the risk of a 
cross-site request forgery (CSRF) 
attack, and/or information leakage.

To mitigate these risks, Chrome deprecates requests to non-public subresources when initiated from 
non-secure contexts, and will start blocking them in Chrome 92 (July 2021).

To fix this issue, migrate the website that needs to access local resources to HTTPS. If the target resource 
is not served on localhost, it must also be served on HTTPS to avoid mixed-content issues.

Administrators can make use of the InsecurePrivateNetworkRequestsAllowed and 
InsecurePrivateNetworkRequestsAllowedForUrls enterprise policies to temporarily disable this restriction 
on all or certain websites.


1 request
Request	Status	Resource Address	Initiator Address	Initiator Context
play/	blocked	Private	Public	insecure

Learn more: CORS for private networks (RFC1918)

I have tried adding parameters to the page, but it didn't work.

    <meta name="referrer" content="origin">

Here is an alternative workaround: If you are only developing, debugging, and learning, you can follow the method taught by Darren, a teacher at Zero Sound Academy. Simply disable HTTPS and all security policies when starting Chrome, which works well.

If it is for online use, it is better to stick to HTTPS honestly.

References:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
• https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default
• https://developer.chrome.com/blog/private-network-access-update?utm_source=devtools

TRANS_BY_GPT3