4 ms·

This should be interesting for OpenVPN.

by rdl 12y ago

peterwwillis 12y ago
I think people underestimate how many products use OpenSSL... http://www.pcworld.com/article/2143440/server-makers-rushing-out-heartbleed-patches.html http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartbleed-bug-hits-at-heart-of-many-cisco--juniper-products.html http://www.networkworld.com/article/2176022/router/heartblee... It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.
- woodrow 12y ago
  OpenVPN already sort of supports this: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).
- syzzer 12y ago
  You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do). OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.
  - peterwwillis 12y ago
    Since tls-auth merely creates an HMAC around all the TLS message types, it makes me wonder if there's still an aspect of initiating a TLS connection (or flaws in the HMAC generation?) that could leave tls-auth vulnerable to future TLS-related flaws. But that could be excessive paranoia.
    - agwa 12y ago
      I think that whether tls-auth protects you against CCS Injection will hinge not on the HMAC but on tls-auth's replay protection. An attacker can always replay a previously-sniffed CCS packet with a valid HMAC, so it all comes down to whether that replay will be properly discarded.
      - JoachimSchipper 12y ago
        tls-auth does prevent replays: note the "packet-id for replay protection" at http://openvpn.net/index.php/open-source/documentation/security-overview.html http://openvpn.net/index.php/open-source/documentation/secur.... OpenVPN does a pretty good job, as long as you choose a sane configuration (most importantly, use tls-auth and TLS key negotiation). It's definitely less vulnerable than other TLS stuff due to the tls-auth option. (Full disclosure: my company provides the hardened OpenVPN-NL, and I've done a little work on that.)
mdtancsa 12y ago
CVE-2014-0224 is the only one that really impacts OpenVPN (No DTLS nor SSL_RELEASE_BUFFERS etc) and as others have said, if you are using OpenVPN chances are you are making use of TLS-AUTH which helps mitigate MITM issues to a reasonable degree. Furthermore, both sides apparently need to be vulnerable. So if you have little control over the clients, updating the server seems to be adequate to address this specific bug.

This should be interesting for OpenVPN.

by rdl 12y ago

This should be interesting for OpenVPN.

I think people underestimate how many products use OpenSSL... http://www.pcworld.com/article/2143440/server-makers-rushing-out-heartbleed-patches.html http://www.pcworld.com/article/2143440/server-makers-rushing... http://www.networkworld.com/article/2176022/router/heartbleed-bug-hits-at-heart-of-many-cisco--juniper-products.html http://www.networkworld.com/article/2176022/router/heartblee... It sounds kind of stupid, but i'm thinking the best short-term way to secure an exposed OpenVPN tunnel against future OpenSSL TLS holes may be two layers of encrypted traffic. One static key tunnel to prevent public TLS holes from exposing the installation, and inside that a strong TLS 1.2 implementation with perfect forward secrecy. It's lame and limited (due to the requirement on the static key) but could work for black-box implementations where you don't have much choice in your use of the product. Some cheap hacks to the source of OpenVPN may even allow both of these to be stacked without requiring two tunnels.

woodrow 12y ago
OpenVPN already sort of supports this: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... While it does not provide additional encryption, it does prevent clients who do not know the secret from initiating connections (and thus interacting with the TLS state machine/etc).
syzzer 12y ago
You don't need another layer of encryption, just another layer of authentication protects you from attacks that require an active mitm adversary (as basically all attacks on TLS do). OpenVPN has offered such an option for a long time: https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth https://community.openvpn.net/openvpn/wiki/Hardening#Useof--... This wraps just the TLS control channel, which has low traffic and thus results in a small overhead. The data channel is separated from TLS in OpenVPN, which is why TLS-auth does not add overhead to the actual network packet encapsulation. TLS-auth is a neat feature and everybody should use it.
- peterwwillis 12y ago
  Since tls-auth merely creates an HMAC around all the TLS message types, it makes me wonder if there's still an aspect of initiating a TLS connection (or flaws in the HMAC generation?) that could leave tls-auth vulnerable to future TLS-related flaws. But that could be excessive paranoia.
  - agwa 12y ago
    I think that whether tls-auth protects you against CCS Injection will hinge not on the HMAC but on tls-auth's replay protection. An attacker can always replay a previously-sniffed CCS packet with a valid HMAC, so it all comes down to whether that replay will be properly discarded.
    - JoachimSchipper 12y ago
      tls-auth does prevent replays: note the "packet-id for replay protection" at http://openvpn.net/index.php/open-source/documentation/security-overview.html http://openvpn.net/index.php/open-source/documentation/secur.... OpenVPN does a pretty good job, as long as you choose a sane configuration (most importantly, use tls-auth and TLS key negotiation). It's definitely less vulnerable than other TLS stuff due to the tls-auth option. (Full disclosure: my company provides the hardened OpenVPN-NL, and I've done a little work on that.)

mdtancsa 12y ago

CVE-2014-0224 is the only one that really impacts OpenVPN (No DTLS nor SSL_RELEASE_BUFFERS etc) and as others have said, if you are using OpenVPN chances are you are making use of TLS-AUTH which helps mitigate MITM issues to a reasonable degree. Furthermore, both sides apparently need to be vulnerable. So if you have little control over the clients, updating the server seems to be adequate to address this specific bug.