Unable to disable SSL v2 and v3 in Postfix & Courier

[iainh]

I am trying to secure my VPS and one thing noted in a recent scan was SSL v2 and v3 being supported for SMTP, POP3 and IMAP. So a check of ‘Disabling SSLv3 Support on Servers’ and the Postfix configuration settings suggest:

smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
# Preferred syntax with Postfix = 2.5:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3​

This actually goes further than disabling SSLv2 and v3 and also excludes the use of NULL and MD5 ciphers. Great.

The Postfix conf file, main.cf exists in two places on my VPS:

# find / -name main.cf
/usr/libexec/postfix/main.cf
/etc/postfix/main.cf​

Examining both only the copy in /etc/postfix/ is configured and at the end of this file I can find all the Plesk settings, including some RBLs I’ve defined via the UI. Hence I know this is the working config as of the two, it’s the only one actually configured. Hence I add the required commands to the config:

...
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_use_tls = yes
smtp_tls_security_level = may

# Start added section
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
# Preferred syntax with Postfix = 2.5:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
# End added section

smtp_use_tls = no
smtpd_timeout = 3600s
smtpd_proxy_timeout = 3600s
...​

I then go to the Plesk Tools & Settings > Services Management and restart:

• SMTP Server (Postfix)

And for good measure:

• Plesk milter (Postfix)

I then test whether SSLv2 is enabled:

# openssl s_client -connect x.x.x.x:25 -starttls smtp -ssl2​

(with thanks to major.io)

Now what I should get back is an error as the attempt to connect with SSLv2 should fail as it's an excluded protocol, but instead what I get back is the Plesk cert and a connection:

# openssl s_client -connect x.x.x.x:25 -starttls smtp -ssl2

CONNECTED(00000003)

depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]

verify error:num=18:self signed certificate

...​

Why? What do I need to do to have Postfix use the updated config and refuse an SSL2 connection?

I seem to have the same issue with Courier having made similar changes to the /etc/courier-imap/pop3d-ssl file:

# Iain 2014-12-12
# TLS_CIPHER_LIST="SSLv3:TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"
TLS_CIPHER_LIST="TLSv1:HIGH:MEDIUM:!LOW:!EXP:!NULL:!aNULL@STRENGTH"​

And /etc/courier-imap/imapd-ssl file:

# Iain 2014-12-12
# TLS_PROTOCOL=SSL23
TLS_PROTOCOL=TLS1​

actually, this should probably read:
# Iain 2014-12-12
# TLS_PROTOCOL=SSL23
TLS_PROTOCOL=TLS1, TLS1.1, TLD1.2​

Why am I unable to disable SSL v2 and v3 for SMTP/POP3/IMAP with Postfix and Courier?

 

[UFHH01]

Hi iainh,

if you use the Parallels suggestion from the Parallels KB - article:

[Plesk] CVE-2014-3566: POODLE attack exploiting SSL 3.0 fallback ( KB - article: 123 160 )​

... and follow the suggestions STEP by STEP... you might experience, that the server securing works very well.


In some cases you might experience issues with incompatibilities for some browser and/or eMail - clients, after you followed the KB - article 123 160. It might help to read:

SSL POODLE / SSLv3 bug ( Parallels Forum - Link )​

... to solve such issues, because there are several additional solutions provided in this thread.

 

[iainh]

Thanks for this.

I have in fact been this way and the httpd/Apache are already sorted, but looking again, I do see:

• for Linux - Disables Apache, nginx, proftpd, courier-imap, qmail, postfix, dovecot, Plesk server engine (for versions 11.5 and later).

So Courier and Postfix are both there...so I'd best get cracking

 

[UFHH01]

Hi iainh,

just a hint, even that you didn't seem to like the idea of reading the mentioned Forum - Thread above, the clue is to use a more specific ciphers - list... ... the Forum - Thread provides as well links, where you might inform yourself and provides different ciphers-list solutions.

 

[iainh]

Sorry, but I *did* read the article when I was addressing Apache. The scan of the VPS later showed SSLv2 on the mail services and I didn't remember this article as also relating to Postfix and Apache and it didn't come up in searches, and yes I did look, hence my post.

As to the use of specific ciphers, I also took the opportunity to raise security of the ciphers in use and so raised the services SSLlabs rating of the httpd service to A-. Next step would be to get the PFS ciphers installed, but for that I'd need to move from Apache 2.2x to 2.4x and that's a more substantial change and so for the moment I've stopped with an A- and no PFS cipher support.

 

[iainh]

