amnezia-vpn/amneziawg-go

Fork 0

mirror of https://github.com/amnezia-vpn/amneziawg-go.git synced 2026-10-14 05:41:54 +00:00

[GH-ISSUE #87] Fully encrypted protocol for AmneziaWG #44

New issue

Open

opened 2026-10-13 21:03:01 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-10-13 21:03:01 +00:00

Owner

Originally created by @darkk on GitHub (Jul 26, 2025).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-go/issues/87

Как справедливо замечено в комментарии https://github.com/amnezia-vpn/amneziawg-go/issues/75#issuecomment-2989336182, AmneziaWG не является FEP: как минимум счётчик по-прежнему остаётся на месте. Да и первые 8 байт в каждом пакете данных одинаковы на протяжении пары минут.

Исправить это обратно совместимым с WireGuard™ образом невозможно. Но и {H1,H2,H3,H4} не равные {1,2,3,4} тоже не будут совместимы, а если уж ломать совместимость — то надёжно и качественно.

Я предлагаю добавить к AmneziaWG подобие опции tls-crypt из OpenVPN. Ключ предлагается общий для клики peer'ов, а не свой для каждого peer'а (т.е. не TLS Crypt v2), т.к.

tls-crypt-v2 предполагает разделение "клиентов" и "серверов" судя по спецификации, а peer'ы в WireGuard равноправные - Initiator и Responder могут меняться местами
в WireGuard при этом есть мгновенный роуминг без повторного "хэндшейка" в понимании OpenVPN, т.е. любой peer должен иметь возможность расшифровать любой пакет, пришедший от любого IP:Port в любой момент
WireGuard handshake обладает свойством Identity Hiding и неаккуратно сделаный per-peer ключ может это свойство сломать

В ближайшие дни пришлю pull request.

Originally created by @darkk on GitHub (Jul 26, 2025). Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-go/issues/87 Как справедливо замечено в комментарии https://github.com/amnezia-vpn/amneziawg-go/issues/75#issuecomment-2989336182, AmneziaWG не является FEP: как минимум счётчик по-прежнему остаётся на месте. Да и первые 8 байт в каждом пакете данных одинаковы на протяжении пары минут. Исправить это обратно совместимым с WireGuard™ образом невозможно. Но и {H1,H2,H3,H4} не равные {1,2,3,4} тоже не будут совместимы, а если уж ломать совместимость — то надёжно и качественно. Я предлагаю добавить к AmneziaWG подобие опции `tls-crypt` из OpenVPN. Ключ предлагается общий для клики peer'ов, а не свой для каждого peer'а (т.е. не TLS Crypt v2), т.к. 1. `tls-crypt-v2` предполагает разделение "клиентов" и "серверов" [судя по спецификации](https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt), а peer'ы в WireGuard равноправные - Initiator и Responder могут меняться местами 2. в WireGuard при этом есть мгновенный роуминг без повторного "хэндшейка" в понимании OpenVPN, т.е. любой peer должен иметь возможность расшифровать любой пакет, пришедший от любого IP:Port в любой момент 3. WireGuard handshake обладает свойством [Identity Hiding](https://www.wireguard.com/known-limitations/) и неаккуратно сделаный per-peer ключ может это свойство сломать В ближайшие дни пришлю pull request.

bsakaguchi commented

2026-10-13 21:03:02 +00:00

Author

Owner

@polcodav commented on GitHub (Aug 28, 2025):

Привет, а что там с PR ?

@polcodav commented on GitHub (Aug 28, 2025): Привет, а что там с PR ?

bsakaguchi commented

2026-10-13 21:03:02 +00:00

Author

Owner

@darkk commented on GitHub (Aug 28, 2025):

@polcodav как оно часто бывает, задача "сделать хорошо" оказалась чуть сложнее, чем я ожидал. Но, как говорится, "мы работаем над этим вопросом".

Если любопытны детали — был месяц назад небольшой драфт, простой как палка, который я дал почитать друзьям. Мы подумали, и оказалось, что есть некоторое количество вполне практически осуществимых атак, которые вполне можно закрыть. Поэтому драфт немного разросся до вот этого не до конца формального и формализованного черновика с Proof-of-Work и синхронизацией часов. Там вроде бы и сложно на первый взгляд, но вроде бы и всё по делу. После фразы HELL HELL HELL TIME IS HELL начинается поток сознания :-)

