Hacker News Reader

Comment by patrickmn | Hacker News Reader

Metadata leakage aside: If you run a parser on unauthenticated input, bugs in your parser can be exploited. This is partly why mac-then-encrypt is a bad idea (you have to decrypt to verify the MAC.)

View on HN

One could take the view that a full TLS stack is so complicated that it is much more likely to contain exploitable flaws than some simple signature checking code.

Undoubtedly true, assuming you use something well-scrutinized like signify or gnupg for that signature verification.

There are plenty of off the shelf TLS stacks, but people tend to end up hand-rolling their own signature validation code badly.

And all of them are universally terrible and a MAJOR hassle to integrate with any embedded system. If you read mbedTLS or PolarSSL run far far away.

Maybe people hand-roll their own signature validation code badly, but those same people will just as much screw up or plain disable the CA verification.

If you have the knowledge to use the primitives from something like NaCl, you have nothing to gain from using a full TLS stack but pain building, upgrading, programming your firmware and massive middleware problems in the field. And when they inevitably find issues in the TLS stack you used, your device is now fucked since there is no virtual address space, W^X, even stack cookies..

There's a parser on unauthentic input either way. Given the choice to do it online with NSS or OpenSSL or offline with the same library, I think it's a hair safer to do it offline---but this will be swamped by other factors particular to the project.

Yeah, don't get me wrong. Not implementing TLS because you're worried about attack surface is a bad idea. But if all you're doing is verifying a gpg signature on some firmware, a TLS stack is probably overkill.

> Not implementing TLS because you're worried about attack surface is a bad idea.

[citation needed]

If you're doing things that should be done over an encrypted channel, but forego TLS (or a suitable alternative like Noise Framework or WireGuard) because it adds attack surface, you are adding more risk than you are removing. A better solution would be to separate the parts of the stack that are sensitive from the parts that do things that you don't trust/are not in your control. This could be openbsd/POSIX style separation between your sensitive and the TLS-terminating process, or ideally placing them on completely separate machines. (Just make sure you trust your internal network if you aren't going to encrypt traffic on the inside...)

Reply on news.ycombinator.com