Dutch Government Officially Trusts OpenVPN-NL 53
First time accepted submitter joost.bijl writes "Yesterday the Dutch government took a step to further improve the adoption of Open Source in its ranks. It has officialy approved a modified version of the open source VPN software OpenVPN for use on the governmental level 'Departementaal Vertrouwelijk' (Restricted). The release is called OpenVPN-NL and is fully open-source and available for use. The software has undergone a security evaluation by the Dutch government's national communications security agency (NLNCSA). The major change is the removal of OpenSSL as the cryptographic core of OpenVPN-NL. Instead, the Dutch government opted to include the smaller, better readable and documented open source library PolarSSL to provide the cryptographic and SSL/TLS functionality. The Dutch IT Security company Fox-IT worked together with both OpenVPN and PolarSSL communities and modified the stock software to support the government evaluation process. In total 8000 lines of code and 4000 lines of documentation were checked in to the OpenVPN trunk."
Re: (Score:1)
I guess you are American?
Awesome (Score:5, Interesting)
This is very good news. OpenVPN is probably the easiest secure VPN software I've ever worked with. I've been running it as the link for our multi-site network for over two years now, and it's also the VPN software our road warriors are using. Simple to configure, and damnit but it just works. After years of trying to get all these weird implementations of IPSec to co-operate with each other, OpenVPN is just a marvel, fast and lightweight.
Re:Awesome (Score:5, Interesting)
I have a client site that needs to access some data in my local office. This client site network is locked down so tight that almost nothing goes through. Somehow OpenVPN manages to maintain several connections between here and there. Add to that the fact that they are fully cross platform and you just can't beat them.
Re:Awesome (Score:4, Informative)
OpenVPN is amazing, the only downside is that it doesn't support IPv6 expect in tap mode. But you can always configure tap mode yourself, right?
Re:Awesome (Score:5, Informative)
OpenVPN 2.3 does support IPv6 in tun mode, even point-to-multipoint. It still needs an IPv4 pool though but you can just ignore it and go IPv6 only.
http://www.greenie.net/ipv6/openvpn.html [greenie.net]
Re:Awesome (Score:4, Informative)
pfSense 2.1 has been including an IPv6 capable OpenVPN setup with tun for a few months now, though it's still in early development. The client on the firewall is capable, as is the windows client that the export package can generate with an included config.
openvpn[32839]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011
Re:Awesome (Score:4, Insightful)
Hear, hear.
Speaking of lightweight, I have it running on my WRT54GL wireless router (TomatoVPN firmware) and it works without a hitch. Even with the dinky 200MHz CPU in the router, the limiting factor is the upstream bandwidth of the network connection.
I particularly like the fact that it uses widely-tested methods for the secure connection (TLS, certificate-based authentication, etc.), rather than depending on some proprietary system.
Now, if only the Windows GUI client didn't need admin rights to open...
Re:Awesome (Score:5, Informative)
Yes, that is a pain. I thought they were supposed to be setting up the Windows service so that a non-admin client could control the VPN via the service to write the routing table, which seems to be the big stumbling block for OpenVPN under the UAC.
Re: (Score:2, Informative)
There's a newer version of the Windows client which uses the management interface to control the OpenVPN service.
Can't check at the moment, but i think it's this one: http://sourceforge.net/projects/openvpn-gui/
Re:Awesome (Score:5, Insightful)
It's great to see my government do something sensible related to IT. Most of the time they really truly suck at it (like almost every other government, I suspect). Surely you remember the Diginotar debacle? We've got tons more like that.
Re: (Score:3, Funny)
I was just thinking that, from Dutch govenment's point of view, OpenVPN must be extraordinary awesome while used in combination with Diginotar-signed certs!
(Sorry, I just couldn't resist.)
Re:Awesome (Score:4, Interesting)
This is mainly going to be used to allow remote access to restricted infrastructure.
The comments in Holland are that this is allowing unsecured & unchecked workstations (home pc's & laptops) that might be infected with general or specifically designed malways; & then via the vpn gaining access to restricted documents & information.
The last word is not yet spoken about this.
Dutch megan00b
Why should we trust openssl? (Score:2, Insightful)
Dutch government does not trust openssl?!
Why should we trust it?
Re: (Score:3)
I think the issue is readability and documentation (and why, that's just what it says!) If there's a slight against openssl, it's probably that the source is a bit more complicated.
Re:Why should we trust openssl? (Score:4, Informative)
I think the issue is readability and documentation (and why, that's just what it says!)
Years back I wrote an encryption program in C as an exercise for myself using the OpenSSL libraries partly to learn how to use the APIs. Just a simple wrapper around well-documented APIs, knock it up in no time, right? Wrong!
The documentation was almost unintelligible to anyone who was not an OpenSSL developer or not prepared to study up on the algorithms used and wade through the OpenSSL code base to understand what the APIs did. I doubt that has changed. I found a tutorial giving code snippets in a popular journal that were incorrect and had a crucial error resulting in much hair-pulling. I eventually solved this by pure guesswork and trial-and-error. It would have been much quicker to just cut and paste from someone else's openssl-based encryption program. This all reminded me of those frustrating time-wasting assignments as a student where lecturers forgot to tell us that it just wouldn't work or be solvable without secret Factor X and someone in the class had to discover this sideways from a tutor.
Time OpenSSL grew up and stopped living in arcane land. It needs decent docs. There is an O'Reilly book on it - maybe that'd help next time.
Re:Why should we trust openssl? (Score:5, Informative)
OpenSSL only goes up to TLS1.0, which contains some vulnerabilities. (Note sure if these issue affect OpenVPN). PolarSSL (which is created by a Dutch company, which might be the reason that was chosen) supports up to TLS1.1.
Why they didn't go for the more feature complete and mature GnuTLS would be an interesting question.
http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations [wikipedia.org]
Re:Why should we trust openssl? (Score:5, Interesting)
That's true, though openssl has had the ability to add empty fragments to avoid the chosen plain text attack I suspect you're referring to for many years. What's strange is that the chosen solution (polarSSL) doesn't seem to have support for OCSP which is the main way to quickly revoke bad keys - particularly important in the light of the recent diginotar breach.
Re: (Score:2, Informative)
In a previous job the developer of PolarSSL worked at fox-it ...that is why fox-it choose PolarSSL
Re: (Score:2, Interesting)
i don't know about gnutls's maturity,
but polarssl does not seem to support renegotiation, that to me indicates it's a pretty bad choice for a vpn which you expect to be up 100% of the time and pass significant traffic. looks like the dutchies just wanted SOMETHING they had made locally in an approved software, security be damned!
Re:Why should we trust openssl? (Score:5, Funny)
Yeah, those silly Dutch just don't have a clue... By the way, is the United States still using Windows to control their nuclear power plants???
Re:Why should we trust openssl? (Score:5, Informative)
you don't know what you're talking about. Openvpn was never affected by the "renegotiation bug" as it doesn't use SSL for that component. As it runs over UDP and TCP, it had to come up with its own way of doing that - hence no problem.
That in combination with HMAC authentication makes it basically immune from that issue anyway...
Re: (Score:1)
Re: (Score:1)
Well good luck to them is all I can say. OpenSSL, even with occasional problems, is still the most proven solution.
Security and cryptography is hard. I mean really, really hard. Even very smart people make critical mistakes when trying to do it. Using some obscure SSL library seems like a really bad idea.
Re: (Score:3)
TLS 1.1 vs. perfect forward secrecy (Score:2)
TLS 1.1 may be excellent, but Google recently added support for perfect forward secrecy to OpenSSL, which would seem like a nice feature to have for governments. If they're sending secrets over OpenVPN with standard TLS, those secrets will only be secrets until computers are powerful enough to factor the primes used to negotiate the session. That might only be a decade - hard to say.
I have an OpenVPN link that's been up ten years! (Score:5, Insightful)
When VPN routers were hard to find I set up several OpenVPN links. Over the years most of those networks migrated to other VPN solutions but this one never changed and it always worked. Meanwhile I had to dick with the other solutions all the damn time. When the client with that old OpenVPN link wanted another link I took a good hard look at it. I never had to reconfigure it. I never had to reboot it. It was installed on two HP desktop mini-towers that the client gave to me. And I realized just how good that product was. So I used OpenVPN for the two new links, too. But I upgraded to version 2 and used Centos. That one has been up for two months and everyone is pleased as punch. I'm about to take the old one out of service and install a newer machine running version 2. I'm sure they'll last another ten years.
Holland has made a wise decision to support OpenVPN!
Re: (Score:2)
One of the other interesting things about using OpenVPN is that it doesn't have to be on the edge of your network. Both OpenVPN boxes are inside the firewall and WAN router... both have only one physical interface and both have internal IP addresses. So all the boxes do is OpenVPN and only that port is open to the Internet and *that* one is filtered by the firewall so that only the other box gets to pass. The firewall also blocks the OpenVPN boxes from sending packets to any IP address other than the firewa
talk about difference between governments (Score:1)
In usa they're still beating up harddrives likes neanderthals.
OpenVPN is really handy... (Score:1)
Comparing to other VPNs... PPTP - insecure by design... L2TP - insecure without IPSec... IPSec - troublesome in IPv4, cause of many of incompatible designs. I do remember one install... cca 8y ago... temporal bridging corporate LAN between two locations for period company moving from one office to another... I've started with IPSec on Linux and after day of not very satisfying results... finished with very stable, lightweight and performant solution OpenVPN on OpenBSD. Computers/servers then worked on both
OpenVPN help! (Score:1)
I have been trying to use SSH and OpenVPN to help a friend play games through a university network, but my experience with VPNs is limited to Hamachi. It seems extremely easy to setup a client, but setting up a server over Windows 7 seems slightly trickier. Anyone know a good up-to-date guide for a complete noob like myself?
Re: (Score:2, Informative)
This might be helpful: http://openvpn.net/index.php/open-source/documentation/howto.html
OpenSSL vs PolarSSL (Score:2)
Wasn't some recent version of OpenSSL actually FIPS approved?
Don't get me wrong, I don't see anything bad in allowing the user choose which crypto library to use.
diff (Score:3, Interesting)
About why the chose to use PolarSSL:
Among the notable differences between OpenVPN and OpenVPN-NL is the cryptographic library. Correct SSL functionality is essential for the protection that OpenVPN offers. OpenSSL is a large and complex library. PolarSSL is a compact and modular library, which is small enough for a fairly in-depth evaluation. Therefore, in the OpenVPN-NL package, it has been chosen to exchange PolarSSL for OpenSSL. This change does not change functionality; the two libraries (OpenSSL and PolarSSL) are mutually compatible.
source: background OpenVPN [fox-it.com]
But as being said in another comment, someone now working for Fox-IT was involved in PolarSSL. Extra functionality and documentation was added to PolarSSL by Fox-IT according to a comment on a tech-site (tweakers.net) by someone who claims to be the maintainer of PolarSSL.
Re:diff (Score:5, Informative)
Sounds good to me (Score:4, Informative)
This seems like a sensible move. It also seems like a major endorsement for OpenVPN. I've always had better experience with OpenVPN than with other VPN solutions, but I have the feeling it hasn't gained much traction. This may be a step in the right direction.
Also, I hadn't heard of PolarSSL, but it sounds worth checking out. OpenSSL has always worked for me, but it is true that the interfaces and documentation aren't the best I've ever seen.
Shameful (Score:1)
I'm Dutch and I feel ashamed!
Apparently to them, less is more. Less code means verifiability?? I thought it was just a matter of checking how well a certain standard was implemented. And if only 1 standard is implemented, well, less code to check?
They could have just taken GnuTLS and removed everything they didn't need. And even that would be plain stupid, as it would simply mean you're disabling a feature (instead of just choosing not to use said feature).
<3 OpenVPN (Score:3)