"Our protocol has security against honest-but-curious adversaries. This means that as long as both participants follow the protocol honestly, neither will learn more than the size of the intersection and the intersection-sum. However, if a participant deviates from the protocol, it is possible they could learn more than the prescribed information."
Also:
"Disclaimers: This is not an officially supported Google product. The software is provided as-is without any guarantees or warranties, express or implied."
Algo (another commenter mentioned it[1]) allows you to set this up to be the default for the VPN, very nice feature. I use it on my phone since I often connect to random wifi APs. More and more of the web is moving to HTTPS but a disturbing amount of unencrypted traffic abounds.
Yep, Algo uses the same approach. It's generating device configuration profiles with the necessary settings. I'm generating mine in the same way but slightly different to allow toggling Ethernet and to support the OpenIKED ciphers etc.
> The only way to configure this however is using the Apple Configurator tool and create a custom profile.
'Activate on demand' is just a checkbox in WireGuard app settings on iOS, so apparently it's only the built-in VPN types that need Apple Configurator. Since IPSEC/IKEv2 are overengineered and L2TP is outdated, you're better off using wg anyway.
On the client, is it possible to setup an “always on” VPN? Such that when the client restarts on reboot, there is no internet connection until the VPN is on. Or when either the client or server glitches, the end point computer/mobile does not connect to the internet in the clear?
“Thinking about what's next, I returned to my roots, rented the original Google office where I started my career, and founded a lab with my longtime friend and teammate @eamunozt. A bit of info: lumilabs.com”
PubNub is more of an end-to-end system. Clients knowingly connect to PubNub, and they can even publish messages to each other.
Fanout is primarily server-side tech. Clients don't necessarily have to know they are connecting to a Fanout-powered service, and only the server publishes messages.
Integrating with Fanout is a little more involved than PubNub, due to the need to set up an origin server, but the advantage is you own your API contract and avoid any lock-in. This can be particularly useful if your API is public.
No. Disregarding technicalities of which there are many, the most important difference is that with ssh you either get the host key through a different secure channel or "trust on first use" (TOFU). With HTTPS you trust certificate authorities (CA).
I was referring to the browser side certificate that can be generated using the <keygen> tag, and then used for the subsequent HTTPS sessions. Would this be equivalent to ssh-keygen for SSH?
That's deprecated though and afaik, that's only the client-side authentication, not the server-side. That still relies on CAs, with all the disadvantages.
I am actually working on build something similar. So, you could roll out an app-specific VPN like secure tunnel real easy. It is inspired by the work at Google IT called BeyondCorp [1].
The target market is companies whose employees require secure remote access to internal apps, but IT does not want to give a broad network access via VPN. So, marketing/sales like employees who simply want to access internal portals, etc. without the hassle of dialing into a VPN.
Besides Cloudflare being the biggest man-in-the-middle on the internet, their DDoS mitigation offering is also questionable. If you google "clouflare bypass" [1], you get to websites that can tell you the origin IP address of a cloudflare customer's domain name. So, malicious guys could hit the real IP directly.
> If you google "clouflare bypass", you get to websites that can tell you the origin IP address of a cloudflare customer's domain name.
Those rely on a known DNS history from before CloudFlare was added to a domain. If bypass is a concern, changing the server's IP and making sure it never shows up in a public DNS record again solves things.
Yes, DNS history is one way to leak your IP. There are several other ways that the origin IP may get leaked, so you should be very careful if you use Cloudflare:
* Keep all subdomains on CloudFlare
* Don't use wildcard subdomains if you are not on Pro account
* Don't host mail or other services on the same server as your web server (email headers have origin IP)
* Never initiate an outbound connection based on user action
* Make sure that your web server and web application are patched against all known information disclosure vulnerabilities.
* Change your origin IP once configured for maximum DDoS protection on CloudFlare
