Open chethega opened 5 years ago
Thanks; your proposal seems better than adding an external dependency. If Http.jl adds the future dependency, we can use that through Http.jl.
It is a vulnerability, but with most actual uses, the garbage collector will create random time intervals I believe.
It is a vulnerability, but with most actual uses, the garbage collector will create random time intervals I believe.
Per rfc6455 10.3, this should not be too urgent to fix. Or do you have different attack scenarios in mind?
This looks mostly unexploitable to me; if I misjudged, then I apologize for opening a public issue instead of reaching out in private before.
I recommend you wait a week, to see how the discussion on julialang evolves, and whether a different "best practice" recommendation is found. RandomDevice has catastrophic thread-safety on old julia versions (everything before 1.3; to be fair, everything before 1.3 has limited threading support anyways), and maybe we find a better solution (i.e. a coding pattern that is more misuse-resistant). Code snippets tend to copy-paste diffuse everywhere, so it is good to be very defensive about that kind of thing.
Consider the this line.
Here, we use the base
rand
, which uses Mersenne twister. This is not a cryptographically secure random source.Per rfc6455, "The masking key needs to be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT make it simple for a server/proxy to predict the masking key for a subsequent frame."
After reading the websockets spec and the paper that lead to this requirement, this is not a severe problem. Still, would be better to fix this and use a secure random source.
A possibility could be to simply use
const CSPRNG = Random.RandomDevice()
.Cf general discussion here. Cf same issue in HTTP.jl.