A Kubernetes engineer's guide to mTLS | Hacker News Reader

A Kubernetes engineer's guide to mTLS

buoyant.io

38 pointsPagCat9 comments

Please include the one extra character that turns on `--fail` for curl, lest `HTTP/2 500\r\ncontent-type: text/html` sent right into a shell ruin some user's day

    curl -fsL run.linkerd.io/install | sh

and, while I can appreciate how slick it may look, in a post about mTLS including the protocol can save someone the coffee shop/hotel intercepting the request and violating the Authenticity tenant, to say nothing of, again, sending html into shell

    curl -fsL https://run.linkerd.io/install | sh

I didn't bother to read the relevant scripts, but it's very, very likely they contain bash-isms, in which case those other 2 characters can also lead to better outcomes:

    curl -fsL https://run.linkerd.io/install | bash

Funny, the point of TLS is to prevent MITM attackers from reading traffic. The two install commands provided would give a LAN or MITM attacker root on your host.

Can you be more specific? The short lifetimes of these certs should also help with that right?

I believe based on your "short lifetimes" comment that you're mixing up TLS, designed to guard against the coffee shop scenario with mTLS designed to guard against interacting with your bank.

In the coffee shop scenario, run.linkerd.io does not need to know who you are, but you need to ensure it is actually run.linkerd.io and not some rando with a DNS hijack running.

In the banking scenario, you need to know bank.example is the institution you think it is, and they need to know who you are in order to only allow you access to the assets that are rightfully yours

My comment was actually only mildly related to the mTLS content of the article, and more an observation of "good tutorial habits makes for good security habits in readers," especially when the changes are so minor as compared to their benefit

Unfortunately no - the curl commands will by default go out over http, which does not use TLS at all or provide any guarantee of remote server integrity, just like plain TCP.So an attacker with the right network posture (say, they pwned your router or a hop between you and these servers, can just reply with plain HTTP and give you code that you will run.

Like op said, just tack on -f and https://, and remember to do this in the future.

Thanks, I updated the curl command-line args.

Just published this earlier this morning. Would love your comments and corrections. TLS is a huge topic and I'm sure I got something wrong in here.

What about traffic that isn't HTTP? Does Linkerd helps authenticate that, perhaps by setting up a tunnel?

Non-HTTP TCP traffic will be mTLS'd by Linkerd just as well as HTTP traffic is, as long as there's a proxy on both ends of the connection. No tunnel required.

Reply on news.ycombinator.com