7 ms·
We have built a VPN over QUIC, and the core code is open source already [0]. We're working on standardizing "IP Proxying" over QUIC as part of the MASQUE worki
by achernya 5y ago
We have built a VPN over QUIC, and the core code is open source already [0].
We're working on standardizing "IP Proxying" over QUIC as part of the MASQUE working group at IETF. So far, we've adopted a requirements document [1] and have started work on an implementation [2].
[0] https://quiche.googlesource.com/quiche/+/refs/heads/master/quic/qbone/ https://quiche.googlesource.com/quiche/+/refs/heads/master/q...
[1] https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-01 https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-...
[2] https://tools.ietf.org/html/draft-cms-masque-connect-ip-00 https://tools.ietf.org/html/draft-cms-masque-connect-ip-00
- tankenmate 5y agoI can see a number of jurisdictions around the world either blocking and/or profiling this sort of traffic. Is any form of "chaffing" / plausible deniability built into the protocol?
- achernya 5y agoRight now we're focusing on building a functional core protocol and making sure it's sufficiently extensible. It should be possible to build chaffing as an add-on extension down the line.
- saurik 5y agoIn #2, why is the path hardcoded to /? One of the things I've considered somewhat important in my similar work (on Orchid, using HTTPS+WebRTC) is the ability to "embed" a VPN as a sub-resource on some existing website.
- therein 5y agoFun to imagine some application layer firewall somewhere go: "that /static/css/style.css sure is large and requiring a lot of two way communication".
- giovannibonetti 5y agoA firewall would be a great place to add some machine learning
- zrm 5y agoA little bit Poe's Law there, but I'll assume you're serious and point out the problem. Machine learning has non-trivial false positives. We don't need firewalls launching denial of service attacks on legitimate traffic at random.
- Xylakant 5y agoI’ve seen an IDS decide to classify all traffic, including management traffic as hostile. The result was an outage for one of the larger web shops in germany.
- codetrotter 5y agoWell, it is said that the only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards. Blanket denying all traffic is a good first step to ensuring that the system is really, really secure :P
- meowface 5y agoSounds like an IPS. An IDS basing its fundamental action (detection) partly on ML can definitely be a good, valuable idea. An IPS basing its fundamental action (blocking traffic) partly on ML is the problem.
- avianlyric 5y agoIt’s doesn’t really make any difference does it? The path isn’t used to indicate an IP packet flow, the “CONNECT-IP” method is what indicates the you want to send an IP packet flow to the server. You could use the path to indicate different VPN endpoints, but ultimately the path isn’t needed at all. Additionally all of this is gonna be inside a TLS session, so no external viewer will ever see any of the headers, including the path. TL;DR the RFC doesn’t make this VPN endpoint a traditional http resource at all. It a special new HTTP method (like GET or POST) that indicates the client wants the server to treat the following data as an IP stream.
- saurik 5y agoFWIW, I do get that it is its own method and I understand the intent of the specification (and thereby why it "wouldn't matter" in that worldview), but it feels weirdly non-HTTP for this functionality to not be treated as a resource... but like, I guess "fair enough" in that (looking at it again) the existing old-school proxy CONNECT method also has this flaw :/. I just feel like people should be able to easily "mount" functionality onto their website into a folder, and by and large most HTTP methods support this, with the ability to then take that sub folder and internal-proxy it to some separate backend origin server (as like, I would want to take the flows for anything under /secret/folder/--whether GET or PUT or PROPPATCH or CONNECT-IP--and have my front-end http terminator be able to transparently proxy them, without having to understand the semantics of the method; it could very well be that I am just living in a dream of trying way too hard to be fully-regular in a world dominated by protocols that prefer to define arbitrary per-feature semantics ;P). I guess I am also very curious why you aren't defining this over WebTransport (which would allow it to be usable from websites--verified by systems like IPFS--to build e2e-encrypted raw socket-like applications, as I imagine CONNECT-IP won't be something web pages will be able to use). (For anyone who reads this and finds this thought process "cool", talk to me about Orchid some time, where I do e2e multi-hop VPN over WebRTC ;P.)
- aasasd 5y agoThe Great Firewall does probing for ages now. It pauses the connection and sends its own request, checking what kind of protocol the server returns. Nothing stops these firewalls from trying ‘connect-ip’. The path could be used as a secret ‘key’ to thwart too-curious firewalls (though the protocol probably won't do much against DPI anyway).
- achernya 5y agoFollowing up on this, there's discussion on github [1] about this, and we're currently leaning towards allowing URIs. [1] https://github.com/DavidSchinazi/draft-cms-masque-connect-ip/issues/13 https://github.com/DavidSchinazi/draft-cms-masque-connect-ip...