Securing Protocols with Fully Encrypted Protocols (FEPs)
B
y
t
e
s
t
o
S
c
h
l
e
p
?
U
s
e
a
F
E
P
:
H
i
d
i
n
g
P
r
o
t
o
c
o
l
M
e
t
a
d
a
t
a
w
i
t
h
F
u
l
l
y
E
n
c
r
y
p
t
e
d
P
r
o
t
o
c
o
l
s
E
l
l
i
s
F
e
n
s
k
e
(
U
.
S
.
N
a
v
a
l
A
c
a
d
e
m
y
)
A
a
r
o
n
J
o
h
n
s
o
n
(
U
.
S
.
N
a
v
a
l
R
e
s
e
a
r
c
h
L
a
b
o
r
a
t
o
r
y
)
M
a
y
2
6
t
h
,
2
0
2
4
C
r
y
p
t
o
g
r
a
p
h
i
c
A
p
p
l
i
c
a
t
i
o
n
s
W
o
r
k
s
h
o
p
(
C
A
W
2
0
2
4
)
2
F
u
l
l
y
E
n
c
r
y
p
t
e
d
P
r
o
t
o
c
o
l
s
(
F
E
P
s
)
1.
All bytes look random
2.
Message lengths variable
App
client
App
server
FEP
client
FEP
server
W
h
a
t
i
s
a
F
u
l
l
y
E
n
c
r
y
p
t
e
d
P
r
o
t
o
c
o
l
(
F
E
P
)
?
Real-world examples:
▪
obfs4 / lyrebird (Tor)
▪
shadowsocks (Outline VPN)
▪
Obfuscated SSH (Psiphon)
▪
OpenVPN + XOR patch
▪
Vmess (V2Ray)
3
S
u
m
m
a
r
y
o
f
O
u
r
W
o
r
k
▪
Goals not formalized mathematically
▪
Security cannot be proven
▪
Existing FEPs continually present security flaws
▪
IND$-CPA: similar goal but for atomic messaging
P
r
o
b
l
e
m
:
N
o
p
r
e
c
i
s
e
u
n
d
e
r
s
t
a
n
d
i
n
g
o
f
F
E
P
s
S
o
l
u
t
i
o
n
s
:
1.
New security definitions for FEPs
2.
Relations among new and existing security definitions
3.
Secure constructions of FEPs
4.
Analysis of existing FEPs
4
S
t
a
t
u
s
o
f
t
h
i
s
W
o
r
k
▪
Presented early version of this work at FOCI 2023
▪
Future Work from that talk:
1.
Proving security of our construction
2.
Deriving relations between the security definitions
3.
Addressing forward secrecy via key exchange in the
protocol
4.
Extending our definitions to the datagram setting
5
S
t
a
t
u
s
o
f
t
h
i
s
W
o
r
k
▪
Presented early version of this work at FOCI 2023
▪
Future Work from that talk:
1.
Proving security of our construction
2.
Deriving relations between the security definitions
3.
Addressing forward secrecy via key exchange in the
protocol
4.
Extending our definitions to the datagram setting
6
S
t
a
t
u
s
o
f
t
h
i
s
W
o
r
k
▪
Presented early version of this work at FOCI 2023
▪
Future Work from that talk:
1.
Proving security of our construction
2.
Deriving relations between the security definitions
3.
Addressing forward secrecy via key exchange in the
protocol
4.
Extending our definitions to the datagram setting
▪
Added experimental analysis of existing FEP security
7
S
t
a
t
u
s
o
f
t
h
i
s
W
o
r
k
▪
Presented early version of this work at FOCI 2023
▪
Future Work from that talk:
1.
Proving security of our construction
2.
Deriving relations between the security definitions
3.
Addressing forward secrecy via key exchange in the
protocol
4.
Extending our definitions to the datagram setting
▪
Added experimental analysis of existing FEP security
▪
Paper available:
▪
Ellis Fenske and Aaron Johnson. “Bytes to Schlep?
Use a FEP: Hiding Protocol Metadata with Fully
Encrypted Protocols”. May 2024.
▪
<
https://arxiv.org/abs/2405.13310
>
W
h
y
F
E
P
?
Existing encrypted protocols reveal metadata
▪
Protocol identity and version
▪
Amount of payload data
▪
Cryptographic primitives being used
E
x
a
m
p
l
e
1
:
T
L
S
R
e
c
o
r
d
E
x
a
m
p
l
e
2
:
W
i
r
e
G
u
a
r
d
D
a
t
a
g
r
a
m
9
W
h
y
F
E
P
?
F
E
P
R
e
a
s
o
n
#
1
:
C
e
n
s
o
r
s
h
i
p
c
i
r
c
u
m
v
e
n
t
i
o
n
▪
Typical VPN protocols can easily be identified and
blocked
▪
e.g. OpenVPN, WireGuard, IPSec
▪
Censors have blocked VPN protocols (e.g. China,
Russia)
▪
FEPs have been invented multiple times to eliminate
simple protocol fingerprints (e.g. obfs4, shadow
socks, Obfuscated SSH, Vmess)
▪
China has blocked FEPs: Wu et al. “How the Great
Firewall of China Detects and Blocks Fully Encrypted
Traffic”. USENIX Security 2023.
10
10
W
h
y
F
E
P
?
F
E
P
R
e
a
s
o
n
#
2
:
M
a
x
i
m
a
l
l
y
p
r
o
t
e
c
t
s
m
e
t
a
d
a
t
a
▪
Protocols increasingly protect metadata
▪
QUIC
▪
TLS 1.3 Encrypted Client Hello
▪
Cryptocurrencies (Ethereum’s RPLx, Lightning’s Bolt)
▪
Metadata can be sensitive
▪
Application(e.g. application-specific protocols)
▪
Domain of the destination (e.g. SNI TLS extension)
▪
Ciphertext primitives in use (some might be vulnerable)
11
11
W
h
y
F
E
P
?
F
E
P
R
e
a
s
o
n
#
3
:
P
r
e
v
e
n
t
s
I
n
t
e
r
n
e
t
o
s
s
i
f
i
c
a
t
i
o
n
▪
Middleboxes develop around observable protocol features
▪
Security firewalls
▪
Traffic shapers
▪
Alternate solution: David Benjamin. 2020. RFC 8701
Applying Generate Random Extensions And Sustain
Extensibility (GREASE) to TLS Extensibility
12
12
W
h
y
F
E
P
?
▪
“
P
r
i
v
a
c
y
:
A
t
h
i
r
d
p
a
r
t
y
…
c
a
n
n
o
t
t
e
l
l
w
h
e
t
h
e
r
t
w
o
c
o
n
n
e
c
t
i
o
n
s
a
r
e
u
s
i
n
g
t
h
e
s
a
m
e
p
s
e
u
d
o
r
a
n
d
o
m
c
T
L
S
t
e
m
p
l
a
t
e
”
▪
“
O
s
s
i
f
i
c
a
t
i
o
n
r
i
s
k
”
▪
“
T
O
D
O
:
M
o
r
e
p
r
e
c
i
s
e
s
e
c
u
r
i
t
y
p
r
o
p
e
r
t
i
e
s
a
n
d
s
e
c
u
r
i
t
y
p
r
o
o
f
.
T
h
e
g
o
a
l
w
e
'
r
e
a
f
t
e
r
h
a
s
n
'
t
b
e
e
n
w
i
d
e
l
y
c
o
n
s
i
d
e
r
e
d
i
n
t
h
e
l
i
t
e
r
a
t
u
r
e
s
o
f
a
r
,
a
t
l
e
a
s
t
a
s
f
a
r
a
s
w
e
c
a
n
t
e
l
l
.
”
E
n
c
r
y
p
t
e
d
P
r
o
t
o
c
o
l
s
Non-FEP encrypted protocols innovation is still occurring:
▪
OSCORE: IoT-optimized (2019)
▪
NoiseSocket: generic framework (2017)
▪
WireGuard: VPN (2017)
▪
Bolt: Lightning network (2016)
▪
RLPx: Ethereum (2015)
W
h
y
c
o
u
l
d
n
’
t
t
h
e
s
e
a
l
l
b
e
F
E
P
s
?
14
14
F
E
P
s
i
n
t
h
e
N
e
t
w
o
r
k
S
t
a
c
k
Generally assume over TCP or UDP
▪
Below transport layer limits developer
agility
▪
Requires permissions for raw-socket
access (e.g. iOS jailbreak)
▪
TCP and UDP are the common
transport protocols
▪
New reliable transports over UDP
▪
e.g. QUIC, kcp
▪
Difficult to accomplish while
protecting metadata
▪
FEP terms
▪
Datastream FEP (e.g.
using
TCP)
▪
Datagram FEP
(e.g.
using
UDP)
Application Layer
Transport Layer
Internet Layer
Data-Link Layer
Physical Layer
F
E
P
h
e
r
e
L
o
o
k
i
n
g
a
t
a
F
E
P
:
o
b
f
s
4
Tor’s obfs4 (aka lyrebird) is a sophisticated FEP
▪
Uses TCP
▪
Key exchange for forward secrecy
▪
Padding for message-length variation
▪
Handshake
1.
C
l
i
e
n
t
s
e
n
d
s
:
E
l
l
i
g
a
t
o
r
-
e
n
c
o
d
e
d
k
e
y
+
r
a
n
d
o
m
p
a
d
d
i
n
g
2.
S
e
r
v
e
r
s
e
n
d
s
:
E
l
l
i
g
a
t
o
r
-
e
n
c
o
d
e
d
k
e
y
+
r
a
n
d
o
m
p
a
d
d
i
n
g
▪
Data-phase messages
2 bytes
Frame length
16 bytes
MAC Tag
1 byte
Type
2 bytes
Payload length
(optional)
Payload
(optional)
Padding
Encrypted (Poly1305/XSalsa20)
XOR with PRG
L
o
o
k
i
n
g
a
t
a
F
E
P
:
o
b
f
s
4
2 bytes
Frame length
16 bytes
MAC Tag
1 byte
Type
2 bytes
Payload length
(optional)
Payload
(optional)
Padding
Encrypted (Poly1305/XSalsa20)
XOR with PRG
Security issues
1.
Length field is malleable
2.
obfs4 closes connection upon decryption error
3.
#1 + #2 = active attack reveals obfs4 message structure
4.
Specific minimum message length despite padding
L
e
t
’
s
d
e
f
i
n
e
F
E
P
s
e
c
u
r
i
t
y
t
o
r
u
l
e
o
u
t
s
u
c
h
i
s
s
u
e
s
.
17
17
N
e
w
F
E
P
S
e
c
u
r
i
t
y
D
e
f
i
n
i
t
i
o
n
s
1.
Passive security:
a.
D
a
t
a
s
t
r
e
a
m
:
F
E
P
-
C
P
F
A
(
F
E
P
u
n
d
e
r
C
h
o
s
e
n
P
l
a
i
n
t
e
x
t
-
F
r
a
g
m
e
n
t
A
t
t
a
c
k
s
)
b.
D
a
t
a
g
r
a
m
:
F
E
P
-
C
P
A
(
F
E
P
u
n
d
e
r
C
h
o
s
e
n
P
l
a
i
n
t
e
x
t
A
t
t
a
c
k
s
)
2.
Active security:
a.
D
a
t
a
s
t
r
e
a
m
:
F
E
P
-
C
C
F
A
(
F
E
P
u
n
d
e
r
C
h
o
s
e
n
C
i
p
h
e
r
t
e
x
t
-
F
r
a
g
m
e
n
t
A
t
t
a
c
k
s
)
b.
D
a
t
a
g
r
a
m
:
F
E
P
-
C
C
A
(
F
E
P
u
n
d
e
r
C
h
o
s
e
n
C
i
p
h
e
r
t
e
x
t
A
t
t
a
c
k
s
)
3.
M
e
s
s
a
g
e
s
i
z
e
s
:
T
r
a
f
f
i
c
S
h
a
p
i
n
g
18
18
D
a
t
a
s
t
r
e
a
m
S
e
t
t
i
n
g
▪
Unidirectional channel
▪
Model allows pre-shared
state
▪
Datastream semantics*
▪
Inputs and outputs treated
as byte streams
▪
Reliable, in-order delivery
▪
Models TCP
SEND
RECV
Plaintext
fragmentation
Ciphertext
fragmentation
*
Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, and Kenneth G. Paterson.
“Data is a stream: Security of stream-based channels”. CRYPTO 2015.
App
client
App
server
19
19
D
a
t
a
g
r
a
m
S
e
t
t
i
n
g
▪
Unidirectional channel
▪
Model allows pre-shared
state
▪
Datagram semantics*
▪
Inputs and outputs treated
as atomic messages
▪
Messages may be dropped
or reordered
▪
Models UDP
SEND
RECV
*
Similar to: Mihir Bellare, Tadayoshi Kohno, and Chanathip Namprempre.
“Authenticated
encryption in SSH: provably fixing the SSH binary packet protocol”. ACM CCS 2002.
App
client
App
server
20
20
P
r
o
t
o
c
o
l
M
o
d
e
l
SEND
RECV
I
n
p
u
t
m
: plaintext message
p
: packet length
f
: flush flag (datastream)
O
u
t
p
u
t
c
: ciphertext
I
n
p
u
t
c
: ciphertext
O
u
t
p
u
t
m
: plaintext message
C
: channel close flag
(datastream)
In implementation, SEND and RECV would interact with
sockets
.
21
21
O
0
SEND
(
m
,
p
,[
f
])
1.
Challenger chooses bit
b
.
2.
Adversary can query
stateful oracle
O
b
SEND
.
3.
Adversary outputs guess
b
’.
4.
Success if
b
’=
b
.
S
e
c
u
r
i
t
y
e
x
p
e
r
i
m
e
n
t
R
e
a
l
W
o
r
l
d
R
a
n
d
o
m
W
o
r
l
d
D
e
f
i
n
i
t
i
o
n
:
P
r
o
t
o
c
o
l
i
s
p
a
s
s
i
v
e
l
y
F
E
P
s
e
c
u
r
e
i
f
a
d
v
a
n
t
a
g
e
o
v
e
r
r
a
n
d
o
m
g
u
e
s
s
i
n
g
i
s
n
e
g
l
i
g
i
b
l
e
.
▪
Outputs
SEND(
m
,
p
,[
f
])
▪
Outputs
|
SEND(
m
,
p
,[
f
])|
random bytes
O
1
SEND
(
m
,
p
,[
f
])
P
a
s
s
i
v
e
F
E
P
S
e
c
u
r
i
t
y
(
d
a
t
a
g
r
a
m
a
n
d
d
a
t
a
s
t
r
e
a
m
)
22
22
A
c
t
i
v
e
s
e
c
u
r
i
t
y
(
d
a
t
a
s
t
r
e
a
m
)
:
F
E
P
-
C
C
F
A
(
C
h
o
s
e
n
C
i
p
h
e
r
t
e
x
t
-
F
r
a
g
m
e
n
t
A
t
t
a
c
k
s
)
O
0
SEND
(
m
,
p
,
f
)
1.
Challenger chooses bit
b
.
2.
Adversary can query
stateful oracles
O
b
SEND
and
O
b
RECV
.
3.
Adversary outputs guess
b
’.
4.
Success if
b
’=
b
.
S
e
c
u
r
i
t
y
e
x
p
e
r
i
m
e
n
t
R
e
a
l
W
o
r
l
d
R
a
n
d
o
m
W
o
r
l
d
D
e
f
i
n
i
t
i
o
n
:
P
r
o
t
o
c
o
l
i
s
F
E
P
-
C
C
F
A
i
f
a
d
v
a
n
t
a
g
e
o
v
e
r
r
a
n
d
o
m
g
u
e
s
s
i
n
g
i
s
n
e
g
l
i
g
i
b
l
e
.
▪
Always returns
channel close
flag
C
.
▪
Does not return
output message
m
unless out of
sync.
▪
Returns channel
close flag
CLOSE(||C
S
, C
R
).
▪
Does not return
output message
m
.
O
1
SEND
(
m
,
p
,
f
)
O
0
RECV
(
c
)
O
1
RECV
(
c
)
▪
Outputs
SEND(
m
,
p
,
f
)
▪
Outputs
|
SEND(
m
,
p
,
f
)|
random bytes
▪
CLOSE(||C
S
, C
R
): Secure close
function
▪
||C
S
: concatenated
O
b
SEND
outputs
▪
C
R
:
O
b
RECV
inputs
23
23
A
c
t
i
v
e
s
e
c
u
r
i
t
y
(
d
a
t
a
g
r
a
m
)
:
F
E
P
-
C
C
A
(
C
h
o
s
e
n
C
i
p
h
e
r
t
e
x
t
A
t
t
a
c
k
s
)
O
0
SEND
(
m
,
p
)
1.
Challenger chooses bit
b
.
2.
Adversary can query
stateful oracles
O
b
SEND
and
O
b
RECV
.
3.
Adversary outputs guess
b
’.
4.
Success if
b
’=
b
.
S
e
c
u
r
i
t
y
e
x
p
e
r
i
m
e
n
t
R
e
a
l
W
o
r
l
d
R
a
n
d
o
m
W
o
r
l
d
D
e
f
i
n
i
t
i
o
n
:
P
r
o
t
o
c
o
l
i
s
F
E
P
-
C
C
A
i
f
a
d
v
a
n
t
a
g
e
o
v
e
r
r
a
n
d
o
m
g
u
e
s
s
i
n
g
i
s
n
e
g
l
i
g
i
b
l
e
.
▪
Output
m
returned if:
1.
c
not Send
output,
2.
m
not error,
and
3.
m
not
null
▪
Does not return
output
m
.
O
1
SEND
(
m
,
p
)
O
0
RECV
(
c
)
O
1
RECV
(
c
)
▪
Outputs
SEND(
m
,
p
)
▪
Outputs
|
SEND(
m
,
p
)|
random bytes
▪
null
message output
allowed to be ignored
to enable short chaff
messages w/o MAC
24
24
S
e
c
u
r
e
C
l
o
s
e
F
u
n
c
t
i
o
n
s
▪
Secure close function CLOSE(||C
S
, C
R
)
▪
||C
S
: concatenated SEND
outputs
▪
C
R
: RECV
inputs
▪
Ensures closures give no more information than
network observations
▪
E.g. No closure based on plaintext value
▪
Rules out obfs4 behavior because length fields
cannot be identified in concatenated byte sequence
▪
Examples of secure close functions
▪
Never close (e.g. shadowsocks requests)
▪
Close after timeout
▪
Close at first “sync” byte position after modified byte
25
25
T
r
a
f
f
i
c
S
h
a
p
i
n
g
▪
Enables arbitrary-length messages
▪
Generalizes padding functionality of existing FEPs
▪
Avoids protocol-specific minimum-message sizes
D
e
f
i
n
i
t
i
o
n
(
d
a
t
a
s
t
r
e
a
m
)
:
P
r
o
t
o
c
o
l
s
a
t
i
s
f
i
e
s
T
r
a
f
f
i
c
S
h
a
p
i
n
g
i
f
,
f
o
r
a
l
l
m
e
s
s
a
g
e
s
m
a
n
d
p
≥
0
,
|
S
E
N
D
(
m
,
p
,
f
=
0
)
|
=
p
,
a
n
d
|SEND(
m
,
p
,
f
=1)|
≥
p
.
D
e
f
i
n
i
t
i
o
n
(
d
a
t
a
g
r
a
m
)
:
P
r
o
t
o
c
o
l
s
a
t
i
s
f
i
e
s
T
r
a
f
f
i
c
S
h
a
p
i
n
g
i
f
,
f
o
r
a
l
l
m
e
s
s
a
g
e
s
m
a
n
d
L
≥
p
≥
0
,
w
i
t
h
c
←
S
E
N
D
(
m
,
p
)
,
I
f
𝑐
𝑐
i
s
n
o
t
a
n
e
r
r
o
r
,
t
h
e
n
|
c
|
=
p
,
a
n
d
If
𝑚
is null
,
then
c
is not an error.
26
26
O
t
h
e
r
F
E
P
s
e
c
u
r
i
t
y
r
e
q
u
i
r
e
m
e
n
t
s
*
▪
Confidentiality
▪
IND-CCFA/IND-CCA (Datastream/Datagram)
▪
Not implied by FEP-CCFA/CCA because ciphertext
lengths can leak plaintexts
▪
With length regularity, implied by FEP-CCFA/CCA
▪
Integrity
▪
INT-CST/INT-CTXT (Datastream/Datagram)
▪
Implied by FEP-CCFA/CCA
27
27
E
x
p
e
r
i
m
e
n
t
a
l
A
n
a
l
y
s
i
s
o
f
D
a
t
a
s
t
r
e
a
m
F
E
P
s
▪
Generally close behavior is identifying, even when they tried to avoid that
▪
Minimum message size may not appear in practice, although protocols with keepalives
do
generate them
▪
Our experiments uncovered an integrity attack in VMess (now fixed)
28
28
E
x
p
e
r
i
m
e
n
t
a
l
A
n
a
l
y
s
i
s
o
f
D
a
t
a
g
r
a
m
F
E
P
s
▪
FEP security easier to achieve without closures
▪
We observe larger minimum message size due to
more required metadata in the datagram setting.
29
29
F
u
t
u
r
e
W
o
r
k
▪
FEP research ideas
▪
Forward secrecy
▪
Forward metadata secrecy
▪
High-performance FEPs
▪
Other TCP metadata leaks (e.g. congestion window)
▪
Versioning / protocol negotiation
▪
Paper available:
▪
Ellis Fenske and Aaron Johnson. “Bytes to Schlep? Use a FEP: Hiding Protocol Metadata with Fully Encrypted Protocols”. May 2024.
▪
<
https://arxiv.org/abs/2405.13310
>
- Short paper
- Work in progress
- Some details deviate from paper
In this research presented at the Cryptographic Applications Workshop, Ellis Fenske and Aaron Johnson address the challenges of Fully Encrypted Protocols (FEPs). They highlight the lack of precise understanding, formalized goals, and proven security in existing FEPs. The work introduces new security definitions, explores relations between security definitions, proposes secure constructions of FEPs, and analyzes existing FEPs. Future work includes proving construction security, deriving relations between security definitions, ensuring forward secrecy via key exchange, and extending definitions to the datagram setting.
Uploaded on Sep 14, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Bytes to Schlep? Use a FEP: Hiding Protocol Metadata with Fully Encrypted Protocols Ellis Fenske (U.S. Naval Academy) Aaron Johnson (U.S. Naval Research Laboratory) May 26th, 2024 Cryptographic Applications Workshop (CAW 2024)
Fully Encrypted Protocols (FEPs) What is a Fully Encrypted Protocol (FEP)? Appclient Appserver 1. All bytes look random 2. Message lengths variable FEPserver FEPclient Real-world examples: obfs4 / lyrebird (Tor) shadowsocks (Outline VPN) Obfuscated SSH (Psiphon) OpenVPN + XOR patch Vmess (V2Ray) 2
Summary of Our Work Problem: No precise understanding of FEPs Goals not formalized mathematically Security cannot be proven Existing FEPs continually present security flaws IND$-CPA: similar goal but for atomic messaging Solutions: 1. New security definitions for FEPs 2. Relations among new and existing security definitions 3. Secure constructions of FEPs 4. Analysis of existing FEPs 3
Status of this Work Presented early version of this work at FOCI 2023 Future Work from that talk: 1. Proving security of our construction 2. Deriving relations between the security definitions 3. Addressing forward secrecy via key exchange in the protocol 4. Extending our definitions to the datagram setting 4
Status of this Work Presented early version of this work at FOCI 2023 Future Work from that talk: 1. Proving security of our construction 2. Deriving relations between the security definitions 3. Addressing forward secrecy via key exchange in the protocol 4. Extending our definitions to the datagram setting 5
Status of this Work Presented early version of this work at FOCI 2023 Future Work from that talk: 1. Proving security of our construction 2. Deriving relations between the security definitions 3. Addressing forward secrecy via key exchange in the protocol 4. Extending our definitions to the datagram setting Added experimental analysis of existing FEP security 6
Status of this Work Presented early version of this work at FOCI 2023 Future Work from that talk: 1. Proving security of our construction 2. Deriving relations between the security definitions 3. Addressing forward secrecy via key exchange in the protocol 4. Extending our definitions to the datagram setting Added experimental analysis of existing FEP security Paper available: Ellis Fenske and Aaron Johnson. Bytes to Schlep? Use a FEP: Hiding Protocol Metadata with Fully Encrypted Protocols . May 2024. <https://arxiv.org/abs/2405.13310> 7
Why FEP? Existing encrypted protocols reveal metadata Protocol identity and version Amount of payload data Cryptographic primitives being used Example 1: TLS Record Example 2: WireGuard Datagram
Why FEP? FEP Reason #1: Censorship circumvention Typical VPN protocols can easily be identified and blocked e.g. OpenVPN, WireGuard, IPSec Censors have blocked VPN protocols (e.g. China, Russia) FEPs have been invented multiple times to eliminate simple protocol fingerprints (e.g. obfs4, shadow socks, Obfuscated SSH, Vmess) China has blocked FEPs: Wu et al. How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic . USENIX Security 2023. 9
Why FEP? FEP Reason #2: Maximally protects metadata Protocols increasingly protect metadata QUIC TLS 1.3 Encrypted Client Hello Cryptocurrencies (Ethereum s RPLx, Lightning s Bolt) Metadata can be sensitive Application(e.g. application-specific protocols) Domain of the destination (e.g. SNI TLS extension) Ciphertext primitives in use (some might be vulnerable) 10
Why FEP? FEP Reason #3: Prevents Internet ossification Middleboxes develop around observable protocol features Security firewalls Traffic shapers Alternate solution: David Benjamin. 2020. RFC 8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility 11
Why FEP? Privacy: A third party cannot tell whether two connections are using the same pseudorandom cTLS template Ossification risk TODO: More precise security properties and security proof. The goal we're after hasn't been widely considered in the literature so far, at least as far as we can tell. 12
Encrypted Protocols Non-FEP encrypted protocols innovation is still occurring: OSCORE: IoT-optimized (2019) NoiseSocket: generic framework (2017) WireGuard: VPN (2017) Bolt: Lightning network (2016) RLPx: Ethereum (2015) Why couldn t these all be FEPs?
FEPs in the Network Stack Generally assume over TCP or UDP Below transport layer limits developer agility Requires permissions for raw-socket access (e.g. iOS jailbreak) TCP and UDP are the common transport protocols New reliable transports over UDP e.g. QUIC, kcp Difficult to accomplish while protecting metadata FEP terms Datastream FEP (e.g. using TCP) Datagram FEP (e.g. using UDP) FEP here Application Layer Transport Layer Internet Layer Data-Link Layer Physical Layer 14
Looking at a FEP: obfs4 Tor s obfs4 (aka lyrebird) is a sophisticated FEP Uses TCP Key exchange for forward secrecy Padding for message-length variation Handshake 1. Client sends: Elligator-encoded key + random padding 2. Server sends: Elligator-encoded key + random padding Data-phase messages 16 bytes MAC Tag 2 bytes Frame length 1 byte Type 2 bytes (optional) Payload (optional) Padding Payload length Encrypted (Poly1305/XSalsa20) XOR with PRG
Looking at a FEP: obfs4 16 bytes MAC Tag 2 bytes Frame length 1 byte Type 2 bytes (optional) Payload (optional) Padding Payload length Encrypted (Poly1305/XSalsa20) XOR with PRG Security issues 1. Length field is malleable 2. obfs4 closes connection upon decryption error 3. #1 + #2 = active attack reveals obfs4 message structure 4. Specific minimum message length despite padding Let s define FEP security to rule out such issues.
New FEP Security Definitions 1. Passive security: a. Datastream: FEP-CPFA (FEP under Chosen Plaintext-Fragment Attacks) b. Datagram: FEP-CPA (FEP under Chosen Plaintext Attacks) 2. Active security: a. Datastream: FEP-CCFA (FEP under Chosen Ciphertext-Fragment Attacks) b. Datagram: FEP-CCA (FEP under Chosen Ciphertext Attacks) 3. Message sizes: Traffic Shaping 17
Datastream Setting Unidirectional channel Model allows pre-shared state Datastream semantics* Inputs and outputs treated as byte streams Reliable, in-order delivery Models TCP Appclient Appserver SEND RECV Plaintext fragmentation Ciphertext fragmentation *Marc Fischlin, Felix G nther, Giorgia Azzurra Marson, and Kenneth G. Paterson. Data is a stream: Security of stream-based channels . CRYPTO 2015. 18
Datagram Setting Unidirectional channel Model allows pre-shared state Datagram semantics* Inputs and outputs treated as atomic messages Messages may be dropped or reordered Models UDP Appclient Appserver SEND RECV *Similar to: Mihir Bellare, Tadayoshi Kohno, and Chanathip Namprempre. Authenticated encryption in SSH: provably fixing the SSH binary packet protocol . ACM CCS 2002. 19
Protocol Model SEND RECV Input m : plaintext message p : packet length f : flush flag (datastream) Output c : ciphertext Input c : ciphertext Output m : plaintext message C : channel close flag (datastream) In implementation, SEND and RECV would interact with sockets. 20
Passive FEP Security (datagram and datastream) Security experiment Random World Real World 1. Challenger chooses bit b. 2. Adversary can query stateful oracle O 3. Adversary outputs guess b . 4. Success if b =b. O0 O1 SEND(m,p,[f]) SEND(m,p,[f]) b SEND. Outputs |SEND(m,p,[f])| random bytes Outputs SEND(m,p,[f]) Definition:Protocol is passively FEP secure if advantage over random guessing is negligible. 21
Active security (datastream): FEP-CCFA (Chosen Ciphertext-Fragment Attacks) Security experiment CLOSE(||CS, CR): Secure close function ||CS: concatenated O CR: O Real World Random World O0 O1 SEND(m,p,f) SEND(m,p,f) b SEND outputs b RECV inputs Outputs |SEND(m,p,f)| random bytes Outputs SEND(m,p,f) 1. Challenger chooses bit b. 2. Adversary can query stateful oracles O O 3. Adversary outputs guess b . 4. Success if b =b. b SEND and O0 O1 RECV(c) RECV(c) b RECV. Always returns channel close flag C. Does not return output message m unless out of sync. Returns channel close flag CLOSE(||CS, CR). Does not return output message m. Definition:Protocol is FEP-CCFA if advantage over random guessing is negligible. 22
Active security (datagram): FEP-CCA (Chosen Ciphertext Attacks) Security experiment null message output allowed to be ignored to enable short chaff messages w/o MAC Real World Random World O0 O1 SEND(m,p) SEND(m,p) Outputs |SEND(m,p)| random bytes Outputs SEND(m,p) 1. Challenger chooses bit b. 2. Adversary can query stateful oracles O O 3. Adversary outputs guess b . 4. Success if b =b. b SEND and O0 O1 RECV(c) RECV(c) b RECV. Output m returned if: 1. c not Send output, 2. m not error, and 3. m not null Does not return output m. Definition:Protocol is FEP-CCA if advantage over random guessing is negligible. 23
Secure Close Functions Secure close function CLOSE(||CS, CR) ||CS: concatenated SENDoutputs CR: RECVinputs Ensures closures give no more information than network observations E.g. No closure based on plaintext value Rules out obfs4 behavior because length fields cannot be identified in concatenated byte sequence Examples of secure close functions Never close (e.g. shadowsocks requests) Close after timeout Close at first sync byte position after modified byte 24
Traffic Shaping Definition (datastream):Protocol satisfies Traffic Shapingif, for all messages m and p 0, |SEND(m,p,f=0)| = p, and |SEND(m,p,f=1)| p. Definition (datagram):Protocol satisfies Traffic Shaping if, for all messages m and L p 0, with c SEND(m,p), If ? is not an error, then|c| = p, and If ?is null, then c is not an error. Enables arbitrary-length messages Generalizes padding functionality of existing FEPs Avoids protocol-specific minimum-message sizes 25
Other FEP security requirements* Confidentiality IND-CCFA/IND-CCA (Datastream/Datagram) Not implied by FEP-CCFA/CCA because ciphertext lengths can leak plaintexts With length regularity, implied by FEP-CCFA/CCA Integrity INT-CST/INT-CTXT (Datastream/Datagram) Implied by FEP-CCFA/CCA 26
Experimental Analysis of Datastream FEPs Close Behavior Length Obfuscation Minimum Message Size Datastream Protocol FEP-CPFA FEP-CCFA Shadowsocks-libev (request/response) Never / Auth Fail / None 35 V2Ray-Shadowsocks (request/response) Drain / Auth Fail None 35 Drain Padding 18 V2Ray-VMess Auth Fail Padding 44 Obfs4/Lyrebird Auth Fail None 42 OpenVPN-XOR Obfuscated-OpenSSH (- PSK) ( Auth Fail None 16 ) Never None 52 kcptun Never Traffic Shaping 1 Our construction Generally close behavior is identifying, even when they tried to avoid that Minimum message size may not appear in practice, although protocols with keepalives do generate them Our experiments uncovered an integrity attack in VMess (now fixed) 27
Experimental Analysis of Datagram FEPs Minimum Message Size Datagram Protocol FEP-CPA FEP-CCA Length Obfuscation None 55 Shadowsocks-libev Padding 75 WireGuard-SWGP None 40 OpenVPN-XOR Traffic Shaping 0 Our construction FEP security easier to achieve without closures We observe larger minimum message size due to more required metadata in the datagram setting. 28
Future Work FEP research ideas Forward secrecy Forward metadata secrecy High-performance FEPs Other TCP metadata leaks (e.g. congestion window) Versioning / protocol negotiation Paper available: Ellis Fenske and Aaron Johnson. Bytes to Schlep? Use a FEP: Hiding Protocol Metadata with Fully Encrypted Protocols . May 20 <https://arxiv.org/abs/2405.13310> 29
