[tptacek]

Heartbleed isn't a TLS vulnerability any more than an overflow in GnuTLS is.

The threshold question is, "could this vulnerability be reasonably expected to recur in independent implementations of the protocol?"

As for stripping back TLS 1.1 --- it wouldn't take much more than simply picking a single ciphersuite and requiring TLS 1.1. You wouldn't need to know, for instance, about export ciphers.

[cperciva]

That seems like the wrong question. My options were "write my own protocol" or "use openSSL" -- writing my own TLS stack was never on the table.

[tptacek]

Right, I get that, but you could have done the two config things I just mentioned with OpenSSL.

I get why you didn't use OpenSSL. The normal thing for someone like you to do in 2022 would be to use Noise.

[alipitch]

What are real world implementations of the Noise Protocol? https://github.com/noiseprotocol/noise_spec/blob/v34/noise.m...

Quick search shows WireGuard protocol, but I am not sure if how much of the WireGuard protocol is the same as the Noise Protocol.

https://www.wireguard.com/formal-verification/ https://www.wireguard.com/papers/wireguard-formal-verificati...

  The WireGuard protocol is extensively detailed in [2], which itself is based on the NoiseIK [3] handshake.

[alipitch]

I found a page by Duo Labs listing Noise in Production.

https://duo.com/labs/tech-notes/noise-protocol-framework-int...

  Noise is used today in several high-profile projects:
    WhatsApp uses the "Noise Pipes" construction from the specification to perform encryption of client-server communications
    WireGuard, a modern VPN, uses the Noise IK pattern to establish encrypted channels between clients
    Slack's Nebula project, an overlay networking tool, uses Noise
    The Lightning Network uses Noise
    I2P uses Noise

[tptacek]

There's a bunch of them, but part of the point of Noise is to be extremely prescriptive in order to simplify implementation. WireGuard is based on Noise, but has a lot more than just Noise in it.