Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Websockets uses insecure random for mask #152

Open
chethega opened this issue Aug 18, 2019 · 2 comments
Open

Websockets uses insecure random for mask #152

chethega opened this issue Aug 18, 2019 · 2 comments

Comments

@chethega
Copy link

chethega commented Aug 18, 2019

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.

@chethega chethega changed the title Websockets uses insecure random for Sec-WebSocket-Key and mask Websockets uses insecure random for mask Aug 18, 2019
@hustf
Copy link
Collaborator

hustf commented Aug 18, 2019

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.

@chethega
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants