4 ms·

This is true. Also, as someone who also works on network crypto boxes: the main VPN protocols are _really_ nasty. - OpenVPN requires TLS (you really don't want

This is true. Also, as someone who also works on network crypto boxes: the main VPN protocols are _really_ nasty. - OpenVPN requires 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, is completely infeasible to implement from scratch, and does not have any implementations useful for a high-security embedded device. Also, the data channel protocol is ugly. - DTLS-based VPNs are, well, DTLS-based (worse protocol than TLS, and still infeasible to implement). - IPsec is comparatively sane if you limit yourself to statically-keyed tunnel-mode ESP with no internal NAT'ing (NAT-T is ok, though). IKE is a pain (and usually requires certificates, which are very hard to parse correctly), and supporting all the zillions of options is extremely expensive. On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Also, IPsec overhead usually ends up being rather high in practice, and e.g. IPsec/L2TP is even worse. - In practice, anything that requires connection negotiation requires some surgery to support high-packet-loss scenarios. (Loss-tolerant protocols over statically keyed IPsec work decently well at packet loss rates that break most IKE implementations.) Also, for any given device, you'd usually prefer to support as few algorithms as possible and/or tailor choose crypto primitives that are well-supported on your hardware. Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)

bdamm 11y ago
These are all very good points. In addition: * We really care about on-the-"wire" efficiency. So we like having control over that. * We actually looked very hard at DTLS, and do support it, but it is still optimized for browsers and not devices and as such carries some thought-baggage that is tricky to work around. So DTLS doesn't carry the bulk of our traffic. * IPSec turned out to be impossible to support at the back end. Equipment that supports IPSec tunnel termination often is sold in terms of tens of thousands of tunnel terminations per box. We need tens of millions. That scale does not work for us. We do use it in some specific circumstances though. * Anything that requires TCP is a non-starter as well. Not at all for the same reasons as the QUIC people. The NoTCP joke was really funny to me.
hueving 11y 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 11y 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.

bdamm 11y ago

These are all very good points. In addition: * We really care about on-the-"wire" efficiency. So we like having control over that. * We actually looked very hard at DTLS, and do support it, but it is still optimized for browsers and not devices and as such carries some thought-baggage that is tricky to work around. So DTLS doesn't carry the bulk of our traffic. * IPSec turned out to be impossible to support at the back end. Equipment that supports IPSec tunnel termination often is sold in terms of tens of thousands of tunnel terminations per box. We need tens of millions. That scale does not work for us. We do use it in some specific circumstances though. * Anything that requires TCP is a non-starter as well. Not at all for the same reasons as the QUIC people. The NoTCP joke was really funny to me.

hueving 11y 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 11y 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.