It is wrong. Warp is the third-party implementation. It would be amazing if it could be made to work from standard wireguard, but I suppose there's a chance that if desktop versions arrive, you'll be able to extract the keys. The only thing stopping that would be if Cloudflare broke the protocol.
We can argue about the terminology but from the perspective of the company other WireGuard clients (including the official ones) are 'third-party' in the sense that we don't control them. That makes supporting users of those clients more expensive for us (e.g. we currently have a mobile app for Warp, someone calls our support asking for help with a Linux client...)
Not supporting a configuration is much different than actively prohibiting it.
It's okay to just say, "Hey, we are running a free VPN. We're making some privacy guarantees and are trying to log as little as possible. That exposes us to being abused, which means that we have to put some limits in-place on the client."
You've built a product (warp) based on Wireguard and refused to work with the upstream project - so saying that you're pushing standards is far more nuanced than you make it seem - at best. https://news.ycombinator.com/item?id=19500725
Forking an upstream project to implement decisions without upstream’s consent is a tried and true open source software process, implemented by thousands of projects over the years. Claiming that they don’t support standards, solely because they don’t support another implementation of those standards, is incorrect and inflammatory.
> Forking an upstream project to implement decisions without upstream’s consent is a tried and true open source software process, implemented by thousands of projects over the years. Claiming that they don’t support standards, solely because they don’t support another implementation of those standards, is incorrect and inflammatory.
If upstream is doing something you don't like and refusing to work with you, sure.
When upstream actively petitions you to not fork, asks you politely to work together, and you refuse to work with them, that is far, far from a "tried and true open source software process". That creates a fissure in the community and it generally ends up poorly for everyone involved.
My comment is far from inflammatory, it's a statement of fact, and something cloudflare has refused to acknowledge or respond to. Which just further drives the point home that they aren't acting in good faith.
I disagree with this statement. We haven't pushed incompatible standards or any other nonsense. We've literally pushed out the latest standards and enabled more encryption (see Universal SSL making SSL free years before Let's Encrypt; see enabling IPv6; enabling HTTP/2; etc. etc.). As for HTTP/3... so will we. See: https://blog.cloudflare.com/http-3-from-root-to-tip/ , https://blog.cloudflare.com/the-road-to-quic/ an…
Fair point. I especially appreciate that even Workers is based on a W3C standard, when it could have been a proprietary API. However, Cloudflare has also adopted and promoted at least one standard that adds complexity for dubious benefit, specifically DNSSEC, which tptacek has repeatedly criticized (e.g. [1]). Moreover, Cloudflare is encouraging both providers and consumers to bypass the public Internet as much as po…
DNSSEC is a standard. We literally adopted and promoted a standard. That is not about your original comment about us trying to take over the Internet or something. And we work hard on the standards-based Internet pushing HTTP/2, IPv6, QUIC, TLS 1.3, ...
I'd wager that the Super Secret Plan is geared towards further centralizing the Internet. Preferably on Cloud Flare's infrastructure. This is one part of a tug-of-war that's going on in recent years between Internet network operators and cloud providers, with the cloud providers slowly but surely winning. For better or worse, we are moving away from a distributed Internet composed of many autonomous networks into a f…
Here's the issue that everything fights when talking about Centralization vs Decentralization.
Centralization is far easier to manage. A single entity has the ability to control all routes and all the pieces of the network. The structure can become faster, mesh-networks are notoriously slow. By using a VPN + Argo cloudflare has control over how your data is routed, and can make sure it skips slow network segments, is peered well, etc.
Decentralization doesn't require trust if implemented correctly. This is it's biggest selling point IMO. If implemented correctly (which is hard to do) it can have better uptime, as we aren't relying on any single entity. But, with meshnetworks as an example, a specific route could be slower then the others, and there's often not much you can do about it. Decentralization if not implemented correctly is a nightmare on so many levels. There's nobody to appeal to if an issue occurs. If trust isn't implemented correctly (current state of ISPs) then we have multiple parties who can spy/modify your communications.
Oddly https://8.8.8.8 doesn't have a legit cert though (even though the cert for 8888.google does have an IP address alt)
It does I think - Certificate[1] info: - subject `CN=Google Internet Authority G3,O=Google Trust Services,C=US', issuer `CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R2', serial 0x01e3a9301cfc7206383f9a531d, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-06-15 00:00:42 UTC', expires `2021-12-15 00:00:42 UTC', pin-sha256="f8NnEFZxQ4ExFOhSN7EiFWtiudZQVD2oY60uauV/n78=" - Status: The certificate is tru…
> Firefox does not trust this site because it uses a certificate that is not valid for 8.8.8.8. The certificate is only valid for the following names: .c.docs.google.com, .a1.googlevideo.com, .c.2mdn.net, .c.audiobooks.play.google.com, .c.bigcache.googleapis.com, .c.chat.google.com, .c.doc-0-0-sj.sj.googleusercontent.com, .c.drive.google.com, .c.googlesyndication.com, .c.googlevideo.com, .c.inbox.google.com, .c.lh3-da.googleusercontent.com, .c.lh3-da.photos0.sandbox.google.com, .c.lh3-db.googleusercontent.com, .c.lh3-db.photos1.sandbox.google.com, .c.lh3-dc.googleusercontent.com, .c.lh3-dc.photos2.sandbox.google.com, .c.lh3-dd.googleusercontent.com, .c.lh3-dd.photos3.sandbox.google.com, .c.lh3-de.googleusercontent.com, .c.lh3-de.photos4.sandbox.google.com, .c.lh3-df.googleusercontent.com, .c.lh3-df.photos5.sandbox.google.com, .c.lh3-dg.googleusercontent.com, .c.lh3-dg.photos6.sandbox.google.com, .c.lh3-dz.googleusercontent.com, .c.lh3-dz.photos-autopush.sandbox.google.com, .c.lh3.googleusercontent.com, .c.lh3.photos.google.com, .c.mail.google.com, .c.offline.maps.google.com, .c.pack.google.com, .c.play.google.com, .c.video.google.com, .c.youtube.com, .cache1.c.docs.google.com, .cache1.c.play.google.com, .cache1.c.video.google.com, .cache1.c.youtube.com, .cache2.c.docs.google.com, .cache2.c.play.google.com, .cache2.c.video.google.com, .cache2.c.youtube.com, .cache3.c.docs.google.com, .cache3.c.play.google.com, .cache3.c.video.google.com, .cache3.c.youtube.com, .cache4.c.docs.google.com, .cache4.c.play.google.com, .cache4.c.video.google.com, .cache4.c.youtube.com, .cache5.c.docs.google.com, .cache5.c.play.google.com, .cache5.c.video.google.com, .cache5.c.youtube.com, .cache6.c.docs.google.com, .cache6.c.play.google.com, .cache6.c.video.google.com, .cache6.c.youtube.com, .cache7.c.docs.google.com, .cache7.c.play.google.com, .cache7.c.video.google.com, .cache7.c.youtube.com, .cache8.c.docs.google.com, .cache8.c.play.google.com, .cache8.c.video.google.com, .cache8.c.youtube.com, .dai.googlevideo.com, .googlevideo.com, .googlezip.net, .gvt1.com, .offline-maps.gvt1.com, .snap.gvt1.com, .xn--ngstr-lra8j.com, xn--ngstr-lra8j.com
Asked differently, do you plan on explicitly disallowing/banning it if people unofficially ran the reference implementation against Warp? It would be nice to know the policy there. For those of us that do know what a VPN is, and are okay not having access to support, getting things to work without a desktop app would be nice.
I think my answer was pretty clear. We do not currently plan to allow stock WireGuard clients to use Warp. I say, currently, because things can always change. It's important to appreciate that we have literally millions of users for the 1.1.1.1 App and we are rolling out a free VPN for them. That is a huge support and network burden that we have to deal with to make that experience work well. Yes, we use WireGuard un…
> huge support and network burden
I don't think anyone on Linux setting up and tweaking WireGuard to integrate with CloudFlare's free network expects to be able to call up support and be like "hey, I need help debugging my custom client." :-) As far as network burden, you're just concerned that we'll be using too much traffic?
It's good have another VPN from a player with huge network infrastructure like Cloudflare, but the article seems to digress frequently. >TCP, the foundational protocol of the Internet, was never designed for a mobile environment. Packet loss due this is mentioned, but I don't see a relevance to the new VPN service; especially when the next section talks about wrap using UDP. > We’ve built Warp around a UDP-based prot…
> Other VPN providers do offer an option of choosing TCP/UDP as per usage i.e. better reliability vs faster speed.
I don't think TCP-based VPNs are offered for increased reliability. They might be offered so you can run your VPN traffic in restricted scenarios, e.g. I run a VPN-ish service that uses TCP/443 by default and all connections are only outbound, so you can still use your VPN in restrictive scenarios.
Outside that, encapsulating TCP inside TCP is nothing short of a headache as you have two congestion control algorithms kicking in and one doesn't know about the other.
Fair point. I especially appreciate that even Workers is based on a W3C standard, when it could have been a proprietary API. However, Cloudflare has also adopted and promoted at least one standard that adds complexity for dubious benefit, specifically DNSSEC, which tptacek has repeatedly criticized (e.g. [1]). Moreover, Cloudflare is encouraging both providers and consumers to bypass the public Internet as much as po…
DNSSEC is a standard. We literally adopted and promoted a standard. That is not about your original comment about us trying to take over the Internet or something. And we work hard on the standards-based Internet pushing HTTP/2, IPv6, QUIC, TLS 1.3, ...
Touché on DNSSEC. That only confused things. But the rest of my comment still stands.
> We built Warp around WireGuard So basically Cloudflare created an app with Cloudflare branding and set up a Wireguard server for everyone. No bad, but just check out the original: https://www.wireguard.com While I am not a big fan of VPNs in general, I have to admit, that Wireguard performs exceptionally well. I tested it a week ago and the added latency is pretty much just the network latency and the bandwidth los…
I consider myself fairly competent, and I couldn’t understand the wireguard documentation enough to setup my own install without resorting to algo [0]. There’s real value in wrapping a system like WireGuard into a product, because it democratizes technology rather than making it available only to those knowledgable enough to understand how to set it up. I think Warp is great in that regard.
Site should load just fine without eDNS -- even "geo-specific" ones. They will just route you as if you came from your local Cloudflare PoP rather than your home IP; usually not a big difference since Cloudflare is in so many locations. I'm not having any trouble with bbc.co.uk on 1.1.1.1, maybe it was a temporary hiccup. (Disclosure: I work for Cloudflare but not on this product.)
> not a big difference I am getting more than 300ms difference to google.com https://pastebin.com/raw/QnbWXU1a
Ouch. Do you know which PoP (point of presence) you're hitting? To find out, Look at the last three letters in the CF-Ray header on any response from a Cloudflare site, e.g.
curl -v cloudflare.com 2>&1 | grep -i CF-Ray
The letters should correspond to an airport code nearby the CF server you landed on. Let me know what it says.