Proxy Transparency about linkerd2 HOT 5 CLOSED

use HTTP1 with an Upgrade header to allow upgrading to HTTP2.

Is any application actually using HTTP1 with an Upgrade header to HTTP2? I am skeptical that it is worthwhile to spend time on this unless we see some evidence it is actually done in the real world. I've literally never seen it done IRL.

from linkerd2.

accept-side

Let's distinguish between the two cases of accept-side traffic: public traffic from outside the pod, and private traffic from the service within the same pod that the proxy is in. I agree that the plan makes sense w.r.t. the private traffic we accept from the service within the same pod as the proxy. And I agree in the short term it is OK for the public traffic from outside the pod. However, in the long term I think the plan makes less sense.

In particular, the long-term plan is to provide automatic TLS and to enforce that TLS is used by default. That means that, in the long term, absent any annotations, we need to reject any non-TLS public traffic. While the annotation to opt into accepting non-secure public traffic could be a boolean flag, if the user has to add an annotation for plaintext traffic to work anyway, we might as well make the annotation value be the name of the plaintext protocol: HTTP or whatever. Then we wouldn't have to do the sniffing on the public listener, which would be better for security, predictability, and reliability.

from linkerd2.

The destination service would be updated to report back hints about what protocols a destination supports. A proposed new destination service:

Do we really need to have per-address protocols? Let's see a motivating example if so. The destination service was designed to be zero-trust like DNS; that is, even if the Destinations service lies to the proxy, there will be no security problem (w.r.t. TLS). This new design proposes Destinations to become a highly-trusted service because it would control whether we attempt to secure the connection with TLS or not.

Although I may be missing some of the target use cases, as far as I understand things now it makes more sense for there to be a Protocols service that maps every Authority to a (Scheme, Authority). Then the Destination lookup would map (Scheme, Authority) to (IpAddr, Port); i.e. Scheme would be an input to Destinations, not an output of Destinations.

from linkerd2.

@seanmonstar What should we do with this issue? GitHub says 0/13 tasks have been done but that seems far from accurate: new tasks were identified and many tasks were already done. Should we just close this in favor of having a separate GitHub issue for each currently-outstanding issue?

from linkerd2.

I'd say this could be closed, as it is not an accurate record of how this was implemented.

from linkerd2.