Printable View
care to show me any encryption method that is 100% not crackable?Quote:
IPSec and WPA, both are crackable, no?
WPA is excellent, and many people are using it. the constraint at this time is everyone with older equipment that does not support it, but as time passes people will buy newer equipment and adopte that form of encryption. It is strong and hard to crack when implemented correctly.
XTC46,
You're right about WPA. If implemented correctly (basic rule, use a complex passphrase) it is very hard to break. WPA requires someone to capture an enormous amount of packets in crack it.
About IPSec, some security is better than none. We use certificate authentication with RSA two-factor authentication as well as 3DES on our VPNs.
I must admit, we fell for the hype driven around IPSec a number of years back when it was touted as the golden egg of security. What we quickly found is that AH (authentication header) would not work through NAT devices and that ESP (encapsulated payload) carried a decent size overhead. Long and short, we were bamboozled.
IPv4 has encryption capabilities only they're not used. What a shame. This little known fact eats at me daily knowing that the foundation is there but no one will step up and build the house.
Now, the next lesson in IPSec was learned after we hooked up site to site tunnels. This worked wonderful for other locations we operate, however, when you hook up a site to site tunnel to an outside agency, all you've done is make a nice encrypted tunnel to an untrusted network.
Today, IPSec has a very limited role as we phase in newer technologies. I have deployed EAP-FAST for wireless and I now use the Juniper SSL VPN. Both have proven to be the right way to fly. But will they endure? No. In steps regulatory compliance, NIST 800 and and the infamous 2 factor auth. I'm not sure where we will be tomorrow. The ride is always an adventure.
What about the fact that IPSec will be [edit: IS part of] included in the IPv6 standard?
We don't have any IPsec VPN. We're moving towards rolling out SSL VPN using Netilla and possibly Juniper.
We have no wireless at all within the organisation we don't think we have a need for wireless that outweighs the security issues it has.
I was at a presentation by http://www.fortresstech.com/ earlier in the year. They took apart wireless IPsec quite comprehensively (to sell their products).
What's that old saying? Just because it's in there doesn't make it good.Quote:
What about the fact that IPSec will be [edit: IS part of] included in the IPv6 standard?
I'm actively watching some of the far eastern Countries which currently have IPv6 implementations running. I'm curious how the protocol flys in the real world instead of on paper.
IPSec has certainly been a let down for me (and others I have spoken to in the industry). Let's see if it rises from the ashes in IPv6, but I wont be betting the farm on it, that's for sure.
Aspman, could you run by us some of the highlights of the benefit of IPSec wireless that was presented to you by fortresstech.com?
TH13, you have actually done me a HUGE favor here. For some reason, I did not realize that I could compile in support for IPv6 in my kernel and still have IPv4 functionality. For some reason, I thought it was either IPv4 or IPv6, not both.
So I did just that, recompiled kernel for IPv6 support, and everything is working great! I am very happy about this! And I would not of even thought to try this were ity not for your feedback. So thanks a million ;-) Like I said, I did not realize that I could do IPv6 internally and still have IPv4 functionality externally. That is awesome!
One problem with this however, is what are my options for internal servers on my network that need to be accessed by the IPv4 web? I have heard of translators for this, but my understanding is that they slow things down considerably. That being the case, do I have any other options, or are those internal servers going to have to remain IPv4 [externally] / ipv6[internally]?
Unfortunately, you're stuck for now. The translators you speak of are indeed crappy and slow. This is another reason why I'm watching others instead of running my own IPv6 experiments (for now).
Yep, all the major distros allow you to compile IPv6 support into the kernel while keeping IPv4. Some people don't compile the support but I have done so ever since it was available. Even though I have no real use for it right now, you never know when something might present itself.
If you want to play, there is a site which will give you addresses to pure IPv6 hosts. Again, this would only be for you to stretch the legs of the protocol. If you want I can dig that info up.
Also, since each interface has two addresses [1 IPv4 and 1 IPv6], how can I enforce the use of IPv6 only on internal interfaces? IPv6 uses IP6tables, and IPv4 - iptables. Can I put IPv6 rules in IPv4 iptables? If this is the case, then I could just drop all IPv4 packets on the internal interfaces while accepting IPv6 packet. However, since IPv6 uses IP6tables, I have a feeling I cannot do this, or can I? If not, would there be another way to enforce the use of IPv6 only internally?
Good question. I've never tried this out, however, I don't *believe* you'll be able to mix the IPTABLE rules.
As far as forcing IPv6 only on the inside, there has to be a config file somewhere that will allow you to do this. Again, I haven't played with it in my own lab only because I have tons of other tests queued up that take priority over my own curiousity. Hehe.
If you do find success, please post it here so we can all benefit.