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

TLS #25

Closed
aturon opened this issue Nov 8, 2018 · 8 comments
Closed

TLS #25

aturon opened this issue Nov 8, 2018 · 8 comments
Labels
feature A feature that's ready for implementation

Comments

@aturon
Copy link
Collaborator

aturon commented Nov 8, 2018

Add support for TLS.

@aturon aturon added the feature A feature that's ready for implementation label Nov 8, 2018
@davidbarsky
Copy link

A small data point: At work, we've been pushing folks to use and out-of-process proxy (very similar to Envoy) that handles TLS termination. That system handles a lot of complexity for people. It might be worth telling folks using Tide to heavily consider not handling TLS themselves and instead outsource it to a system like Linkerd, Envoy, or their cloud provider's hosted load balencer.

@yoshuawuyts
Copy link
Member

yoshuawuyts commented Nov 8, 2018

The tls-api crate seems very intriguing: it's a TLS trait with multiple backends that can be swapped out. It seems like a pretty cool idea, but it's unclear if it's actively maintained.

Other options for TLS would include:

@skade
Copy link
Contributor

skade commented Nov 8, 2018

Interestingly, while I agree that deployment usually works well through terminating/offloading proxies, TLS support during development is an incredibly nice thing to have, catching many errors on https deployments early.

@prasannavl
Copy link
Contributor

It might be worth telling folks using Tide to heavily consider not handling TLS themselves and instead outsource it to a system like Linkerd, Envoy, or their cloud provider's hosted load balencer.

I don't really see why this direction has to be taken. While it is a common practise in edge services, I don't see why Tide has to be deployed with another proxy just for TLS in simplified infrastructures, where a side car pattern is not desired.

While I don't see Tide being deployed on the edge any time soon, I do think Tide without a sidecar pattern in infrastructures that desire secure internal communication is a highly valid use case and should be supported from the beginning.

@Darkspirit
Copy link

Darkspirit commented Nov 28, 2019

https://github.com/async-rs/async-tls ❤️

@yoshuawuyts
Copy link
Member

@Darkspirit we should probably provide support for TLS out of the box though; but async-tls definitely seems like the right starting point!

@yoshuawuyts
Copy link
Member

yoshuawuyts commented Nov 12, 2020

Note from triage: we now have https://github.com/http-rs/tide-rustls! -- we want to build a native version of this as well, so that we can compare both and then move them into Tide proper.

edit: this would become a lot simpler if we can merge async-native-tls and async-tls into the same crate.

@yoshuawuyts
Copy link
Member

After more conversation: the integration with tide will likely be a re-export of the tide-rustls; which means that that UX is about the same. We'll look to merge the crate with Tide proper at some point, but we have a solution now so closing this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A feature that's ready for implementation
Projects
None yet
Development

No branches or pull requests

6 participants