From aae7b14e7c0da66b831379a56d400b20a998be15 Mon Sep 17 00:00:00 2001 From: Russtopia Date: Sun, 15 Aug 2021 12:57:46 -0700 Subject: [PATCH] Update 'README.md' --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e5dd824..df9a700 100644 --- a/README.md +++ b/README.md @@ -51,9 +51,11 @@ Currently supported session algorithms: An interesting question. See [this write-up for a discussion](https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols). -xs implements the philosophy that it is the server admin's prerogitive to allow or deny connection using any particular combination of cryptographic primitives. The protocol makes no allowance for any sort of 'downgrades' or algo substitution during negotiation. The 'negotiation', if you can even call it that, is precisely: (client proposes a KEX, session cipher alg and hash) -- (server accepts or refuses and drops connection). If the server admin wishes, xsd (server) can accept any supported configuration, or a subset, or exactly one. +xs operates via the philosophy that it is the server admin's prerogitive to configure local policy wrt. allowed cryptographic primitives. The protocol makes no allowance for any sort of 'downgrades' or algo substitution during negotiation. The 'negotiation', if you can even call it that, is precisely: (client proposes a KEX, session cipher alg and hash) -- (server accepts or refuses and drops connection). If the server admin wishes, xsd (server) can accept any supported configuration, or a subset, or exactly one. -Furthermore, the code allows no accidental or implied 'sliding' between one configuration and another -- there is no 'fallback' mode or two-way negotiation of what primitives to use (which would open the possibility of downgrade attacks). HOWEVER, the current code does default to the server (xsd) allowing 'all' combinations unless command-line switches give a restriction list. Perhaps I will invert that, and require a list of allowed configurations instead. This is trivial to implement with the current architecture. +The connection negotiation allows no accidental or implied 'sliding' between one configuration and another -- there is no 'fallback' mode or two-way negotiation of what primitives to use (which would open the possibility of downgrade attacks). Unlike `ssh`, the server does not offer to clients a list of supported algos; the client can only offer a single configuration to the server, which it simply accepts or rejects without comment to the client. + +Currently, absent a specific whitelist of algs to allow, the server allows 'all' combinations as listed above to be proposed by clients (but again, only one may be proposed during a connect attempt). If the admin wishes to restrict the accepted algorithms, they may use the `-aK`, `-aC` and `-aH` options when launching the server to define a restricting whitelist. Perhaps in future releases the default will be to accept *no* algs and such a whitelist shall be required. ### Conn