@darkk commented on GitHub (Aug 28, 2025): @polcodav как оно часто бывает, задача "сделать хорошо" оказалась чуть сложнее, чем я ожидал. Но, как говорится, "мы работаем над этим вопросом". Если любопытны детали — был месяц назад [небольшой драфт](https://gist.github.com/darkk/8f0ae7f6dbbfffdb2cafd46a2f341549), простой как палка, который я дал почитать друзьям. Мы подумали, и оказалось, что есть некоторое количество вполне практически осуществимых атак, которые вполне можно закрыть. Поэтому драфт немного разросся [до вот этого не до конца формального и формализованного черновика с Proof-of-Work и синхронизацией часов](https://gist.github.com/darkk/ddabbaf6baecf9db5d73ff13feeee343). Там вроде бы и сложно на первый взгляд, но вроде бы и всё по делу. После фразы `HELL HELL HELL TIME IS HELL` начинается поток сознания :-)

bsakaguchi commented

2026-10-13 21:03:02 +00:00

Author

Owner

@darkk commented on GitHub (Apr 11, 2026):

7.5 месяцев спустя

Я в треде WireGuard obfuscation & active probing: staying virtuous under pressure описал сложность, которую встретил на пути построения AWG-FEP, и не самый плохой метод её обхода.

Там, конечно, чтива минут на 20 — понимаю, многабуков, но всё же буду рад услышать комментарии, если вдруг кто.

@darkk commented on GitHub (Apr 11, 2026): _7.5 месяцев спустя_ Я в треде [WireGuard obfuscation & active probing: staying virtuous under pressure](https://lists.zx2c4.com/pipermail/wireguard/2026-April/009563.html) описал сложность, которую встретил на пути построения AWG-FEP, и не самый плохой метод её обхода. Там, конечно, чтива минут на 20 — понимаю, многабуков, но всё же буду рад услышать комментарии, если вдруг кто.

bsakaguchi commented

2026-10-13 21:03:02 +00:00

Author

Owner

@darkk commented on GitHub (Jun 6, 2026):

ещё пару месяцев спустя

Некоторый poor-man mitigation для проблем, связанных с очевидностью текущего протокола и active probing, может выглядеть следующим образом.

Никакого H3. Сookie message отправить в утиль и на передачу и на приём. Даже computational DoS "лучше", чем active probing, т.к. те злоумышленики, кто могут computational на WireGuard — те и volumetric'ом зальют.
Сделать что-то с обнулением latest-handshakes при рестарте WireGuard.Device. Например:
- сделать глобальный персистентный кэш peer.handshake.lastTimestamp рядом с хранилищем public keys
- при нулевом peer.handshake.lastTimestamp в ConsumeMessageInitiation проверить timestamp клиента против часов
- или проверять его вообще всегда, вдобавок к текущей проверке монотонности. Окно offset'а в 30s…120s выглядит неплохо. Обратите внимание, что WireGuard-Go и Linux Kernel клиенты шлют псевдо-TAI, а не UTC.
Рандомизировать padding. Как именно настраивать — вопрос, но padding фиксированного размера при включенном peer.persistentKeepaliveInterval — запчасть для наблюдателя.
Сцепить padding с пакетом. Сейчас padding не сцеплен, для цензора с active MitM capability — это потенциальная запчасть для probing. Не совсем padding oracle, но похоже.
Рандомизировать peer.persistentKeepaliveInterval, если он используется.
Зашифровать counter & co., заменить {H1, H2, H4} на шифр.

Алгоритм для header encryption

Общая схема Encrypt(Mac(PAD(x))). Это полное нарушение The Cryptographic Doom Principle, но нам чуть-чуть поможет UDP в качестве транспорта вместо TCP — любая ошибка должна отбрасывать пакет.

Nonce для шифрования заголовков выбирается исходя их общего размера пакета: выбираются нешифруемые поля с полновесной энтропией.

Заголовков "мало", меньше 64 байт, т.е. используется один блок ChaCha20, поэтому 128-битный nonce меняет экспоненту с 2³² до 2⁴⁸ в замечании "Note that this is too short to be safely generated at random if the same key is reused more than 2³² times". Именно при таких экспонентах у birthday paradox вероятность коллизии 2⁻³², на которую опираются рекомендации NIST (IIRC).

2⁴⁸ при packet rate в 1M pps — это 9 лет, таким образом использовать фиксированный ключ f(publicKey) для обфускации не идеально, но вполне практично.

HASH(), MAC() и прочее следуют https://www.wireguard.com/protocol/, а дополнительные константы такие:

LABEL_OBFS_ENC = "Amnezia-2.95 header ChaCha20 key" # 32 bytes
LABEL_OBFS_MAC = "Amnezia-2.95 padding Blake2s key" # 32 bytes
LABEL_CLKD_UID = "Amnezia-2.95 Clocked UID"         # 24 bytes
Device.MaxPdu = Device.tun.mtu + MessageTransportSize
PadLen = размер дополняемого padding в пределах [0; Device.MaxPdu - MsgLen]
PduLen = MsgLen + PadLen

Энкапсуляция Initiation и Response

Идея:

вставляем padding между mac1 и mac2
в mac1 складываем Clocked Peer ID для возможной защиты от computational DoS
в самый хвост пакета ("на место mac2", после padding) складываем значение mac1 для нового пакета
шифруем заголовки и plain-text, включая Clocked Peer ID

MsgLen = MessageInitiationSize | MessageResponseSize
Epoch = uint64(time.Now().Unix() / 120) # 120 = RekeyAfterTime
Mac1Key = HASH(LABEL_MAC1 || peer.device.staticIdentity.publicKey)

msg.MAC1 = HASH(
   LABEL_CLKD_UID
   || Epoch
   || peer.device.staticIdentity.publicKey
   || peer.handshake.remoteStatic
   || peer.handshake.presharedKey)
PadStart = offsetof(msg.MAC2)
PadEnd = PduLen - blake2s.Size128
msg[PadStart:PadEnd] = RAND(PadLen)
msg[PadEnd:] = MAC(Mac1Key, msg[0:PadEnd])

Nonce128Offset = 44 # оба сообщения >= 92 байт
CounterOffset = Nonce128Offset
Nonce96offset = Nonce128Offset + 4
Counter = binary.LittleEndian.Uint32(msg[CounterOffset:])
Nonce = msg[Nonce96offset:Nonce96offset+12]

HeaderKey = HASH(LABEL_OBFS_ENC || peer.device.staticIdentity.publicKey)
Cipher = chacha20.NewUnauthenticatedCipher(HeaderKey, Nonce)
Cipher.SetCounter(Counter)
Cipher.XORKeyStream(msg[0:Nonce128Offset])
Cipher.XORKeyStream(msg[offsetof(msg.MAC1):offsetof(msg.MAC2)])

Энкапсуляция Transport

Идея:

добавляем padding в конец
кладём длину рядом с message_type в то, что сейчас reserved_zero
вычисляем MAC padding вместе с pseudo-header
складываем MAC с AEAD tag
шифруем заголовки

MsgLen = полный размер пакета до энкапсуляции вместе с MessageTransport и poly1305.TagSize

PadStart = MsgLen
PadEnd = PduLen
msg[PadStart:PadEnd] = RAND(PadLen) # sizeof(PRNG state) >= 128bit, не pcg32!

PadMacKey = HASH(LABEL_OBFS_MAC || peer.device.staticIdentity.publicKey)
PolyTagOffset = MsgLen - poly1305.TagSize
PolyTag = msg[PolyTagOffset:MsgLen]
assert(msg[2:4] == {0, 0})
msg[2:4] = uint16(MsgLen) # in-place update
PadMac = MAC(PadMacKey, msg[0:MessageTransportHeaderSize] || msg[PadStart:PadEnd])
msg[PolyTagOffset:MsgLen] = PolyTag XOR PadMac

Nonce128Offset = PduLen >= 92 ? 44 : 16
CounterOffset = Nonce128Offset
Nonce96offset = Nonce128Offset + 4
Counter = binary.LittleEndian.Uint32(msg[CounterOffset:])
Nonce = msg[Nonce96offset:Nonce96offset+12]

HeaderKey = HASH(LABEL_OBFS_ENC || peer.device.staticIdentity.publicKey)
Cipher = chacha20.NewUnauthenticatedCipher(HeaderKey, Nonce)
Cipher.SetCounter(Counter)
Cipher.XORKeyStream(msg[0:MessageTransportHeaderSize])

Декапсуляция

Nonce128Offset = PduLen >= 92 ? 44 : 16
CounterOffset = Nonce128Offset
Nonce96offset = Nonce128Offset + 4
Counter = binary.LittleEndian.Uint32(msg[CounterOffset:])
Nonce = msg[Nonce96offset:Nonce96offset+12]

HeaderKey = HASH(LABEL_OBFS_ENC || device.staticIdentity.publicKey)
Cipher = chacha20.NewUnauthenticatedCipher(HeaderKey, Nonce)
Cipher.SetCounter(Counter)
Cipher.XORKeyStream(msg[0:MessageTransportHeaderSize])
[...]

А дальше — в обратном порядке, в зависимости от одного из трёх message_type.

На первом шаге Clocked Peer ID можно проверять после DH с поправкой ±1 эпоха — это не защитит от computational DoS, но позволит обкатать код.

На втором шаге проверку Clocked Peer ID нужно будет вынести перед DH, т.е. перед вычислительно дорогим вызовом device.staticIdentity.privateKey.sharedSecret(). Для каждого сконфигурированного Peer нужно будет добавить {u64 Epoch, int Seen, u16 HandshakeReplayFilter[24]} и поддерживать per-device lookup табличку Clocked Peer ID в Peer.

Clocked Peer ID предоставляет pre-DH идентификацию, HandshakeReplayFilter ограничивает общее число Initiation за Epoch и делает невозможным replay flood. Класть туда можно, например, 16 бит от SipHash, HalfSipHash или Blake2s(tempKey, input, 2). 16 бит вполне достаточно, вероятность дропа повторного Initiation пакета из-за коллизии получается 0.4%. 24 — это EpochLength / RekeyTimeout.

Are We Done Yet?

То, что я предлагаю, это ещё далеко от FEP:

нет ротации ключей и forward secrecy для заголовков
нет фрагментации "больших" пакетов в "произвольный" размер, а маленьких — в "супер-пакеты". Это важно, т.к. MTU != 1500 — тоже фактор ловли VPN'ов.
нет пакетов <32 байт

P.S.: Sponsored by: Scheiße und Pisse Stiftung

@darkk commented on GitHub (Jun 6, 2026): _ещё пару месяцев спустя_ <img width="1846" height="1318" alt="Image" src="https://github.com/user-attachments/assets/c2ee8510-84a6-40f7-a655-5ed75b406057" /> Некоторый poor-man mitigation для проблем, связанных с очевидностью текущего протокола и active probing, может выглядеть следующим образом. 1. Никакого H3. Сookie message отправить в утиль и на передачу и на приём. Даже computational DoS "лучше", чем active probing, т.к. те злоумышленики, кто могут computational на WireGuard — те и volumetric'ом зальют. 1. Сделать что-то с обнулением `latest-handshakes` при рестарте WireGuard.Device. Например: - сделать глобальный персистентный кэш peer.handshake.lastTimestamp рядом с хранилищем public keys - при нулевом peer.handshake.lastTimestamp в ConsumeMessageInitiation проверить timestamp клиента против часов - или проверять его вообще всегда, вдобавок к текущей проверке монотонности. Окно offset'а [в 30s…120s выглядит неплохо](https://gist.github.com/darkk/ddabbaf6baecf9db5d73ff13feeee343#file-awk-fep-fucking-draft-go-L173). Обратите внимание, что WireGuard-Go и Linux Kernel клиенты шлют псевдо-TAI, а не UTC. 1. Рандомизировать padding. Как именно настраивать — вопрос, но padding фиксированного размера при включенном `peer.persistentKeepaliveInterval` — запчасть для наблюдателя. 1. Сцепить padding с пакетом. Сейчас padding не сцеплен, для цензора с active MitM capability — это потенциальная запчасть для probing. Не совсем padding oracle, но похоже. 1. Рандомизировать `peer.persistentKeepaliveInterval`, если он используется. 1. Зашифровать counter & co., заменить {H1, H2, H4} на шифр. ## Алгоритм для header encryption Общая схема Encrypt(Mac(PAD(x))). Это полное нарушение [The Cryptographic Doom Principle](https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html), но нам чуть-чуть поможет UDP в качестве транспорта вместо TCP — любая ошибка должна отбрасывать пакет. Nonce для шифрования заголовков выбирается исходя их общего размера пакета: выбираются нешифруемые поля с полновесной энтропией. <img width="714" height="324" alt="Image" src="https://github.com/user-attachments/assets/a17f8a94-8a99-44f4-b817-29fb1865c748" /> <img width="1261" height="427" alt="Image" src="https://github.com/user-attachments/assets/d0142d10-0353-4a70-802d-2dcb4f40bbfa" /> Заголовков "мало", меньше 64 байт, т.е. используется один блок ChaCha20, поэтому 128-битный nonce меняет экспоненту с 2³² до 2⁴⁸ в замечании [_"Note that this is too short to be safely generated at random if the same key is reused more than 2³² times"_](https://pkg.go.dev/golang.org/x/crypto@v0.52.0/chacha20#pkg-constants). Именно при таких экспонентах у birthday paradox вероятность коллизии 2⁻³², на которую опираются рекомендации NIST (IIRC). 2⁴⁸ при packet rate в 1M pps — это 9 лет, таким образом использовать фиксированный ключ `f(publicKey)` для обфускации не идеально, но вполне практично. `HASH()`, `MAC()` и прочее следуют https://www.wireguard.com/protocol/, а дополнительные константы такие: ``` LABEL_OBFS_ENC = "Amnezia-2.95 header ChaCha20 key" # 32 bytes LABEL_OBFS_MAC = "Amnezia-2.95 padding Blake2s key" # 32 bytes LABEL_CLKD_UID = "Amnezia-2.95 Clocked UID" # 24 bytes Device.MaxPdu = Device.tun.mtu + MessageTransportSize PadLen = размер дополняемого padding в пределах [0; Device.MaxPdu - MsgLen] PduLen = MsgLen + PadLen ``` ## Энкапсуляция Initiation и Response Идея: - вставляем padding между mac1 и mac2 - в mac1 складываем Clocked Peer ID для возможной защиты от computational DoS - в самый хвост пакета ("на место mac2", после padding) складываем значение mac1 для нового пакета - шифруем заголовки и plain-text, включая Clocked Peer ID ``` MsgLen = MessageInitiationSize | MessageResponseSize Epoch = uint64(time.Now().Unix() / 120) # 120 = RekeyAfterTime Mac1Key = HASH(LABEL_MAC1 || peer.device.staticIdentity.publicKey) msg.MAC1 = HASH( LABEL_CLKD_UID || Epoch || peer.device.staticIdentity.publicKey || peer.handshake.remoteStatic || peer.handshake.presharedKey) PadStart = offsetof(msg.MAC2) PadEnd = PduLen - blake2s.Size128 msg[PadStart:PadEnd] = RAND(PadLen) msg[PadEnd:] = MAC(Mac1Key, msg[0:PadEnd]) Nonce128Offset = 44 # оба сообщения >= 92 байт CounterOffset = Nonce128Offset Nonce96offset = Nonce128Offset + 4 Counter = binary.LittleEndian.Uint32(msg[CounterOffset:]) Nonce = msg[Nonce96offset:Nonce96offset+12] HeaderKey = HASH(LABEL_OBFS_ENC || peer.device.staticIdentity.publicKey) Cipher = chacha20.NewUnauthenticatedCipher(HeaderKey, Nonce) Cipher.SetCounter(Counter) Cipher.XORKeyStream(msg[0:Nonce128Offset]) Cipher.XORKeyStream(msg[offsetof(msg.MAC1):offsetof(msg.MAC2)]) ``` ## Энкапсуляция Transport Идея: - добавляем padding в конец - кладём длину рядом с `message_type` в то, что сейчас `reserved_zero` - вычисляем MAC padding вместе с pseudo-header - складываем MAC с AEAD tag - шифруем заголовки ``` MsgLen = полный размер пакета до энкапсуляции вместе с MessageTransport и poly1305.TagSize PadStart = MsgLen PadEnd = PduLen msg[PadStart:PadEnd] = RAND(PadLen) # sizeof(PRNG state) >= 128bit, не pcg32! PadMacKey = HASH(LABEL_OBFS_MAC || peer.device.staticIdentity.publicKey) PolyTagOffset = MsgLen - poly1305.TagSize PolyTag = msg[PolyTagOffset:MsgLen] assert(msg[2:4] == {0, 0}) msg[2:4] = uint16(MsgLen) # in-place update PadMac = MAC(PadMacKey, msg[0:MessageTransportHeaderSize] || msg[PadStart:PadEnd]) msg[PolyTagOffset:MsgLen] = PolyTag XOR PadMac Nonce128Offset = PduLen >= 92 ? 44 : 16 CounterOffset = Nonce128Offset Nonce96offset = Nonce128Offset + 4 Counter = binary.LittleEndian.Uint32(msg[CounterOffset:]) Nonce = msg[Nonce96offset:Nonce96offset+12] HeaderKey = HASH(LABEL_OBFS_ENC || peer.device.staticIdentity.publicKey) Cipher = chacha20.NewUnauthenticatedCipher(HeaderKey, Nonce) Cipher.SetCounter(Counter) Cipher.XORKeyStream(msg[0:MessageTransportHeaderSize]) ``` ## Декапсуляция ``` Nonce128Offset = PduLen >= 92 ? 44 : 16 CounterOffset = Nonce128Offset Nonce96offset = Nonce128Offset + 4 Counter = binary.LittleEndian.Uint32(msg[CounterOffset:]) Nonce = msg[Nonce96offset:Nonce96offset+12] HeaderKey = HASH(LABEL_OBFS_ENC || device.staticIdentity.publicKey) Cipher = chacha20.NewUnauthenticatedCipher(HeaderKey, Nonce) Cipher.SetCounter(Counter) Cipher.XORKeyStream(msg[0:MessageTransportHeaderSize]) [...] ``` А дальше — в обратном порядке, в зависимости от одного из трёх message_type. На первом шаге Clocked Peer ID можно проверять после DH с поправкой ±1 эпоха — это не защитит от computational DoS, но позволит обкатать код. На втором шаге проверку Clocked Peer ID нужно будет вынести перед DH, т.е. перед вычислительно дорогим вызовом `device.staticIdentity.privateKey.sharedSecret()`. Для каждого сконфигурированного Peer нужно будет добавить `{u64 Epoch, int Seen, u16 HandshakeReplayFilter[24]}` и поддерживать per-device lookup табличку Clocked Peer ID в Peer. Clocked Peer ID предоставляет pre-DH идентификацию, HandshakeReplayFilter ограничивает общее число Initiation за Epoch и делает невозможным replay flood. Класть туда можно, например, 16 бит от SipHash, HalfSipHash или `Blake2s(tempKey, input, 2)`. 16 бит вполне достаточно, вероятность дропа повторного Initiation пакета из-за коллизии получается 0.4%. 24 — это `EpochLength / RekeyTimeout`. ## Are We Done Yet? То, что я предлагаю, это ещё далеко от FEP: - нет ротации ключей и forward secrecy для заголовков - нет фрагментации "больших" пакетов в "произвольный" размер, а маленьких — в "супер-пакеты". Это важно, т.к. MTU != 1500 — тоже фактор ловли VPN'ов. - нет пакетов <32 байт P.S.: `Sponsored by: Scheiße und Pisse Stiftung`

bsakaguchi commented

2026-10-13 21:03:02 +00:00

Author

Owner

@darkk commented on GitHub (Sep 15, 2026):

Предыстория:

в v3.1.20260812 исправили active probing через Cookies, но добавили тривиальный DoS при IsUnderLoad (как я и написал выше, "Dropping Cookies removes the distinguisher but breaks legitimate handshakes under load (clients cannot compute mac2)")
в v3.1.20260828 исправили тривиальный DoS, открыв вектор Computational DoS через curve25519.ScalarMult(), от которого Cookies и защищали (умножение занимает ≈100us и ≈10K PPS полностью сатурируют одно CPU ядро).

Среди особенностей awg v3.1.20260828 по сравнению с описаной выше схемой остаются:

MTU на 12 байт меньше, т.к. nonce для header encryption является отдельным "заголовком", а не берётся из payload
целостность padding не гарантируется, но может быть важна в свете задокументированого tampering на DPI
header encryption key scope больше необходимого — он не endpoint-specific, а общий на передачу и приём для всей группы peer'ов на одном device. Это свойство ограничивает возможность на одном device иметь peer'ов с разным header encryption key, и уменьшает "срок годности" ключа
случайный nonce — 96 бит, а не 128, т.е. десятилетний срок годности header encryption key достигается не при ≈1M пакетах в секунду, а уже при весьма скромных ≈1M пакетов в день (≈10 PPS, ≈128 kbit/s)

Computational DoS mitigation

Задача борьбы с Computational DoS — отбросить Handshake пакеты, которых "слишком много". Cookies используют rate-limit по SrcIP, после валидации владения IP адресом. Вместо Cookie я предлагаю незначительно ослабить identity-hiding, добавив идентификатор наподобии TOTP для поиска Peer до вычисления DH.

Для TOTP нам понадобится конфигурируемый ClkIDPeriod, т.к. RekeyAfterTime стал конфигурируемым с v3.0.0, и HandshakesPerPeriod порядка 18…24, где 18 — это MaxTimerHandshakes, 24 — RekeyAfterTime / RekeyTimeout. В "норме" из этих слотов должен использоваться всего один, два-три — при потерях пакетов.

ClkIDPeriod можно сделать per-peer, а не per-device, но польза от этого ограничена возможностью смешивать peer'ов с разными ClkIDPeriod в пределах одного device, значение порядка 120s "подходит всем", а сложность кода в maintenance горутине с разными ClkIDPeriod станет заметной.

При ClkIDPeriod равном нулю MAC1 считается по-старому, MAC2 игнорируется в зависимости от disableCookies.

При ClkIDPeriod больше RekeyAfterTime.Lo() стоит написать notice в лог, т.к. у этой конфигурации есть недостаток — значние ClkID будет использоваться повторно даже в happy-path. ClkID зашифрован квази-публичным header encryption key, поэтому лучше его не повторять за пределами повторных попыток handshake, чтоб ограничить деградацию identity-hiding.

При ClkIDPeriod больше HandshakesPerPeriod * RekeyTimeout.Lo() стоит также написать notice в лог, т.к. в worst-case может не хватить слотов в consumedHandshakes на все повторные попытки Handshake. "Все" попытки важны, т.к. peer может быть без сети, класть Handshake в очередь и отправить их "скопом", когда сеть появится.

Отправка

При ClkIDPeriod > 0 отправка работает следующим образом вместо cookieGenerator.AddMacs():

type ClkID [blake2s.Size128]byte
type HandshakeMac [blake2s.Size128]byte

LABEL_CLKD_UID = "Amnezia-2.95 Clocked UID"           # 24 байта: scope + выравнивание
LABEL_P2P_MAC  = "Amnezia-2.95 Peers Handshake MAC"   # 32 байта

P2PMacSendKey = HASH(                       # HASH(от 128 байт, ровно 2 блока Blake2s)
   LABEL_P2P_MAC
   || peer.device.staticIdentity.publicKey  # publicKey отправителя пакета
   || peer.handshake.remoteStatic           # publicKey получателя пакета
   || peer.handshake.presharedKey)          # секретный PSK пары отправитель-получатель

Epoch = uint64(time.Now().Unix() / ClkIDPeriod)
ClkID = HASH(                               # HASH(от 128 байт, ровно 2 блока Blake2s)
   LABEL_CLKD_UID
   || Epoch                                 # в LittleEndian
   || peer.device.staticIdentity.publicKey  # publicKey отправителя пакета
   || peer.handshake.remoteStatic           # publicKey получателя пакета
   || peer.handshake.presharedKey)          # секретный PSK пары отправитель-получатель
MAC1 = ClkID                                # в MAC1 помещается ClkID
MAC2 = MAC(msg[:smac2], P2PMacSendKey)      # в MAC2 — непосредственно MAC

Т.е. MAC2 вычисляется так же, как "раньше" вычислялся MAC1, только не по [0:smac1], а по [0:smac2] и с peer-specific ключом, а не device-specific.

Я не вижу разницы, иметь разные P2PMacRecvKey и P2PMacSendKey или же вычислять общий ключ для пары peer'ов, например, нижеуказаным методом. Ключ, необходимый для проверки входящего пакета, хранить в struct Peer хочется вслед за CookieChecker. А при отправке стоимость вычисления P2PMacSendKey на лету незначительна по сравнению с операциями с curve25519 и хранить его или нет — не так важно (CookieGenerator хранит).

PublicMin = MIN(peer.device.staticIdentity.publicKey, peer.handshake.remoteStatic)
PublicMax = MAX(peer.device.staticIdentity.publicKey, peer.handshake.remoteStatic)
P2PMacSharedKey = HASH(             # HASH(от 128 байт, ровно 2 блока Blake2s)
   LABEL_P2P_MAC
   || PublicMin
   || PublicMax
   || peer.handshake.presharedKey)  # секретный PSK пары отправитель-получатель

Плюс использования device-specific ключа в том, чтоб для некорректных пакетов даже hashtable lookup не делать и не тратить CPU cache-miss на это.

Недостаток — риск DoS'а, когда сетевой наблюдатель "возле" клиента, который вдобавок знает Header Encryption Key и Public Key "сервера". Такой наблюдатель сможет узнать ClkID для пользователя и DoS'ить его последующие handshake в пределах времени валидности ClkID. Если первый пакет дойдёт, то пользователь ничего не заметит, но если он потеряется, то retry будет заблокирован. Таким наблюдателем может быть ещё один пользователь "того же самого" AWG-сервера, который может по какой-то причине слушать трафик жертвы. В реалистичных сценариях такой наблюдатель трафик может и модифицировать и проблема лишь в том, что при миграции пользователя в другую сеть недоступность сохранится пока ClkID не протухнет.

Если этот недостаток неприемлем, то за цену CPU cache-miss можно использовать peer-specific ключ для MAC вместо device-specific ключа (например HASH(LABEL_P2PMAC || peer.device.staticIdentity.publicKey || peer.handshake.remoteStatic || peer.handshake.presharedKey)).

Maintenance

В Device при ClkIDPeriod > 0 нужно завести табличку map [ClkID]ClkIDTableEntry c type ClkIDTableEntry struct { peer *Peer; epoch uint64 }.

Сервисная горутина должна просыпаться раз в секунду, сверять epoch с часами, и, если наступила новая эпоха (по любым причинам, включая suspend/resume и перевод часов), выкидывать из ClkIDTable все записи с epoch < (Epoch - 1) || (Epoch + 1) < epoch и для каждого peer'а добавить записи для Epoch-1, Epoch и Epoch+1.

Пространство для оптимизации по CPU — не считать ClkID(Epoch, peer) несколько раз. Стоит побенчмаркать, т.к. Blake2s довольно быстрый и дополнительная сложность кода может съесть часть экономии CPU.

Для оптимизации по памяти можно уменьшить ClkIDTable в полтора раза, храня всего две эпохи: посыпаясь в момент посредине эпохи, а не на её границе, и заменяя данные Epoch-1 на Epoch+1.

В каждом Peer нужно добавить lastConsumedEpoch uint64; consumedHandshakes map[HandshakeMac]struct{}.

Сбрасывать lastConsumedEpoch при переводе часов "назад" бессмысленно, т.к. WireGuard не поддерживает перевод часов назад и защита по handshake.lastTimestamp сработает в ConsumeMessageInitiation(). С этой точки зрения вопрос перевода часов "назад" — отдельный "проект".

On-demand maintenance

На мобильных устройствах пересчитывать ClkIDTable каждую минуту-другую может оказаться слишком накладно с точки зрения application CPU wake-ups. Но можно реализовать ту же схему и по-другому, подробнее я написал в ClkID performance в вышеупомянутом письме.

Насколько эти попытки экономии осмысленны в условиях NAT44 и потенциальной необходимости поддерживать NAT-трансляцию keepalive'ом — надо измерять.

Приём

Получение пакета при ClkIDPeriod > 0:

По ClkID находим в ClkIDTable peer и clkidEpoch. Если не находим — пакет отбрасывается, он не из текущих эпох.

Если clkidEpoch < peer.lastConsumedEpoch — пакет отбрасывается, древний replay, MAC не имеет значения.

P2PMacRecvKey = HASH(                       # HASH(от 128 байт, ровно 2 блока Blake2s)
   LABEL_P2P_MAC
   || peer.handshake.remoteStatic           # publicKey отправителя пакета
   || peer.device.staticIdentity.publicKey  # publicKey получателя пакета
   || peer.handshake.presharedKey)          # секретный PSK пары отправитель-получатель

Вместо CookieChecker.CheckMAC1() проверяем MAC по [0:smac2] с ключом P2PMacRecvKey; сверяем с [smac2:size], не сходится — пакет отбрасывается.

Если clkidEpoch > peer.lastConsumedEpoch — обновляем peer.lastConsumedEpoch = clkidEpoch и очищаем clear(consumedHandshakes).

Если MAC пакета (из поля MAC2) есть в consumedHandshakes — пакет отбрасывается, это replay в пределах epoch.

Если len(consumedHandshakes) >= HandshakesPerPeriod — пакет отбрасывается, flood от данного peer'а.

Добавляем MAC в consumedHandshakes и обрабатываем пакет дальше, не забыв проверить, что peer по ClkID совпадает с peer по WireGuard.

Если consumedHandshakes потребляет слишком много памяти на Peer из-за накладных расходов на map[], его можно заменить маленьким массивом uint32_t, значения для которого вычислять как hsiphash_4u32(MAC, Device.runtimeSecret). Если и это много, то массив uint16_t выглядит допустимо, т.к. вероятность коллизии 16-битного хэша на ≈24 элементах всё ещё меньше вероятности потери одного пакета в интернете.

@darkk commented on GitHub (Sep 15, 2026): Предыстория: - в `v3.1.20260812` исправили active probing через Cookies, но добавили тривиальный DoS при IsUnderLoad (как я и написал выше, _"Dropping Cookies removes the distinguisher but breaks legitimate handshakes under load (clients cannot compute mac2)"_) - в `v3.1.20260828` исправили тривиальный DoS, открыв вектор Computational DoS через `curve25519.ScalarMult()`, от которого Cookies и защищали (умножение занимает ≈100us и ≈10K PPS полностью сатурируют одно CPU ядро). Среди особенностей awg v3.1.20260828 по сравнению с описаной выше схемой остаются: - MTU на 12 байт меньше, т.к. nonce для header encryption является отдельным "заголовком", а не берётся из payload - целостность padding не гарантируется, но может быть важна в свете [задокументированого tampering на DPI](https://www.usenix.org/system/files/usenixsecurity26-ablove.pdf) - header encryption key scope больше необходимого — он не endpoint-specific, а общий на передачу и приём для всей группы peer'ов на одном device. Это свойство ограничивает возможность на одном device иметь peer'ов с разным header encryption key, и уменьшает "срок годности" ключа - случайный nonce — 96 бит, а не 128, т.е. десятилетний срок годности header encryption key достигается не при ≈1M пакетах в секунду, а уже при весьма скромных ≈1M пакетов в день (≈10 PPS, ≈128 kbit/s) ### Computational DoS mitigation Задача борьбы с Computational DoS — отбросить Handshake пакеты, которых "слишком много". Cookies используют rate-limit по SrcIP, после валидации владения IP адресом. Вместо Cookie я предлагаю незначительно ослабить identity-hiding, добавив идентификатор наподобии TOTP для поиска Peer до вычисления DH. Для TOTP нам понадобится конфигурируемый ClkIDPeriod, т.к. RekeyAfterTime стал конфигурируемым с v3.0.0, и HandshakesPerPeriod порядка 18…24, где 18 — это MaxTimerHandshakes, 24 — RekeyAfterTime / RekeyTimeout. В "норме" из этих слотов должен использоваться всего один, два-три — при потерях пакетов. ClkIDPeriod можно сделать per-peer, а не per-device, но польза от этого ограничена возможностью смешивать peer'ов с разными ClkIDPeriod в пределах одного device, значение порядка 120s "подходит всем", а сложность кода в maintenance горутине с разными ClkIDPeriod станет заметной. При ClkIDPeriod равном нулю MAC1 считается по-старому, MAC2 игнорируется в зависимости от `disableCookies`. При ClkIDPeriod больше RekeyAfterTime.Lo() стоит написать notice в лог, т.к. у этой конфигурации есть недостаток — значние ClkID будет использоваться повторно даже в happy-path. ClkID зашифрован квази-публичным header encryption key, поэтому лучше его не повторять за пределами повторных попыток handshake, чтоб ограничить деградацию identity-hiding. При ClkIDPeriod больше HandshakesPerPeriod * RekeyTimeout.Lo() стоит также написать notice в лог, т.к. в worst-case может не хватить слотов в `consumedHandshakes` на все повторные попытки Handshake. "Все" попытки важны, т.к. peer может быть без сети, класть Handshake в очередь и отправить их "скопом", когда сеть появится. ### Отправка При ClkIDPeriod > 0 отправка работает следующим образом вместо `cookieGenerator.AddMacs()`: ``` type ClkID [blake2s.Size128]byte type HandshakeMac [blake2s.Size128]byte LABEL_CLKD_UID = "Amnezia-2.95 Clocked UID" # 24 байта: scope + выравнивание LABEL_P2P_MAC = "Amnezia-2.95 Peers Handshake MAC" # 32 байта P2PMacSendKey = HASH( # HASH(от 128 байт, ровно 2 блока Blake2s) LABEL_P2P_MAC || peer.device.staticIdentity.publicKey # publicKey отправителя пакета || peer.handshake.remoteStatic # publicKey получателя пакета || peer.handshake.presharedKey) # секретный PSK пары отправитель-получатель Epoch = uint64(time.Now().Unix() / ClkIDPeriod) ClkID = HASH( # HASH(от 128 байт, ровно 2 блока Blake2s) LABEL_CLKD_UID || Epoch # в LittleEndian || peer.device.staticIdentity.publicKey # publicKey отправителя пакета || peer.handshake.remoteStatic # publicKey получателя пакета || peer.handshake.presharedKey) # секретный PSK пары отправитель-получатель MAC1 = ClkID # в MAC1 помещается ClkID MAC2 = MAC(msg[:smac2], P2PMacSendKey) # в MAC2 — непосредственно MAC ``` Т.е. MAC2 вычисляется так же, как "раньше" вычислялся MAC1, только не по `[0:smac1]`, а по `[0:smac2]` и с peer-specific ключом, а не device-specific. Я не вижу разницы, иметь разные P2PMacRecvKey и P2PMacSendKey или же вычислять общий ключ для пары peer'ов, например, нижеуказаным методом. Ключ, необходимый для проверки входящего пакета, хранить в struct Peer хочется вслед за CookieChecker. А при отправке стоимость вычисления P2PMacSendKey на лету незначительна по сравнению с операциями с curve25519 и хранить его или нет — не так важно (CookieGenerator хранит). ``` PublicMin = MIN(peer.device.staticIdentity.publicKey, peer.handshake.remoteStatic) PublicMax = MAX(peer.device.staticIdentity.publicKey, peer.handshake.remoteStatic) P2PMacSharedKey = HASH( # HASH(от 128 байт, ровно 2 блока Blake2s) LABEL_P2P_MAC || PublicMin || PublicMax || peer.handshake.presharedKey) # секретный PSK пары отправитель-получатель ``` ~~Плюс использования device-specific ключа в том, чтоб для некорректных пакетов даже hashtable lookup не делать и не тратить CPU cache-miss на это.~~ ~~Недостаток — риск DoS'а, когда сетевой наблюдатель "возле" клиента, который вдобавок знает Header Encryption Key и Public Key "сервера". Такой наблюдатель сможет узнать ClkID для пользователя и DoS'ить его последующие handshake в пределах времени валидности ClkID. Если первый пакет дойдёт, то пользователь ничего не заметит, но если он потеряется, то retry будет заблокирован. Таким наблюдателем может быть ещё один пользователь "того же самого" AWG-сервера, который может по какой-то причине слушать трафик жертвы. В реалистичных сценариях такой наблюдатель трафик может и модифицировать и проблема лишь в том, что при миграции пользователя в другую сеть недоступность сохранится пока ClkID не протухнет.~~ ~~Если этот недостаток неприемлем, то за цену CPU cache-miss можно использовать peer-specific ключ для MAC вместо device-specific ключа (например `HASH(LABEL_P2PMAC || peer.device.staticIdentity.publicKey || peer.handshake.remoteStatic || peer.handshake.presharedKey)`).~~ ### Maintenance В Device при ClkIDPeriod > 0 нужно завести табличку `map [ClkID]ClkIDTableEntry` c `type ClkIDTableEntry struct { peer *Peer; epoch uint64 }`. Сервисная горутина должна просыпаться раз в секунду, сверять epoch с часами, и, если наступила новая эпоха (по любым причинам, включая suspend/resume и перевод часов), выкидывать из ClkIDTable все записи с `epoch < (Epoch - 1) || (Epoch + 1) < epoch` и для каждого peer'а добавить записи для Epoch-1, Epoch и Epoch+1. Пространство для оптимизации по CPU — не считать `ClkID(Epoch, peer)` несколько раз. Стоит побенчмаркать, т.к. Blake2s довольно быстрый и дополнительная сложность кода может съесть часть экономии CPU. Для оптимизации по памяти можно уменьшить ClkIDTable в полтора раза, храня всего две эпохи: посыпаясь в момент посредине эпохи, а не на её границе, и заменяя данные Epoch-1 на Epoch+1. В каждом Peer нужно добавить `lastConsumedEpoch uint64; consumedHandshakes map[HandshakeMac]struct{}`. Сбрасывать lastConsumedEpoch при переводе часов "назад" бессмысленно, т.к. WireGuard не поддерживает перевод часов назад и защита по `handshake.lastTimestamp` сработает в ConsumeMessageInitiation(). С этой точки зрения вопрос перевода часов "назад" — отдельный "проект". ### On-demand maintenance На мобильных устройствах пересчитывать ClkIDTable каждую минуту-другую _может_ оказаться слишком накладно с точки зрения application CPU wake-ups. Но можно реализовать ту же схему и по-другому, подробнее я написал в ClkID performance в [вышеупомянутом письме](https://lists.zx2c4.com/pipermail/wireguard/2026-April/009563.html). Насколько эти попытки экономии осмысленны в условиях NAT44 и потенциальной необходимости поддерживать NAT-трансляцию keepalive'ом — надо измерять. ### Приём Получение пакета при ClkIDPeriod > 0: По ClkID находим в ClkIDTable peer и clkidEpoch. Если не находим — пакет отбрасывается, он не из текущих эпох. Если `clkidEpoch < peer.lastConsumedEpoch` — пакет отбрасывается, древний replay, MAC не имеет значения. ``` P2PMacRecvKey = HASH( # HASH(от 128 байт, ровно 2 блока Blake2s) LABEL_P2P_MAC || peer.handshake.remoteStatic # publicKey отправителя пакета || peer.device.staticIdentity.publicKey # publicKey получателя пакета || peer.handshake.presharedKey) # секретный PSK пары отправитель-получатель ``` Вместо `CookieChecker.CheckMAC1()` проверяем MAC по `[0:smac2]` с ключом P2PMacRecvKey; сверяем с `[smac2:size]`, не сходится — пакет отбрасывается. Если `clkidEpoch > peer.lastConsumedEpoch` — обновляем `peer.lastConsumedEpoch = clkidEpoch` и очищаем `clear(consumedHandshakes)`. Если MAC пакета (из поля MAC2) есть в consumedHandshakes — пакет отбрасывается, это replay в пределах epoch. Если `len(consumedHandshakes) >= HandshakesPerPeriod` — пакет отбрасывается, flood от данного peer'а. Добавляем MAC в consumedHandshakes и обрабатываем пакет дальше, не забыв проверить, что peer по ClkID совпадает с peer по WireGuard. Если consumedHandshakes потребляет слишком много памяти на Peer из-за накладных расходов на map[], его можно заменить маленьким массивом uint32_t, значения для которого вычислять как hsiphash_4u32(MAC, Device.runtimeSecret). Если и это много, то массив uint16_t выглядит допустимо, т.к. вероятность коллизии 16-битного хэша на ≈24 элементах всё ещё меньше вероятности потери одного пакета в интернете.

bsakaguchi commented

2026-10-13 21:03:03 +00:00

Author

Owner

@darkk commented on GitHub (Sep 20, 2026):

В реалистичных сценариях такой наблюдатель трафик может и модифицировать

Я немного ошибался, вполне существует сценарий, где наблюдатель может трафик слышать, но модификация затруднена: открытая Wi-Fi сеть с AP Client isolation. Впрочем, в таком случае злоумышленнику зачастую доступна Rogue AP, так что такая атака — это скорее party trick.

Способ выиграть race condition в такой ситуации иногда возможен следующий: трафик до удалённого VPN-сервера может проходить через ECMP линк с разной latency. Это не гипотетическая возможность — например, я вживую наблюдал стабильно разные маршруты и разницу latency в 10-15ms между СПб (Ростелекомом) и Франкфуртом (Linode, AKAMAI) для разных five-tuple.

Возможность у злоумышленника вслепую принудительно загрузить всю hash-таблицу в CPU cache серией пакетов есть и через MessageTransport: будет выполняться поиск по несуществующему Receiver. По этой причине использование ключа более широкого scope для экономии CPU cache-miss для невалидных MessageInitiation и MessageResponse не имеет смысла. Два MAC вместо одного тоже не выглядят осмысленно, т.к. CPU cache-miss это ~100ns, а дополнительный Blake2s-128 от MessageInitiation ~350ns.

Я обновил https://github.com/amnezia-vpn/amneziawg-go/issues/87#issuecomment-5683883588 с учётом вышесказанного.

@darkk commented on GitHub (Sep 20, 2026): > В реалистичных сценариях такой наблюдатель трафик может и модифицировать Я немного ошибался, вполне существует сценарий, где наблюдатель может трафик слышать, но модификация затруднена: открытая Wi-Fi сеть с AP Client isolation. Впрочем, в таком случае злоумышленнику зачастую доступна Rogue AP, так что такая атака — это скорее party trick. Способ выиграть race condition в такой ситуации иногда возможен следующий: трафик до удалённого VPN-сервера может проходить через ECMP линк с разной latency. Это не гипотетическая возможность — например, я вживую наблюдал стабильно разные маршруты и разницу latency в 10-15ms между СПб (Ростелекомом) и Франкфуртом (Linode, AKAMAI) для разных five-tuple. Возможность у злоумышленника вслепую принудительно загрузить всю hash-таблицу в CPU cache серией пакетов есть и через MessageTransport: будет выполняться поиск по несуществующему Receiver. По этой причине использование ключа более широкого scope для экономии CPU cache-miss для невалидных MessageInitiation и MessageResponse не имеет смысла. Два MAC вместо одного тоже не выглядят осмысленно, т.к. CPU cache-miss это ~100ns, а дополнительный Blake2s-128 от MessageInitiation ~350ns. Я обновил https://github.com/amnezia-vpn/amneziawg-go/issues/87#issuecomment-5683883588 с учётом вышесказанного.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

amnezia-vpn/amneziawg-go#44

No description provided.

Rows
Columns