Peer-to-peer Browser Connectivity
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61597 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023159 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Connectivity (graph theory)Software maintenanceImplementationCommunications protocolSoftware developerSoftwareLibrary (computing)EncryptionJava appletAuthenticationComputer configurationComputing platformWeb browserFirewall (computing)UDP <Protokoll>Network socketDirected setPeer-to-peerConnected spaceWeb browserPublic key certificateHash functionMultiplication signGoodness of fitDimensional analysisLibrary (computing)Server (computing)AuthenticationContent (media)Computing platformProjective planeImplementationTouch typingDirection (geometry)LaptopCASE <Informatik>Web 2.0Computer fileRight angleInternetworkingWebsiteEmailCartesian coordinate systemNeuroinformatikSoftware engineeringSoftwareBitMobile appComputer architectureSelf-organizationEvent horizonFirewall (computing)INTEGRALValidity (statistics)Computer configurationTerm (mathematics)Internet service providerPairwise comparisonMatrix (mathematics)Power (physics)Latent heatParameter (computer programming)Different (Kate Ryan album)Computer animation
07:53
Web browserComputing platformNetwork socketDirected setUDP <Protokoll>Connectivity (graph theory)Computer configurationFirewall (computing)Public key certificateTransport Layer SecurityFormal verificationHash functionInternet forumFormal languageMessage passingSlide ruleWeb browserLaptopDialectValidity (statistics)Exterior algebraFirewall (computing)Domain nameStreaming mediaProper mapCASE <Informatik>AuthorizationMereologyImplementationServer (computing)Term (mathematics)Cartesian coordinate systemSoftwareLatent heatVideo gameRight angleInformation securityDirection (geometry)Connected spaceCuboidGoodness of fitBitPoint (geometry)Public key certificateDifferent (Kate Ryan album)Communications protocolMultiplication signBit rateNetwork socketReverse engineeringComputer animation
15:41
Program flowchart
Transcript: English(auto-generated)
00:05
Welcome to the first talk in the Network Dev Room, peer-to-peer browser connectivity. We're going to talk a bunch about WebRTC and the new Shiny Web Transport Protocol, and in general how to get the browser connected to a larger network.
00:24
First off, before we start, I'm very grateful to be here. Thanks to all the organizers. Thanks to all the volunteers making this event possible. That's wonderful. Yeah, and then thanks for all of you to be here and listen in. Cool.
00:41
Just a quick introduction about myself. I'm Max. I'm a software engineer at Protocol Labs. I'm starting the Lippy2P project. I'll do a brief introduction of what Lippy2P is, so don't worry too much about that. I'm maintaining the Rust implementation of the library. In a past life, you might know me from my Prometheus time. I worked a bunch on Prometheus, and its integration into Kubernetes.
01:03
I'm still a little bit active in that community. You find me anywhere on the web with MXN, and then on the website you find e-mails in case you want to get in touch. All right, so what is Lippy2P? Just a small disclaimer. The talk does mention Lippy2P from time to time.
01:24
It is not particularly important, so in a sense if you want to build your own peer-to-peer application, all the content here is applicable for you as well, but if you want to have this pre-built, you can leverage Lippy2P. Okay, so what is Lippy2P? Lippy2P, as you can infer from the name, I'm guessing, is a peer-to-peer networking library.
01:44
It has one specification, and then that specification is implemented in many, many different languages, like, for example, Go, JS, Rust, NIM, C++, Java, but a couple of others as well. The goal of Lippy2P is provide low-level features like encryption, authentication, hole punching, and things like that,
02:05
and then on top of that, leverage those features to then also provide higher-level protocols, like, for example, DHT, a distributed hash table, or gossiping protocols, or things like that. Yeah, and my big slogan always is Lippy2P is all you need to build peer-to-peer applications on the Internet.
02:29
Okay, wonderful. One small disclaimer that's important later on is, that I want to highlight here, is Lippy2P always encrypts and always authenticates, and we'll go into that later on, what that means,
02:44
but that's very important for me. Like, we don't ship any traffic over the Internet that is ever unencrypted or not authenticated, and in terms of authentication, I'm talking about mutual authentication. Okay, that's enough introduction for today, and now to the actual topic.
03:03
What I want to convey today is how we can get from here, from the left side, to the right side. So my great motivation is for browsers to be first-class citizens in networked applications. Now, on the very left side, you see the typical Internet application today.
03:25
So you have a browser, I'm using the Firefox logo here, but you can use any browser, really, that tries to interact with a networked application somewhere in the Internet. Instead of interacting with the nodes directly, it acts through a server,
03:41
and that server acts on behalf of the browser, right? The browser pretty much never interacts with the whole network. And to put this with an example, if you, for example, have a file sharing, you want to share a file. So for example, from my laptop here, I want to share a file with all of you. I would usually upload that to a server, and then all of you would download it from that server.
04:03
We would never interact directly. Now, there are many reasons for that to be a good architecture, right? Browsers usually move a lot. They might be in the living room, then in a cafe, and then at a conference in Fosdam. And they are usually low power.
04:22
But what's the most heard argument for this kind of architecture in comparison to the right architecture is that you cannot connect to browsers, and that browsers cannot connect to other nodes. That's oftentimes heard, right? And what I want to convey here today is that you can actually nicely connect a browser to a whole network,
04:45
and that the browser actually has a lot of connectivity options out there, and I want to go through these. And the next time you design a networked application, maybe you want to consider the architecture on the right versus the architecture on the left.
05:00
All right, cool. When it comes to connectivity for a browser, I want to differentiate this in two dimensions. And the first dimension is whether my node, whatever, for example, my computer here, is public or private. So can it be reachable directly, or is it behind an app or firewall, and or firewall?
05:23
And public you would usually refer to as a server, and then private you would, for example, refer to my laptop or the browser running on my laptop. Cool. Then the other dimension when we talk about connectivity, I want to differentiate in two platforms, which is browser and non-browser.
05:41
Why is this relevant? Well, there are a lot more platforms I know, but usually it's the non-browser, which is very unrestricted in terms of, for example, I have access to UDP or TCP socket, and then I have the browser, which is very restricted, where sometimes I can't make a connection without, for example, a valid TLS certificate.
06:02
Wonderful. My goal today is we fill this matrix now with the different options that we have, and this way I can convey the fact that, actually, browsers can be first-class citizens in network applications. All right, so let's talk about public non-browser into public non-browser.
06:23
I'm in the network dev room. This is the easiest one. I'm not going to explain this much. Reachability, both nodes are public. We can just reach out to them directly over IP and TCP, or then UDP and the shiny new QUIC. We don't have firewalls and that on either side,
06:41
and the platform, which is non-browser, so, for example, an application running on my laptop has direct access to the TCP and UDP socket. Cool. So we have that. Then private non-browser to public non-browser. Again, really easy.
07:00
You do this every day by any application on your laptop going to a server. We don't have any firewalls and or NATs at the receiver side, so on the server side. The left side is private, but we don't really care as we have the direction from the left to the right. And then the platform, again, we're not running in the browser,
07:21
so we're pretty unrestricted. We probably have access to a TCP or UDP socket. Wonderful. To make this a little bit more complex, what if I'm a public non-browser connecting to a private non-browser? So what does that mean? For example, on the left, that could be a server,
07:41
and then on the right, that could be some application running on my laptop right now. What we can do here is something called connection reversal, simply where my laptop connects to some public node. Then whoever wants to reach out to me reaches out to that public node as well, relays the message to me, my laptop,
08:01
and then my laptop dials whoever wanted to dial me initially. This is depicted here. So B connects to the relay R, and then A relays a network over R to B, and then B can actually connect to A, which is commonly referred to as connection reversal. In terms of platform, again, we're non-browser,
08:21
so access to TCP and UDP sockets, so we're all good. Cool. And then the last one I want to fill before it becomes complicated, namely before we introduce a browser, is private non-browser to private non-browser. You see this depicted down there as A and B.
08:41
Reachability really sucks. Both are probably behind NATs or firewalls, so not much luck there. So what we need to employ here is a technique called hole punching. I don't have much time today in this talk, but we have another talk later on. So if you want to learn all about hole punching or what success rate we have across different protocols
09:03
or IP stacks, join the talk. I think it's at 11.45. So we'll go a bunch into that. Just a short, brief one. A and B want to connect. Both are behind firewalls. Both connect to a relay R. That R is public. They coordinate a hole punch over that relay
09:22
and then execute that hole punch through both of their firewalls. Cool. In terms of platforms, again, we're not on the browser yet, so we have access to the TCP and UDP socket. All good. Life is pretty easy. Wonderful. All right. Now comes complexity, which is the browser world.
09:44
And what I want to talk about first is what if I'm a private browser. Now, private browser is somewhat of a weird term. Usually you're not at FOSTM and you don't have a public IPv4 or IPv6 address, so browsers are usually always private,
10:02
which I'm not suggesting to change. Definitely not. There are many security considerations to keep it that way. But what if I want to connect from a private browser to a public non-browser? So what if I, for example, want to connect from my laptop within my browser to some server?
10:23
Now, this, again, sounds pretty easy to everyone, except one small disclaimer. Again, we don't have a firewall or NAT at the receiver side. A server is public depending on the firewall rules, obviously, but we can easily reach out to them. In terms of platform, we are on the browser,
10:42
so we're quite restricted in the sense of what we can do. Eventually I want to end up with a byte stream between the two endpoints, so what I'm restricted to is either WebSockets. Everyone knows that. So TCP, TLS, HTTP, then an upgrade, and then I have WebSocket.
11:00
The problem with that is I need a valid TLS certificate, so I need the remote server to either have a signed IP certificate or based on a domain. So that's a bummer. What I can do as an alternative in the browser is use the shiny new WebTransport, which is basically, I'm simplifying a lot here,
11:21
but basically WebSockets on top of QUIC or HTTP3. WebTransport actually allows us to handle self-signed certificates, and then as a last alternative, we can use WebRTC to get a byte stream. WebRTC gives us data channels, so in the end we can run on IP, UDP, then SCTP,
11:42
and then use data channels from WebRTC. Now, before you scream this is insecure, the small disclaimer that I did at the beginning is, in case you built this yourself, you still need to figure out proper authentication, right? Because self-signed certificates, you're not part of the authority trust chain.
12:06
But otherwise, yeah, these are your options. So WebSocket, WebTransport, and WebRTC. Cool. So what if I want to connect from a public non-browser to a private browser?
12:22
We had this in the past couple of slides back. In terms of reachability, my left side is reachable, my right side is not reachable, so what I can do, I don't need to do fancy hole punching, I can just do connection reversal right over the relay, where A asks B basically to dial it back over the relay.
12:44
In terms of platform, we don't have direct access to the TCP or UDP socket, given that on the right side we have a browser in the whole stack, so that's a bummer. We can do WebSockets in case we have a valid TLS certificate signed by some authority. If not, we can do WebTransport and WebRTC.
13:05
Cool. And now comes the very hard part, or not very hard part, but a little bit more difficult part, which is private browser to private browser, or what is basically the same is, was it private non-browser to private browser,
13:22
or private browser to private non-browser? All the red boxes down there. In terms of reachability, we need to leverage hole punching at this point. Both endpoints are behind the firewall and are not, right? So again, we'll go more into details on how hole punching works.
13:43
Probably a lot of you are already familiar with that. In terms of platforms, at least one of our two sides are behind our browsers, so that means we don't have access to TCP or UDP socket directly. Why am I always saying no access to TCP and UDP?
14:01
That's relevant because you don't control the ports, and this way you don't have the capability of hole punching yourself. But what the browser gives us is WebRTC. WebRTC has hole punching built in, so what we can do is leverage WebRTC and some signaling server R in the middle to then do the actual hole punch.
14:24
WebSockets doesn't work because we can't hole punch with WebSockets, and WebTransport doesn't work either because we can't hole punch with WebTransport either. Okay, wonderful. And that concludes the whole matrix, and what I'm pretty much showing here is
14:41
you can connect a browser to everyone out there that runs on IP, and that means your application can actually make the browser a first-class citizen within your network. Cool. That's all from my end. Yeah, I'll be around the venue for quite a bit.
15:02
If you want to learn more about LippyDB in general, which makes all this nicely packaged for you, you can visit docs.lippydb.io. If you want to see all the nitty-gritty details about the different transports and what that means for, I don't know, for example, you sign TLS certificate or where you can hole punch, that would be on connectivity.lippydb.io.
15:24
There are various forums. There's a specification online, and then, yeah, all the implementations are open source, so you can just check that out on github.com slash LippyDB. Cool. That's all from my end. Thank you very much.