{"id":1256,"date":"2013-06-25T16:40:19","date_gmt":"2013-06-25T15:40:19","guid":{"rendered":"http:\/\/www.michaelm.info\/blog\/?p=1256"},"modified":"2013-06-25T16:49:53","modified_gmt":"2013-06-25T15:49:53","slug":"configuration-of-hidden-sendmail-ssltls-connection-options","status":"publish","type":"post","link":"http:\/\/www.michaelm.info\/blog\/?p=1256","title":{"rendered":"Configuration of hidden Sendmail SSL\/TLS connection options"},"content":{"rendered":"

Sendmail has done it again – proved just how powerful it is, as long as you know what you’re doing.<\/p>\n

While investigating the configuration of the ciphers to used by Apache (SSLCipherSuite<\/code>) and the associated SSLHonorCipherOrder<\/code> option (to ensure the server’s cipher preference order is used), I realised that although I enable TLS on my Sendmail instances I don’t configure the cipher options. Given I’d spent some time coming up with my preferred cipher order for Apache (unfortunately RC4-SHA is fairly high on the list) I decided I may as well put it in place for other daemons which perform OpenSSL based encryption (Sendmail and IMAP for instance). Given the available Sendmail documentation is light on this subject I had to go digging.<\/p>\n

The “standard” encryption related options (enabled with the STARTTLS<\/code> define at compilation time) for Sendmail are pretty well documented<\/a> and understood:
\nServerCertFile
\nServerKeyFile
\nClientCertFile
\nClientKeyFile
\nCACertFile
\nCACertPath
\nDHParameters
\nTLSSrvOptions
\nRandFile
\nCRLFile<\/code><\/p>\n

There are some other useful options available when the STARTTLS<\/code> define is combined with the _FFR_TLS_1<\/code> define at compile time.
\nDHParameters512
\nCipherList
\nServerSSLOptions
\nClientSSLOptions<\/code><\/p>\n

 <\/p>\n

Note:\u00a0You can determine the compile settings used for your version of Sendmail by running:<\/p>\n

sendmail -d0.14 -bt < \/dev\/null<\/code><\/p>\n

 <\/p>\n

These four options do not appear to be documented properly anywhere – even the Sendmail source code is pretty light on their configuration syntax and use. The CipherList<\/code> option is mentioned as an available option on a page titled “Tips and Tricks for Sendmail Hackers<\/a>“, dated 2006-03-31. There are a few other web pages and blog posts which mention or show one how to use the CipherList<\/code> option. No mention is made of the remaining three.<\/p>\n

These four options are configured in the LOCAL_CONFIG<\/code> section of your sendmail.mc<\/code> file. The following is an example (which may or may not be suitable for you) of such a section:<\/p>\n

LOCAL_CONFIG
\nO CipherList=HIGH:RC4-SHA:RC4-MD5
\nO\u00a0ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_CIPHER_SERVER_PREFERENCE
\n<\/code><\/p>\n

 <\/p>\n

The options described:<\/p>\n

CipherList<\/code><\/strong> : This option configures the available cipher list for encrypted connections. Your cipher list can be tuned by using the openssl ciphers -v<\/code><\/a> command. Stronger ciphers are obviously better. Excluding weak ciphers may mean that very old clients will be unable to connect. Note that with SSLv3 and TLS1.x the client, by default, will select its preferred cipher from the server’s list.<\/p>\n

ServerSSLOptions<\/code><\/strong> : This option configures the OpenSSL connection flags<\/a>\u00a0used for the SSL\/TLS connections into Sendmail. By default Sendmail, and most other applications using the OpenSSL library, uses the SSL_OP_ALL<\/code> composite flag for its connections. This option allows these flags to be altered. The first option to consider using is\u00a0SSL_OP_CIPHER_SERVER_PREFERENCE<\/code>. This option causes the server, rather than the client, to choose the cipher based on its preference order. The next option to consider is SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS<\/code>. This option disables a countermeasure against a SSLv3\/TLSv1 protocol vulnerability. This flag disables the countermeasure and is set by default when SSL_OP_ALL<\/code> is used. Thus, if one wishes to have the vulnerability countermeasure enabled, this flag needs to be disabled. Depending on the clients and servers of your Sendmail instance you may wish to consider the use of SSL_OP_NO_SSLv2<\/code>, SSL_OP_NO_SSLv3<\/code> and SSL_OP_NO_TLSv1<\/code>. Note that the current version of Sendmail does not have support for OpenSSL’s SSL_OP_NO_TLS_v1_1<\/code> nor for SSL_OP_NO_TLSv1_2<\/code>. These two could be quite useful and I have submitted a patch to Sendmail for these to be included. The value of this parameter is used to manipulate the bits passed to OpenSSL. Note that Sendmail starts with a value of SSL_OP_ALL<\/code> and this option modifies that value – it does not reset it from scratch. You manipulate the value using [+]SSL_OP_XXX<\/code> to SET the bits and using -SSL_OP_XXX<\/code> to CLEAR the bits. Thus a value of +SSL_OP_ALL<\/code> would have no effect (since those bits are already set. A value of -SSL_OP_ALL<\/code> would result in no bits being set. A useful value might be +SSL_OP_NO_SSLv2 +SSL_OP_CIPHER_SERVER_PREFERENCE<\/code>.<\/p>\n

ClientSSLOptions<\/code><\/strong>\u00a0: This option\u00a0configures the\u00a0OpenSSL connection flags<\/a>\u00a0used for the SSL\/TLS connections initiated by Sendmail. The parameter’s value works the same as for\u00a0ServerSSLOptions<\/code>.<\/p>\n

DHParameters512<\/strong><\/code> : This option does not appear to actually be used. It is a valid configuration option which will be parsed. However, it appears as if this parameter is not used by the Sendmail source code at all!<\/p>\n

 <\/p>\n

As an aside, DHParameters<\/strong><\/code> is another odd configuration option. The documentation implies this is a file containing DH paramters. However, the source code in sendmail\/tls.c<\/code> has this to say:
\n
\n\/*
\n** valid values for dhparam are (only the first char is checked)
\n** none no parameters: don't use DH
\n** 512 generate 512 bit parameters (fixed)
\n** 1024 generate 1024 bit parameters
\n** \/file\/name read parameters from \/file\/name
\n** default is: 1024 for server, 512 for client (OK? XXX)
\n*\/
\n<\/code><\/p>\n

So in fact, it is slightly more flexible than the documentation makes out. Note too, that should you wish to use a DH parameter of more than 1024 bits you will need to use an external file.<\/p>\n

So with all that said, a useful set of parameters might be:
\nLOCAL_CONFIG
\nO CipherList=HIGH:RC4-SHA:RC4-MD5
\nO\u00a0ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_CIPHER_SERVER_PREFERENCE
\nO\u00a0ClientSSLOptions=+SSL_OP_NO_SSLv2
\n<\/code><\/p>\n

So, based on this configuration, we are only using “high” strength ciphers and also two RC4 ciphers. You may want to remove the RC4-MD5 one if you are concerned about MD5’s strength. For maximum compatibility with old clients, you may want to keep it included. We don’t allow SSLv2 and we request that the server (i.e. our Sendmail instance) chooses the mutual cipher.<\/p>\n

Hope this helps.<\/p>\n

Another useful thing to note, is that when _FFR_TLS_1<\/code> is used you can use two certificates and key files for ServerCertFile<\/code> and ServerKeyFile<\/code> – with their names separated with simply a ,<\/code> (i.e. a comma and no spaces). This is useful if you have both an RSA and DSA certificate you wish to use. For example, the configured option within sendmail.cf would be:<\/p>\n


\nO ServerCertFile=\/etc\/mail\/tls\/server-rsa.crt,\/etc\/mail\/tls\/server-dsa.crt
\nO ServerKeyFile=\/etc\/mail\/tls\/server-rsa.key,\/etc\/mail\/tls\/server-dsa.key
\n<\/code><\/p>\n

Due to constraints within OpenSSL’s SSL_CTX_use_PrivateKey_file<\/code> and SSL_CTX_use_certificate_file<\/code> calls, both certificates should use the same certificate chain. More information can be found on OpenSSL’s website<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Sendmail has done it again – proved just how powerful it is, as long as you know what you’re doing. While investigating the configuration of the ciphers to used by Apache (SSLCipherSuite) and the associated SSLHonorCipherOrder option (to ensure the server’s cipher preference order is used), I realised that although I enable TLS on my […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[134,135,140,139,144,143,145,142,141],"class_list":["post-1256","post","type-post","status-publish","format-standard","hentry","category-technical","tag-cipher","tag-encryption","tag-openssl","tag-sendmail","tag-sendmail-cf","tag-sendmail-mc","tag-ssl_op_cipher_server_preference","tag-sslv3","tag-tls"],"_links":{"self":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1256","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1256"}],"version-history":[{"count":14,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1256\/revisions"}],"predecessor-version":[{"id":1266,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1256\/revisions\/1266"}],"wp:attachment":[{"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1256"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.michaelm.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}