Flaw Found in VPN Crypto Security
peeon writes "CNET reports the British National Infrastructure Security Coordination Centre has discovered a flaw in IPSEC protocol. From the article: 'The flaw, which the NISCC rates as "high" risk, makes it possible for an attacker to intercept IP packets traveling between two IPsec devices. They could then modify the encapsulation security payload--a subprotocol that encrypts the data being transported.'"
It's important to realize that you're only vulnerable to this issue if you're *not* doing integrity checking via IPSEC. Most major VPN infrastructures I run across use ESP with both confidentiality *and* integrity functionality enabled (some use AH as well). If that's the case for network x, then network x has nothing to fear from this.
Always read vulnerability details; people love to sensationalize stuff like this to the extreme.
dmiessler.com -- grep understanding knowledge
http://openvpn.net/
I was worried there for a second.
Ok, no I wasn't.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
This is a misleading writeup. The problem only shows up in certain configurations and is easily worked around. From TFA: Solution - - -------- Any of the following methods can be used to rectify this issue: 1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution. 2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done carefully: for example, the configuration where AH in transport mode is applied end-to-end and tunnelled inside ESP is still vulnerable. 3. Remove the error reporting by restricting the generation of ICMP messages or by filtering these messages at a firewall or security gateway.
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
"old news for nerds"
Slashdot is only as up-to-date as you make it. AFAIK the editorial team don't go looking for articles, they wait for YOU the reader to submit them.
If you want current news, you should participate in providing it.
Well, I guess it stands for Virtual Public Network now. ;)
More info here.
From the article it states clearly that it is a mode of ESP in tunnel mode that causes the problem NOT IKE (Internet Key Exchange) that is used for session setup.
Now the solution might be in IKE as in don't let IKE configure ESP without authentication - but this boys and girls is why you NEVER do encryption without authentication
I have mod points and I am not afraid to use them
Taken from the NISC website.
Solution
- - --------
Any of the following methods can be used to rectify this issue:
1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution.
2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done carefully: for example, the configuration where AH in transport mode is applied end-to-end and tunnelled inside ESP is still vulnerable.
3. Remove the error reporting by restricting the generation of ICMP messages or by filtering these messages at a firewall or security gateway.
My lame blog.
If you hand your credit card to the first person who walks past you when you're done eating, it may not be your waiter!
That's fine if you don't care about the security of your data. Current cryptanalysis indicates that at a minimum you want 16 rounds of ROT-13. And since I'm rather paranoid, as a rule I tend to double the recommendations of cryptographic primitives, so I use 32 rounds of ROT-13. With current CPUs as fast as they are, there's very little reason to use less than 16 rounds. And 2 rounds is just insanity.
I dare you to crack my data.
Jason.