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

We do not have perfect forward secrecy #707

Open
yaronyg opened this issue Apr 8, 2016 · 2 comments
Open

We do not have perfect forward secrecy #707

yaronyg opened this issue Apr 8, 2016 · 2 comments
Labels
Milestone

Comments

@yaronyg
Copy link
Member

@yaronyg yaronyg commented Apr 8, 2016

To actually connect two devices we use data from the discovery process to generate a secret that is then used with TLS PSK. Ideally we should be able to provide perfect forward secrecy. But the algorithm used to generate the PSK uses static entries based on the device's public keys. This means that an attacker can record a TLS session and if the attacker can later get one of the devices to give up its public key it should be possible to regenerate the secret and retrieve the session contents.

We were well aware of this threat when the discovery system was designed and our assumption was that we would use one of the TLS PSK cipher suites that provides perfect forward secrecy by introducing an extra set of ephemeral keys. Any of the ECDHE_PSK_* suites would do nicely.

The problem is that the version of OpenSSL used in JXcore is so old that it doesn't support any of those suites!

The only sane solution to this problem is to upgrade the OpenSSL version we use with JXcore to one that supports an appropriate cipher suite.

If anyone suggests adding perfect forward secrecy to the discovery protocol directly rather than using the existing facilities in OpenSSL please ask them to consider a different line of work than security. We already committed a grave sin by implementing the Discovery cryptographic protocol (we didn't have a choice, there is literally nothing available off the shelf to match it), extending it to support forward secrecy would just be irresponsible. This is a complex area and we need to take advantage of existing, well tested code. Not inventing our own solutions.

@yaronyg
Copy link
Member Author

@yaronyg yaronyg commented Jul 14, 2016

Once #741 is resolved then hopefully this bug goes away.

@yaronyg yaronyg added estimate - 2 and removed jxcore labels Jul 14, 2016
@yaronyg yaronyg added this to the V1 milestone Aug 3, 2016
@yaronyg yaronyg added 1 - Backlog and removed 0 - Icebox labels Aug 4, 2016
@yaronyg
Copy link
Member Author

@yaronyg yaronyg commented Aug 8, 2016

We either get this for free because we get the right cipher suite or we can't do it.

@yaronyg yaronyg added Node and removed 1 - Backlog labels Oct 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.