3 ms·

>TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems I beg to differ. What'

by hueving 12y ago

>TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems I beg to differ. What's we've seen is non-stop problems from implementation mistakes when it comes to all of the extra extensions. Maybe this indicates there would be a market for an opinionated TLS embedded library... >On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Static keying issues aren't unique to IPsec, they occur with every symmetric cipher. There is nothing stopping you from having a management tool that rotates the static key based on a master key and the day. Or if you want to send updated keys, you just encrypt them and send them over the IPsec connection using GPG or whatever your asymmetric choice is. >Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.) I'm sorry for saying this, but that's what every single person that has implemented a broken protocol thinks. It's true that it's not hard to get one that encrypts and decrypts. The trick is getting one that doesn't leak any information. There is basically know way to know that without an extensive analysis by the entire crypto community. Look at how long TLS has existed and they are still just finding issues now. RC4 is another example of one that looked pretty good for quite a while and then fell under scrutiny. Do you really think you are smart enough to know everything the entire crypto community knows?

tptacek 12y ago
It's really not true that most of TLS's problems are implementation-based. Problems that had nothing to do with implementation: * CRIME, which conceptually breaks the way TLS wants to handle compression * POET, which is an oracle attack against the way TLS does CBC * BEAST, which exploits IV chaining in the TLS CBC construction * The RC4 flaws break one of the most popular TLS ciphers, which was ill-advisedly included in SSL3/TLS I could probably go on. For instance, the JSSE Bleichenbacher flaw looks like an implementation issue today, but it's an implementation that fails to perfectly implement a clumsy countermeasure TLS builds in to Bleichenbacher's P1v15 attack which TLS was originally totally susceptible to. These aren't "implementation extensions"; this is core functionality. Heartbleed was an implementation flaw. TLS's security record is much worse than just the implementation flaws. You're actually unlikely to experience lots of Heartbleed-like flaws implementing TLS in a safe language, and equally likely to have them implementing something different in C.

by hueving 12y ago

tptacek 12y ago

It's really not true that most of TLS's problems are implementation-based. Problems that had nothing to do with implementation: * CRIME, which conceptually breaks the way TLS wants to handle compression * POET, which is an oracle attack against the way TLS does CBC * BEAST, which exploits IV chaining in the TLS CBC construction * The RC4 flaws break one of the most popular TLS ciphers, which was ill-advisedly included in SSL3/TLS I could probably go on. For instance, the JSSE Bleichenbacher flaw looks like an implementation issue today, but it's an implementation that fails to perfectly implement a clumsy countermeasure TLS builds in to Bleichenbacher's P1v15 attack which TLS was originally totally susceptible to. These aren't "implementation extensions"; this is core functionality. Heartbleed was an implementation flaw. TLS's security record is much worse than just the implementation flaws. You're actually unlikely to experience lots of Heartbleed-like flaws implementing TLS in a safe language, and equally likely to have them implementing something different in C.