On 04/08/14 10:13, Erik Anderson wrote: > On Tue, Apr 8, 2014 at 10:09 AM, Ryan Coleman <ryanjcole at me.com> wrote: > >> So... yeah. I put my stuff on a non-performing port anyway. That should keep >> it "ok" for a little bit. This is good, provided your attacker can't sniff traffic. SSL/TLS handshakes are pretty trivial to search for, regardless of the port. Depending on what you're protecting, I would not feel safe relying on this alone. > Anyway, I imagine if you were using certifiate auth only for OpenVPN you'd > be hosed. I have xauth enabled, though, so it requires client cert + > username/password, which I'm assuming gives me a bit of extra insulation > from heartbleed. This is good, but according to heartbleed, an attacker could potentially force the server to disclose private keys. If they have the private key, then they can decrypt the transmission between the client and server. So to them, your xauth user/pass handshake would be basically clear text. They could sniff the connections and wait for a new user and then have full access. :( > It will be interesting to hear pfsense's response to this. I haven't seen > anything from them yet. This is a very serious bug, and I would highly recommend disabling the OpenVPN until pfSense sends out an update, which I'm guessing won't take too long. If this was just a website, or smtp server or something, you could probably get by longer. The script kiddie crowd will be after them, maybe suffer some defacement or something. But the nature of VPN, giving an external entity access to internal resources, this is where the real attackers will be focusing on, and there's usually a lot more risk involved when VPNs fail. It's probably better to suffer the downtime and be safe, than have it working and risk a major breach. That's my two cents. Chris Frederick