I've just re-read your note and you seem to think the cipher list is somehow linked to the transport layer protocol. Excepting that POODLE is linked to the use of block ciphers in CBC mode, the protocol used to negotiate the session and the cipher agreed for use in the ongoing symmetric encryption are two entirely different things and they have no relevance other than if you were to disable CBC-based cipher suites with SSLv3, then you would protect yourself against POODLE which is a vulnerability in the SSLv3 *protocol* (not any one cipher, but the protocol itself) when handling CBS ciphers due to the non-checking of padding bytes. None of this is anything to do with disabling SSLv2 and v3 and forcing the use of TLS 1.0 and above and so I am afraid, the clue is NOT to use a more specific ciphers list, because the ciphers used to encrypt the transport data are quite separate to the protocol used for the session. So to quote you, “you might like to inform yourself” about transport layer security.

 

[iainh]

Well for anyone interested, after researching more I have more info.

There’s an interesting thread on disabling SSLv3 and not simultaneously disabling TLSv1.0. It starts by someone experimenting and finding that if the explicitly disabled SSLv3 in the cipher list:

TLS_CIPHER_LIST="!SSLv3:TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"​

It had the side effect of also disabling TLSv1 and 1.1. At the very end of the thread is the explanation:

The "Cipher list" only controls which ciphers can be used, not which protocols. This is by definitions. However disabling all the ciphers that *could* potentially be used by SSLv3, has the side effect of disabling SSLv3 (and also blocking anything needing to use those same ciphers with later TLS versions). This is why Oliver saw TLSv1.0 being disabled for one of his tests because the server/client combination he used did not support any TLSv1.0-compatible ciphers that weren't also TLSv3 [typo: SSLv3] compatible.

Thus telling OpenSSL to enable/disable ciphers compatible with specific SSL/TLS versions is unlikely to produce the desired effect of just enabling/disabling specific SSL/TLS versions without confusing effects on the other protocol versions. The fact that the cipher list syntax lets you use protocol names as shorthands for "those ciphers related to that protocol version" is a confusing aspect of that interface and not of much practical use.​

I think this makes the point that the *protocol* and *cipher* are quite separate albeit there is an overlapping relationship between ciphers and TLS versions, but that setting ciphers isn’t really the way to control the protocol version to use.

Looking at my own issues:

Problem in /etc/courier-imap/pop3d-ssl

I had defined a TLS_CIPHER_LIST dropping the reference to SSLv3:

TLS_CIPHER_LIST="TLSv1:HIGH:MEDIUM:!LOW:!EXP:!NULL:!aNULL@STRENGTH"​

But failed to set the protocol version higher in the config, changing the default:

TLS_PROTOCOL=SSL23​

meaning all protocols (including TLS 1.x protocols. ) to now read:

TLS_PROTOCOL=TLS1​

This setting *seems* to cover TLS1, 1.1 and 1.2, although it’s hard to find definitive confirmation of this, even in the Courier documentation, which doesn’t even mention the SSL23 setting!

In /etc/courier-imap/imapd-ssl

The cipher list was (as default) commented out as:

# TLS_CIPHER_LIST="SSLv3:TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"​

And so I removed the reference to SSLv3, therefore meaning no ciphers were defined for SSLv3

TLS_CIPHER_LIST="TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"​

I then restarted. What I found is SSLv3 gave handshake errors and no cipher selection, but did connect, while an SSLv2 connection worked! Therefore, despite what I’ve mentioned about protocols and ciphers, I followed the Plesk instruction EXACTLY, e.g.: (-colon- equal : and used to stop smilies being inserted into the string and have -colon-D ( : D ) displayed as !)

TLS_PROTOCOL=TLSv1
TLS_CIPHER_LIST="ECDH+AESGCM-colon-DH+AESGCM:ECDH+AES256-colon-DH+AES256:ECDH+AES128-colon-DH+AES:ECDH+3DES-colon-DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS​

Guess what…exactly the same result…SSLv3 continued to give handshake errors and no cipher selection, but did connect, while SSLv2 continued to connect, as in:

# openssl s_client -connect x.x.x.x:110 -starttls pop3 -ssl3
CONNECTED(00000003)
140059895179080:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140059895179080:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
No peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 102 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1418568281
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

# openssl s_client -connect x.x.x.x:110 -starttls pop3 -ssl2
CONNECTED(00000003)​

So sadly, it seems even following the step-by-step instructions hasn’t worked, even using the specific cipher list…but I guess it reinforces the point that you don’t manage the TLS protocol by manipulating the cipher list.

 

