Skip to main content

Disabling STARTTLS for IMAP services.

Spork Schivago
Hi. I'm sorry if this has been asked, I couldn't find anything on the forums or internet here. I have my server audited once a week or so. One of the messages that I want fixed is:
The remote IMAP service supports the use of the 'STARTTLS' command to switch from a plaintext to an encrypted communications channel.
I have an SSL cert and I have plaintext authentication disabled. In WHM, I don't see a lot of configuration options for Dovecot under WHM >> Service Configuration >> Mailserver Configuration. I believe to do away with the message from the company that audit's my website, I just need to require SSL for Dovecot. I noticed this in the /etc/dovecot/dovecot.conf file.
# SSL/TLS support: yes, no, required. #ssl = yes
If I set this to:
ssl = required
in the template file, /var/cpanel/templates/dovecot2.2/main.local, and regenerate the dovecot.conf file, do you think that would solve the issue? If that fixes the issue, all I'd need to do is copy /var/cpanel/templates/dovecot2.2/main.default to main.local, edit it, uncomment the ssl = yes, change yes to required and then just execute
/scripts/builddovecotconf
Right? Would I also need to restart dovecot or would builddovecotconf take care of that for me? Thanks!

Comments

6 comments

Date Votes
  • Spork Schivago
    I telneted to port 143 on my server and saw this:
    * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
    So I guess that didn't work. AUTH=PLAIN is showing because I telneted from the server running Dovecot. Security is dropped because Dovecot assumes that because we're connecting on the machine that's running Dovecot, we don't have to worry so much. Here's what it shows when I connect from a remote machine:
    * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE STARTTLS LOGINDISABLED] Dovecot ready.
    I still see that dang STARTTLS. But because the AUTH=PLAIN is gone, do you guys think that means the IMAP service no longer supports the use of the 'STARTTLS' command to switch from a plaintext to an encrypted communications channel?
    0
  • cPanelMichael
    I still see that dang STARTTLS. But because the AUTH=PLAIN is gone, do you guys think that means the IMAP service no longer supports the use of the 'STARTTLS' command to switch from a plaintext to an encrypted communications channel?

    Hello, Per the Dovecot documentation: [LIST]
  • ssl=required: SSL/TLS is always required, even if non-plaintext authentication mechanisms are used. Any attempt to authenticate before SSL/TLS is enabled will cause an authentication failure.
    This suggests the authentication should fail on unencrypted connections before an attempt to use STARTSSL is possible. Thank you.
    • 0
  • Spork Schivago
    Hello, Per the Dovecot documentation: This suggests the authentication should fail on unencrypted connections before an attempt to use STARTSSL is possible. Thank you.

    That was my understanding from reading the documentation as well....but for some reason, even after setting SSL=required, I still fail the test... I'm starting to wonder if something's wrong with the scanning program though. I also see how I'm failing for HSTS. It says I have it setup, which is a good thing (it'll prevent people from sniffing unencrypted traffic), but then it says I fail because I'm not properly following the draft. It says I need to not send the HSTS header through unencrypted channels. I check my site though, and I only see where it's being sent through encrypted channels (https) and never through http. Makes me wonder if the scanning program is having some issues.
    0
  • cPanelMichael
    Hello, It's possible the scan is reporting a false positive. Dovecot provides a useful document if you'd like to manually test authentication: TestInstallation - Dovecot Wiki You could report those results to the developer/support for the scanning application to verify if it's a false positive. Thanks!
    0
  • Spork Schivago
    Hello, It's possible the scan is reporting a false positive. Dovecot provides a useful document if you'd like to manually test authentication: TestInstallation - Dovecot Wiki You could report those results to the developer/support for the scanning application to verify if it's a false positive. Thanks!

    Thanks cPanelMichael. When I telnet to my domain, port 143, and see this:
    * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE STARTTLS LOGINDISABLED] Dovecot ready.
    Because there is no, AUTH=PLAIN and no AUTH=LOGIN, that means the starttls command is in fact disabled for plain-text authentications, right? I will go through the various steps in the article you linked to. I wouldn't be surprised if it's some sort of false positive. There's this free PCI compliance scan one as well that provides a lot of false positives if I let it through my security systems. It's through that Comodo service. The free scan is done by HackerGuardian. I let it through the firewall and tell the various programs (modsecurity, etc) not to block it. I fail the PCI compliance test. But they're almost all false positives. For example, it'll show all kinds of problems with SSH, because of the low version number. But the scanning program doesn't seem to actually test for the vulnerabilities. It just seems to check for the version number of SSH and then assumes it's vulnerable. With CentOS, a lot of those vulnerability fixes from the higher versions of SSH have been back ported to the version I run, so I'm in fact patched. I was just using that as an example though, I don't need any help with the PCI compliance stuff. Thanks!
    0
  • cPanelMichael
    Because there is no, AUTH=PLAIN and no AUTH=LOGIN, that means the starttls command is in fact disabled for plain-text authentications, right?

    Yes, that is correct. Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post