So I know many people use OpenVPN these days, but does anyone use L2TP/IPSec or IPSec? I asked because when recently searching this topic, despite the author mentioning lots of dated materials, most of what I find is archaic. This post mentions ipsec-tools, but it has been clear that since the IPSec changes/patches went inline into the kernel for 2.6.x and beyond, these have slowly become more relevant over time, and that ipsec-tools and/or raccon to do L2TP and IPSec or pure IPSec is generally outdated and now only really suited to the BSDs because, as the articles mentions, it is more germane to that architecture.
And the difference between FreeSWAN, LibreSWAN, and StrongSWAN was very confusing to me unitl I read this.
I mean setting up VPN is no trivial pursuit, but the amount of effort to set any of these up to use native VPN clients for my mobile (Android devices) encouraged me to potentially consider StrongSWAN once I really review the documentation and learn as much as I can.
Password protected keys (edit:certificates), yes, but not regular user/password no matter if it's LDAP backed or anything else... (but I think you can do password and key, but I need to check docs)
I'm in a meeting and drawing a blank on what the primary reason was for avoiding password-only... I'll update if I can remember the reason besides "passwords are easier to crack"
Almost any decent enterprise identity management solution (read: Active Directory, FreeIPA) includes user certificate management in some fashion; or if you want a separate CA for VPN access it's not hard to write a couple scripts to generate user certificates and revoke them as needed.
I use IPsec in addition to OpenVPN, primarily because that's all iOS used to support. Since iOS 5 or 6 (I think; maybe even as late as version 7?), Apple has allowed third-party VPN apps, so with an "official" OpenVPN client now available in the iOS App Store, it's not as important as it was. However, I've left it running as a fallback solution to OpenVPN (some hotel firewalls, for example, permit IPsec but actively block UDP-based OpenVPN).
I use ipsec-tools, as circa 2012 when I was originally setting this up, it was the only free software IPsec solution I could get to work with iOS clients, but based on this vulnerability I've now disabled it and will try StrongSWAN again.
In addition, tunneling TCP in TCP to hide OpenVPN behind a HTTP proxy, lest it look out of place and be easily fingerprinted as OpenVPN on packet analysis is why I wanted to avoid it this time around.
Plus, I wanted to better secure my home network AND make it accessible remotely (in a dorm-like accomodation with enterprise-grade NAT with Cisco gear), I thought an IPSec tunnel would be optimal as well.
There are a lot of places using IPSec VPNs for point-to-point connections, in part because there's an awful lot of equipment out there that supports them.
Heck, Cisco's "Small Business" RV router series (RV042/RV082/RV016/RV042G and possibly others) are still being sold after several hardware revisions (still kind of long in the tooth), and they support all of two VPN types: IPSec and PPTP.
Oh, I am aware. I work in a such an org with the Cisco IPSec system. I have mutliple that I use/evaluate for work purposes, but when I asked this I am more interested in the open systems not tied to a dedicated appliance, or at least can do both (I see "OpenVPN appliances" advertised on the OpenVPN page these days).
You got a write-up on that? It sounds like a daunting task, so funny blog post with profanity about Linux config (used to write them, no one would read them) are something I really enjoy.
So definitely write about that. There is so much bullshit and misinformation I have read this week alone on VPN config in *nix environments, it's astounding. My shakiness was only confirmed by this article.
I'm planning on going through some of my old projects and writing blog posts about them over the next couple of months, and I will add that one to the list. It was indeed, a massive pain in the ass.
IPSec is still the enterprise defacto standard. Its pretty much everywhere.
Yeah, it a little different for the FOSS home hobbyist, but for companies with a budget, its a trivial addition to their infrastructure (Cisco, Sonicwall, etc). FOSS IPSec implementations seem to be pretty non-existant in practice from my own experience and I only see FOSS-only shops using OpenVPN, which is OpenSSL based (which, of course, suffered from heartbleed).
This is why I ask. I did not want to post it again (I am sure I am not the first), but this is SoftEther thing masquerades as these different VPN protocols while being the same backend.
I'm really glad you posted that link, because I think Streisand is an important project. I wasn't under the impression that Streisand existed because OpenVPN was hard. Rather, it tries to support everything possible, and helps you set up some of the more esoteric solutions out there in case that is all your users can support. OpenVPN is just along for the ride.
We use L2TP/IPSec to VPN into our AWS VPC. Amazon's VPN solutions aren't great, and propping up a VPN endpoint on a micro instance and an elastic IP is fairly easy. Also makes it easier to SSH/RDP/MySQL to instances in your private subnet from trusted developer machines at our office. L2TP/IPSec is built in to modern versions of OS X and Windows (though for Windows you have to tweak hidden settings to work with NAT properly)
Someone once told me, "you are far too interested in what you have to say". I think that applies to this write-up.
I mean, it was educational and somewhat entertaining, but the lack of professionalism bothers even me, and that's saying something... Just stick to the technical aspects so that people can fix this as quickly as possible.
With all due respect, find a more appropriate soap-box next time. All the ranting simply caught me off guard in a 0-day announcement.
> The reason I found this vulnerability is because I made the mistake of following someone's IPsec How-To. Don't trust How-Tos written ten years ago. Don't trust How-Tos written yesterday.
Finding the vulnerability leaves him full of confused regret?
> Relativism and Utilitarianism are not a valid excuse for doing harm. A person who does harm consistently marks himself or herself as a bad actor. It is our job to name them and reduce harm.
The rhetoric doesn't fit reality so much. Like you said stick to the technical facts, so moral people everywhere can "do the right thing".
I find that when I keep my opinions to myself, people assume that something very different than what I am thinking. I have become more outspoken recently as I have found that people are more willing to listen to and argue things that they disagree with if they trust the person saying it (yourself perhaps?).
The audience of this document was the TA3M Seattle group, which is very different from the average tech audience. It was a mix of people who are programmers and people who are not. I tried to put the subject area into both areas. If I was speaking to a tech audience, I would have made the paper more like this: https://www.altsci.com/ipsec/ipsec-tools-sa.html and simply described the problem of software security prediction instead of trying to give people actionable advice and the reason why.
So this document attempts to give people 0-day and the motivations behind naming software as unmaintained. I think that most people don't understand how many hours I spent trying to report my findings (~20 hours) when finding the vulnerability took just 3-4 hours. If we want secure software, we need to remove IPsec-tools and similarly unmaintained software from the open source ecosystem so that we don't spend 20 hours trying to contact them every time we find a vulnerability.
While I agree with you, I am also inclined to think "well, it's his find. He's entitled to say whatever he wants." And in his defense, he follows the inverted pyramid structure of putting the vital information up front. Heck, he even included the line of code that causes the issue. I rarely see that!
He definitely explained things well and proved he has a deep understanding of the larger situation. I wish more people were so involved and passionate about their field of work.
Thank you for the comment. I didn't have enough time to finish the paper, so it is more than a little rough around the edges. I have intentionally reduced professionalism in this paper to save time and energy so that I can spend it on more effective pursuits. The reason I tacked on the whole question of "Was IPsec itself poorly designed?" "Why didn't this get reported in 2013?" "What should we do about software vulnerability?" was to get interest from people who generally get nothing from a vulnerability announcement in software they don't use. Thus, the audience of this paper is very different from the traditional audience of people who read vulnerability announcements by the hundreds. Like another user commented, I tried very hard to put the important stuff first so that people like you could stop reading when they became disinterested.
Although my post did have legitimate reasons for criticizing, I really just meant to poke a little fun at someone who is obviously more dedicated and passionate than the majority.
I meant no harm. You are most probably accomplishing the types of things in the security field that I can only dream about. /me stares off into space, thinking of a day when I might discover a vital 0-day.
FYI, this seems to affect some configurations but not all configurations. I've had one member of the NYC BSD group ran these against his IPSec configuration with just errors, but then set up a IPSec using the OP's configuration and was able to reproduce the coredumps.
Thank you very much for testing this exploit. The vulnerability is in gssapi.c which is only compiled in if HAVE_GSSAPI is defined. This is an optional configuration parameter, so it sounds like the configuration you tested did not have GSSAPI/kerberos enabled. That's good news for users who have a similar setup, it will give them ample time to switch to a different IPsec implementation.
Is the number of vulnerabilities for a product really a good indicator of it's quality? I seem to remember a year-end report showing Google Chrome as the browser with the most number of security bugs found, but some people said that was because they pay the most in their bug bounty program.
No, by itself the number of vulnerabilities patched is only useful in telling us which software has been tested and found to be lacking in the past. Along with other metrics (severity, static analysis results, code quality, complexity, reports by an independent auditor, availability of a testing framework, and competitor quality), this can be used to decide which projects need to be replaced or improved upon.
The reason that many vulnerabilities have been found in Chrome is because it is a very large and complex project. The bug bounty only gives people the necessary additional motivation to work on it during business hours. Other projects that lack bug bounties have found similar numbers of bugs (Wireshark and ClamAV to name a few) due to their complexity.
I would recommend IPVanish with exceptional performance combined with outstanding online security, IPVanish VPN will keep you from all kinds of threats present on the internet and it allow internet freedom. With 150+ servers located all over the world as well as securing your data with safe encryption tunnels along with protocols, IPVanish will be away cyber-goons and also protect your privacy. Take a look at this review http://www.bestvpnprovider.com/ipvanish-review/
44 comments
[ 2.5 ms ] story [ 101 ms ] threadAnd the difference between FreeSWAN, LibreSWAN, and StrongSWAN was very confusing to me unitl I read this.
http://serverfault.com/questions/173158/strongswan-vs-opensw...
I mean setting up VPN is no trivial pursuit, but the amount of effort to set any of these up to use native VPN clients for my mobile (Android devices) encouraged me to potentially consider StrongSWAN once I really review the documentation and learn as much as I can.
What are others doing?
Thanks for the cool article either way.
http://strongswan.org/testresults.html
I'm in a meeting and drawing a blank on what the primary reason was for avoiding password-only... I'll update if I can remember the reason besides "passwords are easier to crack"
Maybe the certificates could be stored in LDAP.
I use ipsec-tools, as circa 2012 when I was originally setting this up, it was the only free software IPsec solution I could get to work with iOS clients, but based on this vulnerability I've now disabled it and will try StrongSWAN again.
1- https://news.ycombinator.com/item?id=2409090
https://www.bestvpn.com/blog/5919/how-to-hide-openvpn-traffi...
Plus, I wanted to better secure my home network AND make it accessible remotely (in a dorm-like accomodation with enterprise-grade NAT with Cisco gear), I thought an IPSec tunnel would be optimal as well.
Heck, Cisco's "Small Business" RV router series (RV042/RV082/RV016/RV042G and possibly others) are still being sold after several hardware revisions (still kind of long in the tooth), and they support all of two VPN types: IPSec and PPTP.
So definitely write about that. There is so much bullshit and misinformation I have read this week alone on VPN config in *nix environments, it's astounding. My shakiness was only confirmed by this article.
IPSec is still the enterprise defacto standard. Its pretty much everywhere.
Yeah, it a little different for the FOSS home hobbyist, but for companies with a budget, its a trivial addition to their infrastructure (Cisco, Sonicwall, etc). FOSS IPSec implementations seem to be pretty non-existant in practice from my own experience and I only see FOSS-only shops using OpenVPN, which is OpenSSL based (which, of course, suffered from heartbleed).
Exactly. I'd love to see a simple, auditable and secure open source VPN software. (not OpenVPN)
http://softether.org/
https://github.com/jlund/streisand
EDIT: Forgot the link, like a proper idiot.
The article mentions Vista and Window Server 2008, but it applies to Windows 7 and Windows 8 as well. There are some Stack Overflow threads as well.
For the VPN setup, I largely followed these instructions:
http://www.stormacq.com/build-a-private-vpn-server-on-amazon...
There are a few typos in the scripts cited in the article especially around saving the iptables rules.
OS X's native VPN client worked out of the box
Also "IPsec is a piece of software that is often used for critical infrastructure." it is not software.
ps the document reads really bad, and is not even solely about a _potential_ issue with ipsec protocol.
I mean, it was educational and somewhat entertaining, but the lack of professionalism bothers even me, and that's saying something... Just stick to the technical aspects so that people can fix this as quickly as possible.
With all due respect, find a more appropriate soap-box next time. All the ranting simply caught me off guard in a 0-day announcement.
Finding the vulnerability leaves him full of confused regret?
> Relativism and Utilitarianism are not a valid excuse for doing harm. A person who does harm consistently marks himself or herself as a bad actor. It is our job to name them and reduce harm.
The rhetoric doesn't fit reality so much. Like you said stick to the technical facts, so moral people everywhere can "do the right thing".
I find that when I keep my opinions to myself, people assume that something very different than what I am thinking. I have become more outspoken recently as I have found that people are more willing to listen to and argue things that they disagree with if they trust the person saying it (yourself perhaps?).
The audience of this document was the TA3M Seattle group, which is very different from the average tech audience. It was a mix of people who are programmers and people who are not. I tried to put the subject area into both areas. If I was speaking to a tech audience, I would have made the paper more like this: https://www.altsci.com/ipsec/ipsec-tools-sa.html and simply described the problem of software security prediction instead of trying to give people actionable advice and the reason why.
So this document attempts to give people 0-day and the motivations behind naming software as unmaintained. I think that most people don't understand how many hours I spent trying to report my findings (~20 hours) when finding the vulnerability took just 3-4 hours. If we want secure software, we need to remove IPsec-tools and similarly unmaintained software from the open source ecosystem so that we don't spend 20 hours trying to contact them every time we find a vulnerability.
You have convinced me to release a version of the report without the soapbox for people like you: https://www.altsci.com/ipsec/ipsec-tools-sa.html
I meant no harm. You are most probably accomplishing the types of things in the security field that I can only dream about. /me stares off into space, thinking of a day when I might discover a vital 0-day.
Congrats on the discovery!
The reason that many vulnerabilities have been found in Chrome is because it is a very large and complex project. The bug bounty only gives people the necessary additional motivation to work on it during business hours. Other projects that lack bug bounties have found similar numbers of bugs (Wireshark and ClamAV to name a few) due to their complexity.