[UFHH01]

Hi iainh,

did you as well update your openssl package? The recent vendor versions exclude SSL2 - support on Debian - based operating systems.

 

[iainh]

I did a comnplete CentOS update to 6.6 recently, but will check the OpenSSL version as well

 

[iainh]

The correct version of OpenSSL for CentOS 6.6 is openssl-1.0.1e-30.el6_6.2.<arch>.rpm or above (http://wiki.centos.org/Security/POODLE). I am at 6_6.4 as below and so yes, OpenSSL is fully up to date:

# rpm -q openssl
openssl-1.0.1e-30.el6_6.4.x86_64​

I remember too checking out 1.0.1e, as usually 'e' is considered a vulnerable build and 'j' or later should be used, but it seems in the case of CentOS 'e' is correct and certainly Apache passes the SSLlabs checks including POODLE vulnerability

 

[iainh]

Similar results with Postfix. I had found and applied:

smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
# Preferred syntax with Postfix = 2.5:
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3​

Based on the KB article I also added:

# Iain 2014-12-14 ref: http://kb.odin.com/123160
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3​

I now see:

# openssl s_client -connect x.x.x.x:25 -starttls smtp -ssl2
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 239 bytes and written 83 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1418574193
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
# openssl s_client -connect x.x.x.x:25 -starttls smtp -ssl3
CONNECTED(00000003)
139725913065288:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
139725913065288:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 246 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1418574202
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---​

So this is looking good, as no cert is being returned although the SSLv2 and v3 resposnes differ. But for instance a -tls1 response is quite different:

# openssl s_client -connect x.x.x.x:25 -starttls smtp -tls1
CONNECTED(00000003)
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
verify return:1
---
Certificate chain
0 s:/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
i:/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDszCCApsC...
...
...WT3fCcGOitmVm
-----END CERTIFICATE-----
subject=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
issuer=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 1708 bytes and written 324 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 99BF724EC92BF73A933B4E83165EC769EC075134BFF7F11DD12B210BDF3065D8
Session-ID-ctx:
Master-Key: 6861F8D879F91BA657DF6325AF58ED4729E3D2E6DBE889686E13E83A4066CED2938A8A535AFFACCC926B24480F37F66A
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1418575291
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---​

 

[iainh]

Looking at IMAP and POP3 from Courier again and using the following configuration:

TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"​

Note the lack of any ciphers defined for use with SSLv3, but using the shorter HIGH and !LOW settings rather than listing individual cipher suites, then I get:

Testing a TLS1 connection:

# openssl s_client -connect x.x.x.x:143 -starttls imap -tls1
CONNECTED(00000003)
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = [email protected]
verify return:1
---
Certificate chain
0 s:/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
i:/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDsz...
...
...cGOitmVm
-----END CERTIFICATE-----
subject=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
issuer=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=[email protected]
---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 2353 bytes and written 379 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 9ED8CA2554A26145FF7A620E9949CB0350FDF5726812C2A2E98804BE9452A6EE
Session-ID-ctx:
Master-Key: 7994EC2E3475AA598098A61419FA1E4042D83491144AD9034569CA8881FE2B102E247D266BD2AA3F6D755EFA3A194C76
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 54 a8 41 f0 da ...
...
... cf 63 03 65 54 80 3d ..D..tE...c.eT.=

Start Time: 1418575870
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
. OK CAPABILITY completed
Q
DONE​

So this is a successful TLSv1 connection.

Testing an SSLv2 connection:

# openssl s_client -connect x.x.x.x:143 -starttls imap -ssl3
CONNECTED(00000003)
140035894441800:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140035894441800:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 558 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1418575976
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---​

A FAILED SSLv3 connection...good!

And testing an SSLv2 connection:

# openssl s_client -connect x.x.x.x:143 -starttls imap -ssl2
CONNECTED(00000003)
Q
Q
^C​

This reports differently, but doesn't provide an interactive session...you can't even Q[uit].

So SSLv2 and v3 do appear to be disabled, although report differently. My next interest is whether than successful TLS connection report of 'TLS1' means TLS 1.0 and whether support for 1.1 and 1.2 needs to be defined differently, but I've failed to find any referecne to a setting other than 'TLS1'!

 

[UFHH01]

Hi iainh,

you might like this thread: http://courier-mail-server.10983.n7...-ssl-with-TLS1-TLS1-1-and-TLS1-2-td21877.html

 

[iainh]

Thanks for this. Yes, I've been through this earlier and it's the same thread as mentioned before (just a nicer presentation )

So yes, he (Oliver) tries defining TLS_PROTOCOL="TLS1_2:TLS1_1:TLS1" but then doesn't seem sure the TLS1_2 and 1_1 flags are correct; "Perhaps the constants TLS1_2 and TLS1_1 are not recognized?". Despite looking, I've not found these flags mentioned elsewhere and as mentioned, even the Courier documentation doesn't mention these, only "The possible versions are: SSL2, SSL3, TLS1.", which doens't include "SSL23" which is a known working flag!

There's then the suggestion that a 'quirk' of OpenSSL is that SSL must be defined in the TLS_PROTOCOL statement, but can then be 'rendered ineffective' by removing any ciphers from SSLv3, e.g. remove SSLv3 from:

TLS_CIPHER_LIST="SSLv3:TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"​

However, Oliver then reports that in this configuration doesn't work:

Behaviour when using the following variable (removed SSLv3):
TLS_CIPHER_LIST="TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"

SSLv3 working, TLS 1.0 working, TLS 1.1 working, TLS 1.2 working (no changes to before)​

He then tries explcitly disabling SSLv3 as below, but then gets "odd results":

Behaviour when using the following variable (added !):
TLS_CIPHER_LIST="!SSLv3:TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"

SSLv3 not working, TLS 1.0 not working, TLS 1.1 not working, TLS 1.2 working?!​

This is later explained as being due to the disabling of all ciphers linked to SSLv3 and in so doing removing ciphers that would otherwise work with TLS 1.0 or 1.1. This was my point about 'playing' with the cipher list having unexpected results as by removing a cipher that might be used by SSLv3 so as to 'neuter' SSLv3, you also remove that cipher from TLS 1.0/1.1 which isn't the intended outcome.

So the idea of a TLS1_1/1_2 switch is precisely what I've been looking for...or confirmation that "TLS1" actually means TLS1.x, but so far I've failed to find any confirmation of this.

 

[iainh]

I found this which suggest the TLS1_1/1_2 flags might be GnuTLS switches, not OpenSSL. From StackOverflow:

COURIERTLS=/usr/sbin/couriertls

##NAME: TLS_PROTOCOL:0
#
# TLS_PROTOCOL sets the protocol version. The possible versions are:
#
# OpenSSL:
#
# SSL2 - SSLv2
# SSL3 - SSLv3
# SSL23 - either SSLv2 or SSLv3 (also TLS1, it seems)
# TLS1 - TLS1
#
# Note that this setting, with OpenSSL, is modified by the TLS_CIPHER_LIST
# setting, below.
#
# GnuTLS:
#
# SSL3 - SSLv3
# TLS1 - TLS 1.0
# TLS1_1 - TLS 1.1
#
# When compiled against GnuTLS, multiple protocols can be selected as follows:
#
# TLS_PROTOCOL="TLS1_1:TLS1:SSL3"
#
# DEFAULT VALUES:
#
# SSL23 (OpenSSL), or "TLS_1:TLS1:SSL3" (GnuTLS)​

Note the TLS1_1 swtich seems to refer to GnuTLS only

 

[iainh]

Well testing Postfix with:

# openssl s_client -connect 127.0.0.1:25 -starttls smtp -tls1_1​

or -tls1_2, I can confirm TLS1.0, 1.1 and 1.2 connections with Postfix, and no SSLv3. Excellent.

Trying the same with Courier IMAP (port 143) however, only TLS1[.0] works and 1.1 and 1.2 fail, but POP3 (port 110) works with TLS1/1.1/1.2.

Comparing the TLS settings between imapd-ssl and pop3d-ssl:

IMAP                                  POP3
-------------------------------------+----------------------------------
IMAPDSSLSTART=YES                     POP3DSSLSTART=YES
IMAP_TLS_REQUIRED=0                   POP3_TLS_REQUIRED=0
COURIERTLS=/usr/bin/couriertls        COURIERTLS=/usr/bin/couriertls
TLS_PROTOCOL=TLS1                     TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1            - missing –

IMAP: TLS_CIPHER_LIST="TLSv1:HIGH:!LOW:!MEDIUM:!EXP:!NULL:!aNULL@STRENGTH"
POP3: TLS_CIPHER_LIST="TLSv1:HIGH:MEDIUM:!LOW:!EXP:!NULL:!aNULL@STRENGTH" (permits medium strength ciphers)

So essentially, the settings are similar excepting the POP3 config - the ones that DOES support TLS1.1 and 1.2 - lacks a STARTTLS_PROTOCOL command and also permits medium strength cipher suits.