test(dtls): EncryptionAck sans activer DTLS — le client continue le login EN CLAIR après l'ack (observé live)
Build Game Server / build (push) Successful in 21s
Build Game Server / build (push) Successful in 21s
This commit is contained in:
@@ -314,23 +314,17 @@ public abstract partial class UWorld : FNetworkNotify, IAsyncDisposable
|
||||
// Chiffrement DTLS-PSK requis par le client. Si on connaît la
|
||||
// PSK de cette identité (user_id), on répond NMT_EncryptionAck et
|
||||
// on établit le DTLS côté serveur (BouncyCastle). Cf. DTLSHandlerComponent.
|
||||
var psks = DtlsPsks.Value;
|
||||
if (psks.Get(encryptionToken) != null && connection.DtlsComponent != null)
|
||||
{
|
||||
Logger.Information("DTLS-PSK: identité {Token} connue -> EncryptionAck + handshake", encryptionToken);
|
||||
// OBSERVÉ EN LIVE : après NMT_EncryptionAck, le client envoie son
|
||||
// NMT_Login EN CLAIR (paquet UE de 18o, jamais de ClientHello DTLS
|
||||
// 16fefd). Hypothèse : l'EncryptionAck suffit à satisfaire son check
|
||||
// « chiffrement acquitté » et le canal de contrôle reste en clair.
|
||||
// => on ACQUITTE mais on N'ACTIVE PAS DTLS (sinon on mange le Login),
|
||||
// et on laisse le flux login se poursuivre normalement.
|
||||
Logger.Information("DTLS-PSK: identité {Token} — EncryptionAck (canal de contrôle laissé en clair, test)", encryptionToken);
|
||||
NMT_EncryptionAck.Send(connection);
|
||||
connection.FlushNet();
|
||||
connection.DtlsComponent.BeginHandshake(
|
||||
psks, encryptionToken,
|
||||
rec => connection.LowLevelSend(rec, rec.Length * 8, new FOutPacketTraits()));
|
||||
connection.SendChallengeControlMessage();
|
||||
}
|
||||
else
|
||||
{
|
||||
Logger.Warning("DTLS-PSK requis mais aucune PSK pour {Token} (renseigner PROSPECT_DTLS_PSKS) — le client fermera la connexion", encryptionToken);
|
||||
connection.SendChallengeControlMessage();
|
||||
}
|
||||
}
|
||||
}
|
||||
break;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user