Mixing HTTP and HTTPS content will always throw a Cross Origin Resource Sharing (CORS) at the browser level. There is no method to either suppress or ignore that warning. Content must always use HTTP only or HTTPS only.
DSA is faster in signing, but slower in verifying. A DSA key of the same strength as RSA (1024 bits) generates a smaller signature. An RSA 512 bit key has been cracked, but only a 280 DSA key.
So RSA would need to be used and because it can both encrypt and decrypt, and an RSA 512 has already been cracked.
The StreamLock option is a good fit for a “Free” option needing HTTPS delivery, however if security of the content is a real concern then using RSA 2048 is a better fit, though the added overhead does have to be accounted for concerning resources.
I really don’t care about security. My problem is that everyone’s serving sites over https and if I stream hls over http I get mixed content and google chrome blocks hls.js plugin in flowplayer due the mixed content.
I am trying to live stream over https to avoid this issue. But when I enable ssl stream lock as I was written I could stream only for 300 visitors and my CPU was at 100%. Normally with http I stream for 7000-8000 visitors.
You can use a less CPU intensive method for SSL delivery. Please reference the article below for more information on changing the cipher suite that is being used.
Nothing more on this? This is a terrible setback for many uses of HLS, particularly when those TLS files being served over http are in fact AES encrypted. Per-session encryption will never, ever be as scalable as one-time encryption.
nginx handle this request and proxy passing the request to the wowza and get response from wowza then answer the request, by the way your link can work on https page and your wowza still working on 1935