Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
I took a quick look at the difference between the TLS handshaking used by roVideoScreen and roUrlTransfer. It appears that, like the other built-in components: roPosterScreen, roSlideshow, roImageCanvas, etc., roVideoScreen also will only negotiate a TLS session using TLS 1.0, whereas an attempt to retrieve the same resource using roUrlTransfer will be negotiated to use TLS 1.2.
Here's a Wireshark capture taken when retrieving a video using roVideoScreen:
And another capture retrieving the same video file using roUrlTransfer:
I set up my own server to use "strong" TLS encryption, refusing connections from clients that only support TLS 1.0 and got the same "handshakefailed" error reported by jedashford in his initial post, even though I could download the video successfully using roUrlTransfer:
It seems to me that there's something messed up with the Roku's TLS code as it pertains to the built-in components.
It looks like some CDNs are requiring their clients to connect using TLS 1.2 possibly due to the various security vulnerabilities discovered in earlier SSL/TLS versions, but this is not supported by the Roku's built-in components.
It's been almost a month since I first reported this issue, and there's been not a single word from anyone at Roku even acknowledging that they're even aware of the problem. I'm surprised. Most companies take security issues seriously these days once they're notified of a potential problem in their security protocols.
Here's a Wireshark capture taken when retrieving a video using roVideoScreen:
And another capture retrieving the same video file using roUrlTransfer:
I set up my own server to use "strong" TLS encryption, refusing connections from clients that only support TLS 1.0 and got the same "handshakefailed" error reported by jedashford in his initial post, even though I could download the video successfully using roUrlTransfer:
------ Running ------
00:56:15.266 Starting ..
00:56:15.577 playVideo. roSystemLogEvent [21]-LogType=http.error. Datetime: 00:56:15.575
00:56:15.578 > Url: https://videos.nsa.mil/Videos/video-5secs.mp4
00:56:15.580 > Status: handshakefailed
00:56:15.597 > HttpCode: -1
00:56:15.598 > Method: GET
00:56:15.600 > TargetIp: 192.168.0.100
00:56:15.603 > OrigUrl: https://videos.nsa.mil/Videos/video-5secs.mp4
00:56:15.744 playVideo. roVideoScreenEvent [11]-isStatusMessage. Message: Unspecified or invalid track path/url.
00:56:15.748 playVideo. roVideoScreenEvent [9]-isRequestFailed. Message: Index: -5. MediaFormat: ???
00:56:15.778 playVideo. roVideoScreenEvent [1]-isScreenClosed
00:56:15.781 Finished
It seems to me that there's something messed up with the Roku's TLS code as it pertains to the built-in components.
It looks like some CDNs are requiring their clients to connect using TLS 1.2 possibly due to the various security vulnerabilities discovered in earlier SSL/TLS versions, but this is not supported by the Roku's built-in components.
It's been almost a month since I first reported this issue, and there's been not a single word from anyone at Roku even acknowledging that they're even aware of the problem. I'm surprised. Most companies take security issues seriously these days once they're notified of a potential problem in their security protocols.
