1
1
# webauthn-rs caBLE tunnel server
2
2
3
+ ** Important:** it is only necessary for an * authenticator vendor* to run a caBLE
4
+ tunnel service for their devices. Initiators (such as browsers and client
5
+ applications) connect to a tunnel service of the * authenticator's* choosing.
6
+
3
7
** Warning:** this is still a work in progress, and not yet fully implemented.
4
8
5
9
However, you can run a single-task tunnel service with the ` backend ` alone:
6
10
[ see ` ./backend/README.md ` for instructions] [ 0 ] .
7
11
8
- ** Important:** it is only necessary for an * authenticator vendor* to run a caBLE
9
- tunnel server for their devices. Initiators (such as browsers and client
10
- applications) connect to a tunnel server of the authenticator's choosing.
11
-
12
12
[ 0 ] : ./backend/README.md
13
13
14
14
## Background
@@ -27,14 +27,14 @@ As far as the tunnel server is concerned, what happens is:
27
27
28
28
2 . The authenticator connects to a tunnel server of its choosing, using HTTPS.
29
29
30
- 3 . The authenticator makes a WebSocket request to ` /cable/new/${TUNNEL_ID} ` .
30
+ 3 . The authenticator makes a WebSocket request to ` /cable/new/${TUNNEL_ID} ` [ ^ new ] .
31
31
32
32
4 . The tunnel server responds with a WebSocket handshake, and includes a 3 byte
33
33
routing ID in the HTTP response headers to indicate which task is serving
34
34
the request.
35
35
36
- 5 . The authenticator transmits the tunnel server ID and routing ID as as an
37
- encrypted Bluetooth Low Energy advertisement to the initiator .
36
+ 5 . The authenticator transmits the tunnel server ID and routing ID to the
37
+ initiator using an encrypted Bluetooth Low Energy advertisement.
38
38
39
39
6 . The initiator decrypts the advertisement, and connects to the tunnel server
40
40
using HTTPS.
@@ -44,8 +44,8 @@ As far as the tunnel server is concerned, what happens is:
44
44
45
45
8 . The tunnel server responds with a WebSocket handshake.
46
46
47
- 9 . The tunnel server relays WebSocket messages between the authenticator and
48
- initiator.
47
+ 9 . The tunnel server relays binary WebSocket messages between the authenticator
48
+ and initiator.
49
49
50
50
The initiator starts a Noise channel with the authenticator for further
51
51
communication such that the tunnel server cannot read their communications, and
@@ -56,6 +56,13 @@ limits, the tunnel server implementations are very simple. The tunnel server
56
56
itself does not need to concern itself with the minutae of the Noise protocol -
57
57
it only needs to pass binary messages across the tunnel verbatim.
58
58
59
+ [ ^ new ] :
60
+ This [ follows Google's caBLE URL convention] [ 2 ] . The URL used to establish a
61
+ new channel [ is not part of the FIDO 2.2 specification] [ 3 ] .
62
+
63
+ [ 2 ] : https://source.chromium.org/chromium/chromium/src/+/main:device/fido/cable/v2_handshake.cc?q=symbol%3A%5Cbdevice%3A%3Acablev2%3A%3Atunnelserver%3A%3AGetNewTunnelURL%5Cb%20case%3Ayes
64
+ [ 3 ] : https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#ref-for-client-platform①⓪
65
+
59
66
## Design
60
67
61
68
` webauthn-rs ` ' caBLE tunnel server consists of three parts:
85
92
### Frontend
86
93
87
94
** Warning:** The ` frontend ` is not yet fully implemented, and does not yet do
88
- everything described here. This would be necessary for a larger scale deployment
89
- of a caBLE tunnel server .
95
+ everything described here. This would be necessary to operate a
96
+ high-availability caBLE tunnel service .
90
97
91
98
** Source:** [ ` ./frontend/ ` ] [ frontend ]
92
99
0 commit comments