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

Update blurb on 'cryptographic agility' and server alg whitelisting

This commit is contained in:
Russtopia 2021-08-15 13:12:29 -07:00
parent aae7b14e7c
commit 0e453f15d0
1 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.md
View File

@ -47,15 +47,17 @@ Currently supported session algorithms:
* HMAC-SHA256 * HMAC-SHA256
* HMAC-SHA512 * HMAC-SHA512
### Wait. You offer a lot of cryptographic primitives there. According to some, 'Cipher-agility' is considered bad in 2021. What gives? ***
**A Note on 'cryptographic agility'**
It has been suggested recently to me that offering multiple cryptographic primitives is considered bad in 2021.
An interesting question. See [this write-up for a discussion](https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols). An interesting question. See [this write-up for a discussion](https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols).
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. xs operates via the philosophy that **it is the server admin's prerogitive to configure local policy wrt. allowed cryptographic primitives**. The connection protocol makes no allowance for any sort of 'downgrades' or algo substitution during negotiation; 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 algorithms; the client can only offer a single configuration to the server, which it simply accepts or rejects without comment to the client.
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. In all releases to date, absent a specific whitelist of algs to allow, the server allows 'all' combinations of the above cryptographic primitives to be proposed by clients (but again, **only one** combination is proposed by the client in a single connect attempt). If the admin wishes to restrict the accepted algorithms now or at any future time, they may use the `-aK`, `-aC` and `-aH` options when launching the server to define a whitelist which excludes certain primitives. In future releases the default may be changed to accept *no* algs and such a whitelist shall be required. This will have no effect on the connection protocol itself.
***
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 ### Conn