This ticket supersedes the sagas in T864 and T902.
Frontend Connections (listeners)
Regardless of the configuration of a backend connection, when a client connects to a listener that is not configured to apply implicit SSL, the following capabilities need to be provided (no more, and no less):
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS LOGINDISABLED] imapf06.mykolab.com Cyrus IMAP Murder 2.5.6.3-Kolab-2.5.6-3.1.el6.kolab_14 server ready
This will allow a client to upgrade the connection with TLS, by using the STARTTLS command, without bypassing the upgrade of the connection.
However, a current initial (i.e. pre-STARTTLS) Guam capability response looks as follows:
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE ANNOTATE-EXPERIMENT-1 LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE URLAUTH URLAUTH=BINARY X-NETSCAPE MUPDATE=mupdate://mupdate.mykolab.com/ AUTH=PLAIN AUTH=LOGIN SASL-IR COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE STARTTLS] imapf06.mykolab.com Cyrus IMAP Murder 2.5.6.3- Kolab-2.5.6-3.1.el6.kolab_14 server ready
This includes some 41 capabilities that are superfluous, but more importantly;
- Includes AUTH=PLAIN,
- Includes AUTH=LOGIN,
- Includes SASL-IR,
- Includes COMPRESS=DEFLATE,
- Does NOT include LOGINDISABLED
Moreover, when the client connects to a listener that is configured to apply implicit SSL, the following capabilities are offered in current Guam / #EImap:
verify error:num=18:self signed certificate TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits) S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxten QUOTA NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY SORT=UID THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE ANNOTATE-EXPERIMENT-1 LIST-EXTENDED LIST-STATUS LIST-MYRIGHTS WITHIN QRESYNC SCAN XLIST XMOVE MOVE URLAUTH URLAUTH=BINARY X-NETSCAPE MUPDATE=mupdate://mupdate.mykolab.com/ AUTH=PLAIN AUTH=LOGIN SASL-IR COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE STARTTLS] imapf06.mykolab.com Cyrus IMAP Murder 2.5.6.3- Kolab-2.5.6-3.1.el6.kolab_14 server ready
Please note the presence of STARTTLS on a listener that is configured to apply implicit SSL.
Backend connections (imap_servers)
The Guam architecture is mistakenly using backend configuration to impose logic on frontend connections (listeners) that deserve treatment in their own right.
Summary
| # | Listener | Port | STARTTLS? | Implicit SSL? | Backend | Port | TLS | Relevant? |
| 1 | imap | 143 | no. | false | imap | 143 | false | no. |
| 2 | imap | 143 | yes. | false | imap | 143 | false | yes. |
| 3 | imap | 143 | yes. | false | imap | 143 | starttls | yes. |
| 4 | imap | 143 | yes. | false | imaps | 993 | true | yes. |
| 5 | imaps | 993 | no. | true | imap | 143 | false | yes. |
| 6 | imaps | 993 | no. | true | imap | 143 | starttls | yes. |
| 7 | imaps | 993 | no. | true | imaps | 993 | true | yes. |
"no." and "yes." are functional requirements, "true", "false" and "starttls" are configuration values or runtime parameters.
- Scenario is invalid and not valuable, on the principle of not offering clients unencrypted connections, period.
- Scenario 2 is valid, providing a TLS termination point. Connection to backend is plaintext and w/o TLS.
- Scenario expects clients to use STARTTLS. Scenario should offer clients a correct STARTTLS connection upgrade procedure despite configuration or runtime state for backend connections. See also Scenario #4.
- See Scenario #3.
- Scenario 5 is as valid as Scenario 2, for precisely the same reasons. The client does expect NO STARTTLS among the capabilities presented to it.
- Scenario 6 is as valid as Scenario 3, 4 and 7. The client does expect NO STARTTLS among the capabilities presented to it, despite the backend configuration perhaps maybe incidentally having been configured to be connected to using a STARTTLS-based explicit connection security upgrade procedure.
- Scenario 7 is as valid as Scenario 3, 4 and 6. The client does expect NO STARTTLS among the capabilities presented to it.
Example Configuration
In the following example configuration, the backend is configured to use implicit SSL (the most secure), and two listeners provide clients with a port 143 IMAP server reverse proxy (expected to function only with STARTTLS, as per the outlined scenarios) and a port 993 IMAP server reverse proxy (expected to function only with implicit SSL, as per the outlined scenarios).
[
{
kolab_guam, [
{
imap_servers, [
{
default, [
{ host, "192.168.56.101" },
{ port, 993 },
{ tls, true }
]
}
]
},
{
listeners, [
{
imap, [
{ port, 143 },
{ imap_server, default },
{
rules, [
{ filter_groupware, [] }
]
},
{
tls_config, [
{ certfile, "/etc/ssl/sample.pem" }
]
}
]
},
{
imaps, [
{ port, 993 },
{ implicit_tls, true },
{ imap_server, default },
{
rules, [
{ filter_groupware, [] }
]
},
{
tls_config, [
{ certfile, "/etc/ssl/sample.pem" }
]
}
]
}
]
}
]
},
{
lager, [
{
handlers, [
{ lager_console_backend, debug },
{ lager_file_backend, [ { file, "log/error.log"}, { level, error } ] },
{ lager_file_backend, [ { file, "log/console.log"}, { level, info } ] }
]
}
]
},
%% SASL config
{
sasl, [
{ sasl_error_logger, { file, "log/sasl-error.log" } },
{ errlog_type, error },
{ error_logger_mf_dir, "log/sasl" }, % Log directory
{ error_logger_mf_maxbytes, 10485760 }, % 10 MB max file size
{ error_logger_mf_maxfiles, 5 } % 5 files max
]
}
].