Slashdot Mirror

← Back to Stories (view on slashdot.org)

Flaw Found in VPN Crypto Security

Posted by Zonk on from the dire-straights dept.

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.'"

106 comments

  1. Hype Warning by danielrm26 · · Score: 5, Informative

    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
    1. Re:Hype Warning by whoever57 · · Score: 3, Interesting

      Does this mean that it DOES apply to IPSEC VPNs that are configured with NAT Traversal?

      --
      The real "Libtards" are the Libertarians!
    2. Re:Hype Warning by pocketfullofshells · · Score: 1

      Good one danielson...

      Quick, all you psuedo-pro's get out your VPN cheat sheet and study up!

      oh yeah, and RTFA!!!

    3. Re:Hype Warning by Facekhan · · Score: 1

      Is your vulnerability reduced or eliminated by encapsulating your IPSEC tunnels in GRE tunnels?

    4. Re:Hype Warning by Anonymous Coward · · Score: 0

      Yes, you are correct.

    5. Re:Hype Warning by God!+Awful+2 · · Score: 2, Informative

      Does this mean that it DOES apply to IPSEC VPNs that are configured with NAT Traversal?
      Sure, if you disable authentication. But there's nothing specifically related to NAT traversal.

      -a

      --
      /. users can't
    6. Re:Hype Warning by m0rningstar · · Score: 4, Informative

      No ... all NAT traversal does is to wrap the ESP packet in a UDP packet (to the best of my understanding, at any rate).

      So if you have the integrity trailer turned on -- which, as the original poster said, is good practice -- it should make no difference if it's a raw ESP packet or an ESP packet in the payload of a UDP packet.

      There also look to be some fairly large technical difficulties with implementing the attack, not the least of which is that you have to bit flip arbitrarily to recover the data and depending on your SA lifetime that might not be terribly productive.

      Yes, it's a flaw in IPSec and that's bad, but I think it's technically a very difficult attack AND relatively easy to work around.

    7. Re:Hype Warning by God!+Awful+2 · · Score: 1

      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.
      What you say is true.

      Another thing that hasn't been mentioned is that most VPN boxes would use SPD checking to verify that the IPs of packets coming out of the tunnel matches what was negotiated. Probably the packets can only get redirected to someone who was already on your network. (There are better ways to handle that -- ARP poisoning...)

      -a

      --
      /. users can't
    8. Re:Hype Warning by hal9000(jr) · · Score: 1

      Is your vulnerability reduced or eliminated by encapsulating your IPSEC tunnels in GRE tunnels?

      First, why would you want to encaps IPSec into GRE? And no. It is a flaw in ESP.

    9. Re:Hype Warning by pocketfullofshells · · Score: 1

      you know, the a on my keyboard is right next to the o if you go from left to right. must have been a typo.

    10. Re:Hype Warning by God!+Awful+2 · · Score: 1

      Yes, it's a flaw in IPSec and that's bad, but I think it's technically a very difficult attack AND relatively easy to work around.
      No, it is not a flaw in IPsec. It is simply a misconfiguration. IPsec is a very flexible protocol, and it has been both praised and criticized for that fact. The upside is that you can choose to use whatever crypto algorithms you want. The downside is that you may choose a dumb combination.

      -a

      --
      /. users can't
  2. Whew... by grasshoppa · · Score: 4, Informative

    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!
    1. Re:Whew... by Linker3000 · · Score: 2, Informative

      Good call - OpenVPN is a good package.

      --
      AT&ROFLMAO
    2. Re:Whew... by Tack · · Score: 2, Insightful
      I'm going to chime in with a definite "me too" here. I've been using OpenVPN for over a year, and this is absolutely solid software. It easily falls into the Just Works category. I have it started on boot, and I simply forget that it's there. If there are network issues, it recovers gracefully.

      I can't quite speak to its security, but there's nothing I've seen that makes me the least bit concerned. Although Peter Gutmann didn't do a real audit of openvpn, he did have this to say about it: "... but a quick look through it indicates that the author knows what he's doing." After you read a few remarks made by cryptographers, something like "this person is not a moron" is exceptionally high praise.

      And Gutmann did leave us with this memorable quote: "Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment."

      If you need a vpn solution that Just Works, check out OpenVPN.

      Jason.

    3. Re:Whew... by halfelven · · Score: 1

      OpenVPN:
      Easier to configure than most if not all IPSec-based solutions.
      Provides pretty much the same functionality, except for obscure bells and whistles.
      Has similar, if not better, security.
      Runs on pretty much all important platforms.
      Has a GUI for Windows, so that even dummies can use it.
      It Simply Works (TM).

      I will never go back to IPSec.

    4. Re:Whew... by jascat · · Score: 1

      Yet another to add to those singing praises for OpenVPN. I had a setup with a friend between a linux box and a sparc running solaris. The linux box was setup to initiate the connection and the solaris box had openvpn startup via inetd. The linux box had a cronjob to do a pgrep for openvpn every few minutes and start it up if it weren't running. If there were ever any connection issues on my side or his, the tunnel would be initiated again as soon as the connectivity was restored. It was so much easier than IPSec and didn't care about NAT at all. If I ever need another VPN tunnel, OpenVPN will be it.

    5. Re:Whew... by Anonymous Coward · · Score: 0

      Just because noone has discovered them yet, doesn't mean that there are no flaws and OpenVPN is rock solid. In fact, if history is any indication, it would not be surprising to find serious problems. The developer of OpenVPN did make an excellent choice to base it off of well tested technology (SSL), but his infrastrcture around SSL is his own creation..

      IPSec, on the other hand, was designed and reviewed by a large number of experts in security. It continues to go through a lot of review, and constant attempts to break it.

      The fact that this "exploit" qualifies as news gives me more confidence in the security of IPSec. Basically, all it says is "If you configure IPSec in a very unusual way, disabling half of the security, as the designers of IPSec and sellers of IPSec products tell you not to, there is a potential security issue". This is a non-issue.

    6. Re:Whew... by Tack · · Score: 1
      IPSec, on the other hand, was designed and reviewed by a large number of experts in security. It continues to go through a lot of review, and constant attempts to break it.

      I can't argue with this. But IPsec's biggest enemy is its own complexity. I've read enough about IPsec and it scares the shit out of me. Sure, I can set it up and see that it works (and have done so). But to really understand what's going on would take a me a solid week (probably more) of research, and even then there's no guarantee I'd really grok it.

      In contrast, OpenVPN's protocols like its key exchange (which is the primary "infrastructure built around SSL" as you put it) is fairly straightforward to understand. Now I'm not saying they're secure because I don't know; I'm not a cryptographer. But getting the architecture of a system fully in your head is a prerequisite to understanding its security implications. Modularization helps here, and this is where openvpn shines. IPsec digs its fingers into many different layers, with quite complex relationships between them.

      IPsec has received a lot more review than openvpn, but it also needs it. IPsec probaby solves some more esoteric problems than openvpn can, but when all I need is a simple, secure tunnel between two points, I'll continue to recommend OpenVPN.

      Cheers,
      Jason.

    7. Re:Whew... by cduffy · · Score: 2, Insightful

      Spin it however you like -- but read this.

      OpenVPN's security model is quite strong -- as documented in the FAQ, it borrows heavily from preexisting (time-tested, heavily reviewed) protocols (not just SSL but ESP as well), and supports multiple layers of security (ie. "tls-auth", a pre-shared key authenticating all traffic; support for running unprivileged and within a chroot jail to prevent OS-level security breaches; etc). Further, the (limited region of) code which handles pre-authentication network traffic is heavily audited.

      There has been analysis resulting in security vulnerabilities found; these have exclusively been related to misconfiguration, and even in those cases the daemon now spits out a warning when it detects such misuse. Certainly, OpenVPN hasn't garnered the level of direct review (as opposed to inderect review of components it borrows) that IPsec has -- but I'm confident in its security. Certainly, the other homegrown userspace VPNs all have serious issues -- but notably, those issues have by and large been pointed out, whereas OpenVPN's security model has had no serious flaws documented despite significant popularity.

      OpenVPN has a number of other advantages as well -- plays nice with NAT, tunnels over almost any network, no interop issues (since there's just one implementation that runs anywhere), etc.

    8. Re:Whew... by MikeBabcock · · Score: 1

      No offence intended, but I'll stick to security systems designed by experts. "Borrowing" techniques from experts is great, but its a far cry from being one.

      Consider that the average person rewiring their own home often doesn't know of the dangers of having polarity reversed on outlets despite knowing how to use a screwdriver and knowing that grounding is important.

      Consider that those who do know about polarity issues might not know about the heat dissipation limitations of various sizes of box for the wires causing potential house fires.

      Those who are aware of heat dissipation issues of 1-gang boxes (and those are rare) often still run wiring through insulation or ventilation systems without proper jacketing.

      There are a *lot* more mistakes to be made in large number cryptography and security software than there are in wiring a house.

      --
      - Michael T. Babcock (Yes, I blog)
    9. Re:Whew... by cduffy · · Score: 1

      There are a *lot* more mistakes to be made in large number cryptography and security software than there are in wiring a house.

      True.

      Notably, while OpenVPN's core is documented well enough to allow peer review of its design, and the code is clean enough to allow for easy desk checking, I haven't seen a single 3rd-party patch to the crypto portions submitted or accepted. As such, it's not such an amateur effort as you perhaps make it out to be -- there's a single author of the core, and to the best of my limited knowledge said author has made maintaining said software his full-time job since 2002 [AFAIK, and that *is* a limited extent, the contract work he does these days is focused around OpenVPN], and his design decisions have so far stood up to all scrutiny.

      Did you follow the ML post I linked? In short, I submit that the sensitive parts of OpenVPN are written by an expert. Granted, further peer review would still be a Good Thing -- but I'm confident in the software as it stands.

    10. Re:Whew... by MikeBabcock · · Score: 1

      While I have no evidence to suggest that OpenVPN actually has any such bugs, many crypto software bugs have been highly obscure even in well-designed packages. Consider the with/without compression issues for PGP/SSH in the past, or initialization vector selection issues, or how memory is handled (protection, swapping, etc.)

      Getting crypto right requires a lot of thought, that's all. I'm sure OpenVPN works well for you, but I'll stick to ipsec for now.

      --
      - Michael T. Babcock (Yes, I blog)
  3. Nonsense by Cally · · Score: 5, Informative

    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
    1. Re:Nonsense by matman · · Score: 1

      I agree.

      Not only that, but this is as designed. If you want to guarantee the integrity of the ESP payload, you've got to turn on integrity guarantees. That's why the option is there. Encryption != guaranteed integrity!

      Shame on any vendor which doesn't enable integrity checks on ESP payloads by default. If they make it easy enough to use IPSec without understanding it, they've got a responsibility to use secure defaults or warn the user (loudly) when insecure defaults are used.

  4. So... by blcamp · · Score: 1


    Why wouldn't the payload data be encrypted in the first place?

    After all, we are talking about sending packets over public lines.

    Am I missing something here?

    --
    The problem with socialism is that they always run out of other people's money. - Margaret Thatcher
    1. Re:So... by Veinor · · Score: 1

      Why wouldn't the payload data be encrypted in the first place?

      How would you communicate how this is encrypted? You'd need another payload data, which would probably be vulnerable to the same attack.

    2. Re:So... by mkettler · · Score: 1

      This vulnerability doesn't cause the payload to not be encrypted, it's a means of figuring out how to decrypt them without knowing the key.

      Of course, the whole thing relies on you having message authentication (hmac-md5 or hmac-sha1) off. Something which was already known to be a bad idea.

      With authentication off, someone can twiddle bits in the packet (without knowing their original state, but they can predictably flip a specific bit). From that, you look at the reply. If you do this enough times to fields that have predicable behavior, such as the TCP sequence number, you can gather enough information to figure out the encryption state and decrypt some of the packets in the stream.

      To me, this whole thing is a gigantic "DUH". Almost crypto protocol which doesn't have good integrity protection is likely to be attacked this way. It's been done dozens of times.

      Weaknesses using CRC32 as a cryptographically secure integrity check is how the classic SSH crc-compensation attack worked:
      http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999 -1085

      Lack of integrity is part of why VTUN is considered insecure to the point of being broken:
      http://off.net/~jme/vtun_secu.html

      This kind of attack is blatantly obvious. It's been written about many times and demonstrated against many different protocols in the past. It's why nearly every book on IPSEC I've seen warns that if you don't use a MAC, someone will break your crypto.

      The only difference is that before it was a obvious theoretical weakness. Now it's one that's been demonstrated in practical application.

      --
      -Matt
  5. Re:OpenBSD is clear by Anonymous Coward · · Score: 0

    OPenBSD has had ONE remote exploit in its lifetime. This exploit was not with OpenBSD but rather with Apache but the OpenBSD team took the fall becaue it is there job to audit the code.

  6. Re:Old news by norfolkboy · · Score: 5, Insightful

    "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.

  7. Re:OpenBSD is clear by Anonymous Coward · · Score: 0

    I'm a long time OpenBSD user and can tell you they've had more than one remote hole in "its lifetime". Only one in the past few years. I love the OS as much as the next tinfoil hatter but get your facts straight.

  8. end-to-end by rsw · · Score: 0, Flamebait

    This, children, is why end-to-end solutions are better.

    -rsw

    1. Re:end-to-end by tomstdenis · · Score: 0, Troll

      No, I think well thoroughly documented [no less than 900 pages] of gibberish on every-step-of-the-way-from-start-to-end-encryption -and authentication ... is much better..

      simple people. Challenge response + salts + cipher + MAC == much simpler and likely more secure.

      If you wanna have fun look at 802.16e it's like 950 pages and specifies dozens of encode methods for the data [e.g. FSK, BFSK, QAM] ...

      So it has 16 modes to transmit it... let's see what the hardware will do... oh right THE BARE ASS MINIMUM!

      So why don't these smart and overly intelligent folks on standards committees just specify ONLY the minimum and let people have their own extensions? E.g.

      Broadcom 802.16 + Broadcom-super-plus

      and

      Linksys 802.16 + Linksys-max!

      [or whatever]...

      AT the very least they have 802.16 at the base so the two products can talk... and if their admendmends are good you turn it into a new standard [not one huge god forsaken hard to read and remember 950 page behemoth].

      Of course that's just my opinion and I'm right.

      Tom

      --
      Someday, I'll have a real sig.
  9. second security flaw today? by nietsch · · Score: 1

    After reading the ultra mysterious unknown exploit in hyperthreading to be announced at that bsd conference + BSD is usually security paranoid == they have tickets to sell for that conference and are brewing up some hype...

    I could be wrong, TFA is very sparse on details...

    --
    This space is intentionally staring blankly at you
    1. Re:second security flaw today? by masterpenguin · · Score: 1

      Its 'inscure friday' where it is a techs duty to let known one security flaw so that the tech is guaranteed to have a job on monday.

  10. Re:Old news by Anonymous Coward · · Score: 0, Redundant

    Yes, for hysterical paranoids!

  11. So the solution is .. by Anonymous Coward · · Score: 0

    Turn off HyperThreading and SATA drive caching, install MS virus checker? (Too much vulnerability info, buffer overflow!)

  12. Don't go replacing anything just yet. by PacketScan · · Score: 2, Informative

    Ipsec it self isn't vulnerable. It is the session setup that can be misconfigured causing the Exploitable problem.

    1. Re:Don't go replacing anything just yet. by Anonymous Coward · · Score: 0

      The car isn't vulnerable... it is the driver, who stupidly: forgot to switch on the ABS, decided not to engage the differential slip feature, turned off the gear shift smoother, never installed the tire pressure monitor and regulator, forgot to turn on the running lights, etc. etc. So when the car almost got hit, then lost traction, yawed, went out of control, and killed all the occupants, it wasn't that the car was vulnerable, it was grandma's stupidity in misconfiguring it for the drive home with the grandkids.

      Oh, wait! Cars don't have serious configuration options, certainly not where it comes to essential safety features.

  13. VPN by OverflowingBitBucket · · Score: 4, Funny

    Well, I guess it stands for Virtual Public Network now. ;)

  14. Re:OpenBSD is clear by bluGill · · Score: 2, Informative

    No, the one hole was in openssh. There have been many (well at least one) holes in their apache, but apache is not enabled by default so it is not counted. Openssh is enabled by default, so it counts.

  15. Don't use agressive mode PSK by Neo-Rio-101 · · Score: 1

    As far as I know, there is a way to crack Aggressive mode Pre-shared keys when used on IP-Sec. It's been done and proven.

    --
    READY.
    PRINT ""+-0
    1. Re:Don't use agressive mode PSK by God!+Awful+2 · · Score: 1

      As far as I know, there is a way to crack Aggressive mode Pre-shared keys when used on IP-Sec. It's been done and proven.
      Yeah... it's called brute force.

      A lot of boxes on the net use relatively weak passwords, so it shouldn't take too long, actually... although you might set off the IDP.

      -a

      --
      /. users can't
  16. ipsecks is hawt by Anonymous Coward · · Score: 0

    things i'd like to super size my IPSEC protocol stack with:

    large fry and diet coke. combined message authentication and encryption block cipher for ESP/AH equivalent transport. perhaps GCM AES-256

    some of those fried cheese stick things, and ephemeral diffie hellman with ECC/RSA/DSA signatures.

    and lots of temporal keying. and i do mean really promiscious, indulgant amounts of temporal keying...

  17. Misleading hype by Anonymous Coward · · Score: 4, Informative
    This only applies to certain configurations using CBC encryption for confidential guarantees without proper integrity protection. These configurations are rare these days and are not even allowed by major vendors.

    More info here.

  18. Wrong Answer - Please ignore parent by MerlynEmrys67 · · Score: 4, Informative
    Uh - NO - (why is this insiteful)

    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
    1. Re:Wrong Answer - Please ignore parent by PacketScan · · Score: 1

      Yet it's still part of the SETUP! or initial Configuration of said tunnel! Through a few abbreviations around and watch the score rise :-)

    2. Re:Wrong Answer - Please ignore parent by That's+Unpossible! · · Score: 1

      Uh - NO - (why is this insiteful)

      Because it causes people to vehemently rise up against it?

      OH... you meant insightful.

      --
      Ironically, the word ironically is often used incorrectly.
  19. Solution by SenFo · · Score: 4, Informative

    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.
  20. Sweet Friday the 13th! by Mad_Rain · · Score: 3, Funny

    So let's see, first there was the Intel Hyperthreading Vulnerability, then there was a patch to an Apple security flaw and now this....

    So who came out a winner betting on this trifecta? ;)

    --
    "What do you think?" "I think 'What, do you think?!'"
    1. Re:Sweet Friday the 13th! by dpilot · · Score: 1

      Well, you've got to add the Firefox vulnerability just a few days back, and the answer becomes obvious:

      Microsoft.

      --
      The living have better things to do than to continue hating the dead.
    2. Re:Sweet Friday the 13th! by hotdiggitydawg · · Score: 0

      Microsoft! Because someone else is taking a bashing for a change...

  21. Severity of the flaw? by wcitech · · Score: 1

    Would this even matter over an SSL connection?

    1. Re:Severity of the flaw? by Anonymous Coward · · Score: 0

      IPSec and SSL are not related.

      However, don't be fooled into thinking that because you use SSL you are safe or safer than with IPSec. SSL may still be vulnerable to unknown flaws and has always been vulnerable to man-in-the-middle(MIM) attacks. So, jumping up and down because you recently setup OpenVPN just demonstrates ignorance and naivete. IPSec, properly configured, is still a more secure solution than SSL.

  22. Grrr... by jazzman75 · · Score: 1

    And here I thought my wireless link using WPA-TKIP (WPA2 not out for access point yet) and an L2TP/IPSEC VPN using ESP 3DES would be secure enough for daily use. Guess I'll have to add yet another layer of encryption. Must I now install an english to pig-latin service for both ends? ;)

    1. Re:Grrr... by Anonymous Coward · · Score: 1, Funny

      Better throw in some Double ROT-13 encryption as well. Just to be sure ;)

    2. Re:Grrr... by Anonymous Coward · · Score: 0

      Nah, do what i do. Make your communications so boring that no one would want to intercept them. This post is a prime example.

    3. Re:Grrr... by jonadab · · Score: 1

      > Must I now install an english to pig-latin service for both ends? ;)

      No, here's what you do: Set up Dvorak->Qwerty transliterative fonts on all your workstations at both ends, and set the keyboard layouts to Dvorak. Your users will still type as if the layout were QWERTY, and due to the transliterative fonts the letters will appear correct. For instance, the user will type the key that they think is "S", but on a Dvorak layout that key is really "O", so the character they typed is "O". However, the transliterative font displays "O" as "S", so the user will see "S" on the screen. But anyone who intercepts the traffic will see "O". As long as whoever intercepts the traffic doesn't know about frequency analysis, you should be good to go ;-)

      --
      Cut that out, or I will ship you to Norilsk in a box.
    4. Re:Grrr... by fuzzybunny · · Score: 1

      ROT13 twice, for extra security.

      --
      Cole's Law: Thinly sliced cabbage
  23. This method is known as .... by wsanders · · Score: 1

    This method is known as "giving all your sales guys the same key". Once, I was kidnapped, held at gunpoint in a basement dungeon, and beaten until I agreed to so this.

    --
    Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
  24. Yea. by Anonymous Coward · · Score: 0

    You would have been safer if you used Double ROT-13 encryption instead. You 1337 script kiddie, you.

    1. Re:Yea. by grasshoppa · · Score: 1

      Erm...I did.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    2. Re:Yea. by Tack · · Score: 4, Funny
      You would have been safer if you used Double ROT-13 encryption instead.

      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.

    3. Re:Yea. by Nerd+Cooties · · Score: 1

      Hey, I just use ROT26 and so far no one has cracked my code... of course it might help to be intelligible in my writings.

      --
      I support the 2nd Amendment, the right to keep and arm bears!
    4. Re:Yea. by owlstead · · Score: 1, Funny

      You would have been safer if you used Double ROT-13 encryption instead.

      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.

    5. Re:Yea. by Anonymous Coward · · Score: 0

      Way to totally miss a joke.
      2. Double.
      Do these words make any connection in your head?

    6. Re:Yea. by Alsee · · Score: 1

      I prefer to use 52 rounds of ROT-1.

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    7. Re:Yea. by Anomynous+Coward · · Score: 1


      3328 rot-13's work for me...

      plus as an added bonus, you can preview the encrypted message for spelling errors before you post it!

      shine,

      --
      Time flies like an arrow -- Fruit flies like a banana
    8. Re:Yea. by Anonymous Coward · · Score: 0

      Way to reveal yourself as a total fucktard.

  25. Only relevant to the standard by iabervon · · Score: 3, Insightful

    This only affects a relatively odd combination of features, so it's probably not a big deal for actual users. On the other hand, it is a flaw in the standard to claim that you can get confidentiality without integrity, when, in fact, that means that your data can be replaced with a request to decrypt your earlier packets, and you'll do so. Of course, integrity would only be disabled in a specialized application (where you expect to be able to deal with mangled data), and IPSec is generally deployed in cases where a variety of applications will use the channel.

    It's extremely difficult to design a cryptosystem with optional features, because the security of various techniques tends to depend on properties provided by other techniques, and it's difficult to determine, especially in a committee, whether these properties are provided for the proper function of the system or because the end user is likely to want them.

    1. Re:Only relevant to the standard by God!+Awful+2 · · Score: 1

      On the other hand, it is a flaw in the standard to claim that you can get confidentiality without integrity.
      IIRC, the standard doesn't say that. I believe it says the opposite.

      Disabling authentication is just something vendors like do to increase their published performance numbers. No one should actually deploy that configuration.

      -a

      --
      /. users can't
  26. Slashdot provides critical security advisory! by ramam · · Score: 5, Funny

    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!

  27. Whiskey Tango Foxtrot??? by Anonymous Coward · · Score: 0

    Wtf? Are you joking? If you aren't joking then I must tell you that you are full of crap! Let's see the proof, since you say it's been done and proven.

  28. Flashy Title Generates Ad Clicks!` by ramam · · Score: 1

    From now on we should expect every IE or Firefox vulnerabilitiy to be reported as "Flaw found in Internet security"? Very dramatic!

  29. SSL vulnerable too! by ramam · · Score: 1

    You can disable encryption in SSL. Next article "Critical Flaw found in SSL."

  30. Encapsulating Security Payload by Anonymous Coward · · Score: 0

    Check the rfc it is encapsulating security payload

  31. Agreed - ICMP backchannel is cute, though by billstewart · · Score: 1

    The ESP-without-Authentication issues have been known for a while. ICMP leakage of the otherwise-secure packets are an interesting new wrinkle on it, though.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  32. Re:Old news by ediron2 · · Score: 1
    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.

    Yeah, like readers are even remotely in control here...

    In bizarro slashdot-land, there's no doubt a peer-reviewed, wiki-ish news system and their critics are arguing that all the trouble with old news, inanity and dupes could be solved if they allowed advertising and used the profit to hire editors to professionally manage the news flow.

  33. Re:Old news by Anonymous Coward · · Score: 0


    AFAIK the editorial team don't go looking for articles...

    You must be new here.

    ...they wait for YOU the reader to submit them.

    And then they reject them.

    Shame on the mouth-breathing kiss-asses who modded parent 'insightful'. PLEASE.

  34. More Info... by Jeffb05 · · Score: 2, Informative

    They must be using ICMP type 12 (from RFC792) which shows the original header + first 64 bits (8 bytes) of data from each packet. Interesting leak, but very small amount of data. http://rfc.net/rfc792.html

  35. Re:Old news by hotdiggitydawg · · Score: 0

    AFAIK the editorial team don't go looking for articles, they wait for YOU the reader to submit them.

    Well, they certainly don't edit any submissions either - look at all the dupes, headline typos, etc... so what do they actually do again?

  36. security protocols 101... by Anonymous Coward · · Score: 0

    Those in the security community know that in MOST if not ALL cases, the use of 'privacy protocols' (ESP) without the simultaneous use of 'authentication protocols' (AH) for the same communications session is ripe for exploitation.

  37. From the dire-straits dept. by Brent+Nordquist · · Score: 0, Offtopic

    Sounds like we can get our money for nothing after all! (What about the chicks for free?)

    --
    Brent J. Nordquist N0BJN
  38. Old News.. This is a non-issue by tji · · Score: 3, Informative

    Basically, this tells us "don't switch off authentication in IPSec" (if your IPSec allows this, many don't allow you to run without authentication).

    But, the creators of IPSec told us this a LONG time ago.. Security wizard Steve Bellovin analyzed this as part of his IPSec reviews and said that encryption without authentication is a very bad idea. See the FreeS/WAN FAQ pages for more info ( http://www.manualy.sk/freeswan-1.3/doc/overview.ht ml#encnoauth )

    Mr. Bellovin presented a paper on this in the Usenet Security Symposium of July 1996.

  39. MOD PARENT DOWN by Anonymous Coward · · Score: 0

    This guy has no idea what he's talking about.

  40. No, it doesn't by apankrat · · Score: 1

    NAT traversal just adds another level of encapsulation and this 'vulnerability' applies to ESP itself.

    --
    3.243F6A8885A308D313
  41. known and documented since 1995 by Anonymous Coward · · Score: 0

    these "vulnerabilities" were known in 1995 and published in all IPsec ESP RFCs.

  42. Moreover by apankrat · · Score: 2, Interesting

    Not having integrity protection enabled automatically opens ESP to the replay attacks, which are easier to mount and far more practical than the one described in TFA.

    --
    3.243F6A8885A308D313
  43. It's not a flaw in ESP by Anonymous Coward · · Score: 0

    It's an expected behaviour. That is why there is an integrity protection option.

  44. No sane IPsec implementation id vulnerable by leto · · Score: 2, Informative

    Response from the Openswan team: Not vulnerable

  45. Number of Solutions by Shamanin · · Score: 1

    The NISCC includes a number of solutions to this issue in its advisory.

    Solutions:

    • (1) ignore this hyped warning
    • (2) use all possible security layers of IPSec
    • (3) don't use IPSec at all, if you are worried from this message your obviously not very secure to begin with
    --
    come on fhqwhgads
  46. This is a known issue by lyrix · · Score: 3, Informative

    This is a known issue. Some colleagues and I published on a very similar attack where unauthenticated IPSec packets can be redirected, bounced, and possibly decrypted by outsiders back in 2000. See "Initialization vector attacks on the IPsec protocol suite" in the proceedings of WET ICE 2000. Basically you can mess with the first encrypted chunk of the plaintext, i.e. the TCP and IP headers, by bitflipping the initialization vector (IV) in the encrypted packet stream. An IV is used in several block encryption schemes, notably cipher block chaining.

    This even works with TCP even though the plaintext header is checksummed. We showed that it was easy to get an identical checksum by modifying an unused part of the TCP header along with a more important part, like destination port.

    Using authentication defeats this attack. Just don't forget to authenticate and everything is peachy.

  47. Re:OpenBSD is clear by shis-ka-bob · · Score: 2, Insightful
    1) Look at the security report from the OpenBSD folks at http://openbsd.org/errata31.html#sshd, the OpenBSD hole was indeed in OpenSSH.
    2) Look a the openssh.org homepage. Notice the quote 'OpenSSH is primarily developed by the OpenBSD Project, and its first inclusion into an operating system was in OpenBSD 2.6. '

    I'm siding with bluGill on this point, the AC is the dumbass on this trhread.

    --
    Think global, act loco
  48. This is the Paris Hilton of Security Advisories by Fefe · · Score: 2, Informative

    Big noise, nothing behind it.

    To call this issue well-known would be an understatement. It is even mentioned in the RFC2406 in the Introduction. RFC2406 happens to be to RFC that defines ESP mode in IPsec.

    It must be a slow news day in Great Britain.

  49. how does VPN work? by zippthorne · · Score: 1

    I thought you were supposed to use SSH tunneling to connect the remote sites.. That isn't necessary? shoot i've been doing this all wrong.

    --
    Can you be Even More Awesome?!
  50. Re:The Founding Fathers by benhaha · · Score: 1

    Erm, yes?

    What do you think "the conquest of the west" was?

    America was built by invading lands occupied by others and driving them out and/or killing them. That's not how we ought to behave now, but was not too far from a mainstream attitude then.

    All countries were created and re-created the same way, many times, over millennia. Look at Britain, created by successive waves of invasion and colonisation. Before America, the indigines did the same thing to each other. Prior to the invention of the modern state and modern democracy, it wasn't even widely considered especially morally wrong, just something you didn't want to be on the wrong end of.

    --
    NO ID: BEING FREE MEANS NOT HAVING TO PROVE IT