Document reasons and alternatives to SSL connections
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
percona-pam-for-mysql |
Triaged
|
Medium
|
Borys Belinsky |
Bug Description
After documenting bug 931934, let's have a FAQ item (it's already been asked/suggested on blogs...) on the reasons we recommend existing SSL setup and not e.g. implement SASL.
SASL would be cheaper than SSL, but using SASL requires that both client and server have a shared secret. In case of regular password auth, such shared secret is the password. But with PAM there is no such secret: the server does not know the password, does not even know if there is a password at all. If there are any ways to use SASL that do not require a shared secret, we would like to know that, but they probably are as expensive as setting up a SSL connection.
Since there is no shared secret the next thing we can do to send the password securely is to encrypt it using the server's public key. But at this point we might as well use SSL.
If there is no need to encrypt the whole client-server session, but only to send the password securely, we could implement setting up our own short-lived SSL session in the plugin to do that. But currently we see no need, as an already-established SSL connection is cheap so we don't win much by making it shorter. If anybody disagrees, they are welcome to contact us and tell it/ask to implement it. Another option then is to avoid PAM altogether and implement a plugin that authenticates directly against the desired auth backend.
Changed in percona-pam-for-mysql: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in percona-pam-for-mysql: | |
assignee: | Hrvoje Matijakovic (hrvojem) → Borys Belinsky (borys-belinsky-percona) |