🧵 ...

With the time, Canonical has grown and created internal structures as a big-tech, especially how employees are evaluated. With my mostly external work I got a victim of it and they laid me off. All my colleagues do not really understand why I got fired, as they consider my work really important. Got ~30 "I am really sad that you have to go, you do not deserve it, you are doing great work" answers to my good-bye e-mail

... 🧵

#OpenPrinting #LinuxFoundation #getfedihired

imagine you have two computers, one trusted while the other runs untrusted code. the trusted one holds authentication credentials to some server that the other one wants to connect to, and you don't trust the other one enough to let it have the credentials too. so let's say you want the trusted computer to send the credentials and then hand the authenticated connection off to the untrusted computer.

in principle you might be able to play games at the TCP/IP layer to open a socket on one machine and then transfer it to the other. you could also proxy all traffic through the trusted computer, at the cost of CPU time and latency. let's say you don't want to do either of those things.

instead, you might have the untrusted computer open the connection to the server; have the trusted computer proxy through it to authenticate the connection and then disconnect and get out of the way. but of course now the untrusted computer gets to see that authentication traffic, including the credentials we didn't want to reveal.

so! let's use TLS to encrypt the connection. initially the trusted computer is responsible for establishing the TLS session. it's okay to have the untrusted computer proxy that traffic as long as the trusted computer fully validates the server's certificate; we've essentially created a MITM attack which TLS is meant to be secure against. now we can send credentials without the untrusted computer being able to sniff them.

next we need to hand the TLS state over to the untrusted computer so it can take over the connection. this is supported in various TLS libraries to enable using things like Linux kTLS, where userspace does the initial handshake but then the kernel, perhaps with hardware acceleration, handles all the cryptography for the rest of the session. it requires handing over the session keys and a bit of other state; not particularly complicated.

but wait: these are the keys we just used to encrypt the credentials that we were trying to keep secret. if we give them to the untrusted computer it can go back and decrypt the traffic that we just passed through it!

the trick is that TLS supports re-keying the connection at the request of either end. so once the credentials are sent, the trusted computer can trigger re-keying, causing both ends to throw away their keys and start using new ones. these new keys are then safe to hand off to the untrusted computer because they haven't been used to encrypt anything yet.

note that the server does not need to know any of this is happening; from its point of view, this is a perfectly normal TLS connection, with only the slight oddity of a re-key happening once before it was strictly necessary. only the two client computers need to take special steps to cooperate to make this work.

is this a good idea? eh, I dunno. should you trust me to have gotten the security case right? hell no, use this at your own risk. but I had fun thinking it through.