RusstopiaLabs
/
xs
mirror of https://gogs.blitter.com/RLabs/xs
1
0
Fork 0
Code Issues Releases Wiki Activity

Update 'README.md'

This commit is contained in:
Russtopia 2021-08-15 12:57:46 -07:00
parent 6904268797
commit aae7b14e7c
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -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