Hello. I manage the email for several SMBs (between 100 and 900 mailboxes each), where they are still running on-premises Exchange 2007 on Windows Server 2003 x64. Yes, I know this is old software, but upgrading their setup is expensive because it involves getting new licenses (for the server OS, for the Exchange Server, and for the client CALs), procuring new and more powerful hardware (currently running on old Proliant G5 servers), and consulting fees for the migration work. These SMBs are not particularly affluent, and the economy in my part of the world is in bad shape -- I've recommended them to go to Office 365 as the best course of action, but their reply is that way forward is "too expensive" for them (the "subscription model" is not popular with them, especially when they are cutting costs right and left to try to stay afloat). So this is the "email status quo" I have to deal with, and to tell the truth those Exchange 2007 setups have been working great for them so far.
Until last week, when problems began: email from certain senders is not reaching them. After investigating the problem, it has to do with said senders running new and upgraded Linux MTAs with new and upgraded OpenSSL versions, which trigger a bug in Windows Server 2003 when using STARTTLS in the SMTP transaction. This bug in SChannel (the SSL/TLS subsystem in Windows) in Windows Server 2003 is well known: that vintage operating system can only use an encryption algorithm of the 64 first ones advertised as supported by the remote host. Those new and upgraded Linux MTAs are advertising the encryption algorithms which Windows Server 2003 supports way further down in the list than the 64 first slots, and the result is that (1) the SMTP-with-TLS connection fails abruptly, and (2) the SMTP-with-TLS connection is retried by the remote Linux MTA for several days with the same result until the message expires in the remote side and is discarded, never reaching the recipient on the Exchange 2007 systems. This bug in Schannel in Windows Server 2003 has been discussed previously here: http://postfix.1071664.n5.nabble.com/Cannot-start-TLS-handshake-failure-when-relaying-through-Exchange-2007-td86243.html http://postfix.1071664.n5.nabble.com/RC4-in-live-email-servers-td78249.html Using Wireshark, I was able to get the long list of offered encryption algorithms (a.k.a. "cipher suites") which a sender running such a new and upgraded Linux MTA was advertising -- this is the list, which is just too long for Windows Server 2003: Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 284 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 280 Version: TLS 1.2 (0x0303) Random gmt_unix_time: Dec 1, 2076 13:23:21.000000000 Romance Standard Time random_bytes: 055c7b8c18b45e57c51455a7df083568708105b42033778d... Session ID Length: 0 Cipher Suites Length: 172 Cipher Suites (86 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (0x00a5) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3) Cipher Suite: TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (0x00a1) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a) Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA256 (0x0069) Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA256 (0x0068) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037) Cipher Suite: TLS_DH_DSS_WITH_AES_256_CBC_SHA (0x0036) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0086) Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0085) Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026) Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (0x00a4) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) Cipher Suite: TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (0x00a0) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA256 (0x003f) Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA256 (0x003e) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x0031) Cipher Suite: TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x0030) Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a) Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099) Cipher Suite: TLS_DH_RSA_WITH_SEED_CBC_SHA (0x0098) Cipher Suite: TLS_DH_DSS_WITH_SEED_CBC_SHA (0x0097) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0043) Cipher Suite: TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0042) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_IDEA_CBC_SHA (0x0007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c) Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA (0x0010) Cipher Suite: TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA (0x000d) Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d) Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Also, I've been able to replicate the problem, setting up a server with Ubuntu 16.10, which defaults to Postfix 3.1.0 as MTA and OpenSSL 1.0.2g as crypto subsystem. After I enabled TLS for the smtp client of Postfix, I could no longer successfully send email to Exchange 2007 running on Windows Server 2003 x64. Instead, the outgoing messages got queued in Postfix with the error message: "Cannot start TLS: handshake failure"; and eventually some days later they will expire and be deleted from the Postfix queue never reaching their recipient. However, I was able to send email successfully from that Ubuntu/Postfix/OpenSSL system to Exchange 2007 on Windows Server 2003, by adding this setting in "/etc/postfix/main.cf" and then restarting Postfix: smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5 For bonus points, I have uploaded a screenshot detailing the problem here: https://s21.postimg.org/uidiuwupj/2016_11_18_problema_Open_SSL_1_0_2_con_Windows_Se.png Because of all that, I have had to resort to extreme measures to keep the mail flowing (which is what my paying customers happen to appreciate most and above all): I have disabled the STARTTLS verb on the Exchange 2007 "receive connector" which listens on port 25. Therefore, no more "opportunistic SSL/TLS" for external senders trying to send email to my customers' Exchange 2007 systems -- from now on, all incoming email from the Internet will be received "encrypted" in plain text. (PS: I'm posting this to document this problem and the solution I was forced to adopt. It may help others who, as it happens to my clients, may not yet be able/ready to migrate to a more modern groupware version. This is not meant as a rant.) Regards, -- Josh Good
