You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past, there have been several discussions of the relative security of using an internal HTTP server in Readium-1. The point was made (originally by @ryanackley - Ryan Ackley) that using common tools like WireShark, one can intercept the stream and grab its contents. This can happen whether the original content was encrypted or not. This is because the stream can be intercepted after the content has been decrypted by the DRM engine.
Before we try to determine the seriousness of this and/or try to determine ways to block such actions, it would be good if someone on the team would verify this exploit is possible. I am pretty sure Ryan is correct, but in any case, we need a way to verify if any proposed blocking action actually works.
The text was updated successfully, but these errors were encountered:
In order to limit the ability for another app to intercept what's going on, I'd like to suggest two things:
Random port or URI for the manifest
Instead of always using something like http://localhost:8080/manifest.json we could instead assign a random port number or calculate a hash for the manifest.
This could for example return: http://localhost:8204/cn389ncoiwuencr.json
Sign each request to a resource
We could also sign each request with a short-lived token to limit replay attacks (token is intercepted and used in another context).
A JWT (http://jwt.io) could work very well for that:
the payload contains the URI that we'd like to access and the expiration date for the token
the secret to sign the JWT is shared between server & client
The client would simply include this token as a bearer token in its HTTP headers: Authorization: Bearer <token>
Tricky part, is that I'm not entirely sure if we'll be able to intercept each and every request initiated from the webview to do that.
In the past, there have been several discussions of the relative security of using an internal HTTP server in Readium-1. The point was made (originally by @ryanackley - Ryan Ackley) that using common tools like WireShark, one can intercept the stream and grab its contents. This can happen whether the original content was encrypted or not. This is because the stream can be intercepted after the content has been decrypted by the DRM engine.
Before we try to determine the seriousness of this and/or try to determine ways to block such actions, it would be good if someone on the team would verify this exploit is possible. I am pretty sure Ryan is correct, but in any case, we need a way to verify if any proposed blocking action actually works.
The text was updated successfully, but these errors were encountered: