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

WASI: define GSSAPI / TLS / QUIC as socket layer protocols #71

Open
npmccallum opened this issue Mar 27, 2019 · 11 comments
Open

WASI: define GSSAPI / TLS / QUIC as socket layer protocols #71

npmccallum opened this issue Mar 27, 2019 · 11 comments
Labels

Comments

@npmccallum
Copy link

@npmccallum npmccallum commented Mar 27, 2019

Crypto can never work on top of WASM. So these need to be system APIs.

Red Hat is already working on this. See the effort here: https://github.com/enarx/tlssock

We will be renaming this project shortly to cover the fact that we plan to support TLS, GSSAPI and (hopefully in the future) QUIC.

@maxmcd

This comment has been minimized.

Copy link
Contributor

@maxmcd maxmcd commented Mar 27, 2019

Just curious (not asking with a lot of knowledge), but why can crypto never work on top of WASM?

Is this a "crypto doesn't work in the browser" thing, or a "there is a fundamental issue with the WASM VM" type thing?

@npmccallum

This comment has been minimized.

Copy link
Author

@npmccallum npmccallum commented Mar 27, 2019

@maxmcd Cryptography is my day job (Red Hat). WASM is great, but it can never provide guaranteed side-channel protection. We can barely do that on bare-metal with hand-coded assembly. How can we know, at runtime JIT, if the JIT engine only uses constant time and constant cache instructions? Short answer: you can't.

@npmccallum

This comment has been minimized.

Copy link
Author

@npmccallum npmccallum commented Mar 27, 2019

@maxmcd I also forgot to mention that there are tons of things like crypto and network offloaders (think: Mellanox). The current situation is that supporting them requires kernel and application-level changes. Putting encrypted transport protocols under the socket layer allows applications to benefit for free.

@maxmcd

This comment has been minimized.

Copy link
Contributor

@maxmcd maxmcd commented Mar 27, 2019

@npmccallum makes so much sense, thanks!

@sunfishcode

This comment has been minimized.

Copy link
Member

@sunfishcode sunfishcode commented Mar 27, 2019

tlssock and the idea of building encrypted transport into existing socket APIs looks very interesting; thanks for the links! Would you be interested in sketching out what a WebAssembly API for that might look like?

In particular, do you think it makes sense to try to make this completely transparent to applications (possibly with the help of libc), or should we be thinking of this more as something that applications would explicitly opt into?

For completeness, there has been some research under the name "CT Wasm" to explore adding features to wasm to support constant-time guarantees. That said, it's reasonable to continue to design APIs that incorporate crypto in the platform.

@npmccallum

This comment has been minimized.

Copy link
Author

@npmccallum npmccallum commented Mar 28, 2019

@sunfishcode Absolutely. I plan to be very active in WASI.

TLSSock (soon to be renamed) is still fleshing out the API problem ourselves. But we aren't changing any ABI in Linux.

Transparent encryption is impossible (we know, we tried). Situations like certificate selection will always require application exposure. We also have the problem of relating DNS to name validation. What we can do is make it trivial for apps to support encrypted transports in their existing unencrypted application structure.

"CT Wasm" is not enough. Cryptographers used to worry about constant time. Now we worry much more about constant-cache. This isn't something that WASM can really control.

@sunfishcode

This comment has been minimized.

Copy link
Member

@sunfishcode sunfishcode commented Mar 28, 2019

@npmccallum Wonderful! I'm excited for the possibilities here.

@deian

This comment has been minimized.

Copy link

@deian deian commented Aug 2, 2019

Hey sorry to jump on this late.

"CT Wasm" is not enough. Cryptographers used to worry about constant time. Now we worry much more about constant-cache. This isn't something that WASM can really control.

Maybe I am misunderstanding what you mean by constant-cache, but CT-Wasm does prevent cache-based timing attacks by disallowing the use of secret values as indexes into memory.

@npmccallum

This comment has been minimized.

Copy link
Author

@npmccallum npmccallum commented Aug 2, 2019

@deian How do you propose to write WASM code that will never branch on any possible compiler with any possible optimizer? Such an implementation can never be FIPS certified.

@deian

This comment has been minimized.

Copy link

@deian deian commented Aug 2, 2019

CT-Wasm's type system (which extends Wasm's base type system with secrets) doesn't let you branch on secrets.

Sure, there could be an optimization pass that introduces a branch by undoing bit-arithmetic, but this is something you have to worry about GCC, etc. doing too. The extended type system should make it easy to check the optimization passes though: you should never be introducing branches on things marked secret.

@npmccallum

This comment has been minimized.

Copy link
Author

@npmccallum npmccallum commented Aug 4, 2019

@deian It remains to be seen if certification bodies will actually certify this. If they do, they may only certify a combination of WASM compiler in CT-WASM mode + crypto library + native compiler. And the time to certify this will be years and millions of dollars.

Regardless, I think there is significant value in providing a standard API for the crypto network protocols directly. These should be integrated with polling mechanisms, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.