search

StreisandEffect / streisand

Streisand sets up a new server running your choice of WireGuard, OpenConnect, OpenSSH, OpenVPN, Shadowsocks, sslh, Stunnel, or a Tor bridge. It also generates custom instructions for all of these services. At the end of the run you are given an HTML file with instructions that can be shared with friends, family members, and fellow activists.
https://twitter.com/streisandvpn
Other
23.2k stars 1.99k forks source link

Remove LibreSwan & L2TP/IPSec Service #1222

Closed cpu closed 6 years ago

cpu commented 6 years ago

This is perhaps a contentious issue so let me be up front in saying this is my own personal opinion and I'm soliciting input from the larger group of maintainers & the Streisand community.

Expected behavior:

Streisand should offer best-in-class VPN services that follow best practices for security/privacy. The software it ships should always receive security updates. The maintainers should be able to reproduce client configurations to test for regressions, documentation oversight and bugs.

Actual Behavior:

Streisand ships a poor L2TP/IPSec configuration using IKEv1 and a static pre-shared key. The libreswan software is installed from source and receives no security updates. This maintainer (:wave:) has no resources to dedicate to IPSec and its many quirks.

Path Forward:

I think at the time that Streisand added L2TP/IPSec with LibreSwan there were very few options available for deploying an IPSec based VPN server. Client support for alternative VPN types was also quite poor. Since that time alternative projects have filled the niche of providing a solid IPSec based VPN server. Similarly, client support for other VPN protocols has improved.

I think we should prioritize working on the parts of Streisand that are not addressed by alternative IPSec based projects. In this case I think that means removing LibreSwan entirely rather than investing the considerable time/energy required to:

  1. modernize the configuration
  2. address the installation method/source
  3. build client tests into CI
  4. triage issues and offer user support

What do other folks think?

nopdotcom commented 6 years ago

The only OS-native VPNs on Android and iOS are L2TP/IPsec. If you can't/won't download and trust stuff from the app stores, they're the only options.

cpu commented 6 years ago

The only OS-native VPNs on Android and iOS are L2TP/IPsec. If you can't/won't download and trust stuff from the app stores, they're the only options.

I think users with this constraint are better served by projects that exclusively cater to providing a high quality IPsec VPN server (e.g. Algo). Given users with this constraint can be served better by other projects, is there reason to duplicate the effort in Streisand?

alimakki commented 6 years ago

@cpu changed titled to refer to Libreswan as we don't use Strongswan :)

cpu commented 6 years ago

@alimakki Doh! That's embarassing. Too many Swans :-) Thank you.

cpu commented 6 years ago

Another few points against continuing to include Strongswan:

  1. It's one of the things we have to mirror on cloudfront, manually updating each release. Removing this playbook would mean one less thing to update on our manual mirror.
  2. It significantly complicates CI. We have to jump through a bunch of hoops to install the build dependencies on the CI host and then insert the kernel module there before starting the Streisand host container. Removing this playbook would remove a big chunk of CI test code that is annoying to maintain.
alimakki commented 6 years ago

Adding a +1 on deprecating L2TP/IPsec.

cpu commented 6 years ago

@jlund is also a +1 out of band.

I think we have consensus that we should move forward on removing this service from Streisand.

a0s commented 6 years ago

I believe that native IPSec in Android consume less power than OpenVPN in any variant cause OpenVPN working in userspace

cpu commented 6 years ago

@a0s That's true, but the decision has already been made. If there are users that require IPSec on the basis of battery life there are projects other than Streisand that can cater to the need better than we can.

v-karbovnichy commented 6 years ago

I think it's too late for my message here. However, I will try.

Yesterday Russian government blocked over 18M of IP addresses of Amazon and Google. And I need some resources hosted there, and also some corporate resources hosted behind Kerio VPN and another L2TP/IPsec VPN.

My colleagues tested some other L2TP VPN servers to be a ground layer for all these things (for another 2 VPNs as a layer above), and it worked smoothly. I started seeking for VPN servers that I can host somewhere in DigitalOcean and found this project. What are the options for me now, when you had removed libreswan?

cpu commented 6 years ago

@v-karbovnichy I'm sorry to hear you disagree with our decision to remove support for LibreSwan from Streisand. Your feedback would be more helpful if you expanded on why L2TP/IPSec were the only option from the available Streisand services that met your needs.

What are the options for me now, when you had removed libreswan?

For an IPSec based solution you may want to evaluate https://github.com/trailofbits/algo This project focuses exclusively on IPSec and delivers a more consistent & secure experience than the L2TP/IPsec code that Streisand had. Streisand's support was using legacy options (IKEv1, PSK) that are known to be insecure.

v-karbovnichy commented 6 years ago

Thanks for the quick answer and suggestion for Algo. I will try to evaluate it and provide a response also here if I get any useful result.

dimzon commented 6 years ago

I believe the goal is to provide multiple protocols so users can chose most acceptable for concrete situation and device. So maybe it's time to merge Algo into streisand?

cpu commented 6 years ago

I believe the goal is to provide multiple protocols so users can chose most acceptable for concrete situation and device.

Yes, in the abstract. In the concrete we have to balance our ability to deliver a secure implementation that addressses best-practices. We also have to balance the availability and interests of the volunteer maintainers, the burden the protocol introduces, the benefits the protocol offers, and the alternatives available if Streisand doesn't provide it. In this case its clear that our implementation was not secure, did not follow best practices, was not being maintained well, and there is a strong alternative with a better implementation already.

So maybe it's time to merge Algo into streisand?

This is not a tenable solution. The Algo project has historically been aggressively uninterested in the goals of the Streisand project. Adopting Algo's modern IPSec configurations would not address any of the support/maintenance burden described in this thread. Worse, we would be playing catch-up with an uncooperative upstream with different goals. We would be back in this situation months after merging Algo's code. I strongly encourage folks that want an IPSec solution to just run Algo.

Speaking honestly i'm tempted to close this thread for further discussion. I appreciate that folks have interest in Streisand supporting IPSec but we've already made the decision and none of the feedback being provided is constructive or addresses the challenges that caused the decision to be made.

the-Arioch commented 3 years ago

Hello! Perhaps you better edit README.md ? The last lines imply support for L2TP and friends. Can you add there a remark like "Streisands no longer supports I2P/L2TP as of May 2018, but while we did you was of huge help" or something.

Formally, by publishing thanks you do not claim continuity or ever that all his help at least once came to working frution. Formally. But informally this clain in the homepage does implicate existing support. Thus, better be clarified immediately.