Topic: [SOLVED] Mail rejected due to SSLv2 cipher?

[smiit]

Getting reports that users are not receiving email from several senders - error log on sender side reports:

Code: [Select]

TLSconnectfailed:error:140770FC:SSLroutines:SSL23_GET_SERVER_HELLO:unknownprotocolZConnectedtoMY.PUBLIC.STATIC.IP but
connectiondied.error:140770FC:SSLroutines:SSL23_GET_SERVER_HELLO:unknownprotocol(#4.4.2)I'mnotgoingtotryagain;
thismessagehasbeeninthequeuetoolong.
Google tells me this might be because the sender is trying to connect via SSLv2 ?

Our SME 9 server is indeed set to recommended default cipher strength to disable SSLv2:

Code: [Select]

CipherSuite=HIGH:!SSLv2:!ADH
My best guess is our SME9 server won't accept their lower cipher so their server is unable/unwilling to send mail?

If my guess is correct is there no such thing as negotiation UP on the sender server to use a higher-level cipher instead of just failing?

Or is this some other issue/misconfiguration on their end or our end?

[Daniel B.]

If they are still using SSLv2, there's clearly something wrong on their side

[CharlieBrady]

You could probably work around the issue by disabling STARTTLS on port 25 - either all the time, or selectively for their IP addresses.

I don't know how precisely you would do that, but I'm sure that it is possible.

[CharlieBrady]

Alternatively, you could allow STARTTLS, even with SSLv2, but don't permit authentication if weak SSL is negotiated. Again, exactly how you would do that is left as an exercise

Since we are prepared to accept their mail via an unencrypted smtp connection, then it should be OK for them to use weak SSL as well. As to why their MTA is bothering to 'upgrade' the connection from plaintext to SSLv2 - who knows...

[CharlieBrady]

I'm guessing from the server-side message log you showed that they are using a patched qmail MTA at the server end. If so, looks like the patches need to be updated and qmail re-compiled.

[smiit]

Thank you for the insights, Charlie.

I'm considering re-enabling SSLv2 per the wiki at http://wiki.contribs.org/SME_Server:7.5.1#Web_Server

Code: [Select]

[root@test7 ~]# db configuration setprop qpsmtpd tlsCipher 'ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM' [Note: all on one line]
[root@test7 ~]# signal-event email-update

and request outside client resend mail and see if that clears things up before getting into more precise template/plugin adjustments.

[CharlieBrady]

I'm guessing from the server-side message log you showed that they are using a patched qmail MTA at the server end. If so, looks like the patches need to be updated and qmail re-compiled.

Or maybe they just need to supply an appropriate tlsclientciphers configuration file:

http://www.qmailwiki.org/Qmail-control-files#control.2Ftlsserverciphers

[smiit]

I lowered the qpsmtpd tlscipher setting but still getting connection errors similar to this bug -- http://bugs.contribs.org/show_bug.cgi?id=8727

Sample qpsmtpd log (sender info masked):

Code: [Select]

2015-02-10 11:31:53.242263500 11626 220 Go ahead with TLS
2015-02-10 11:31:53.280047500 11626 Plugin tls, hook unrecognized_command returned DENY, TLS Negotiation Failed
2015-02-10 11:31:53.280203500 11626 logging::logterse plugin (deny): ` $SENDERIP sender.domain.com sender.domain.com tls 901 TLS Negotiation Failed msg denied before queued
2015-02-10 11:31:53.280227500 11626 500 TLS Negotiation Failed
2015-02-10 11:31:53.280324500 11626 dispatching �$�����9��8��5��3��2��/������
2015-02-10 11:31:53.280325500 11626 running plugin (unrecognized_command): tls
2015-02-10 11:31:53.280401500 11626 Plugin tls, hook unrecognized_command returned DECLINED,
2015-02-10 11:31:53.280402500 11626 running plugin (unrecognized_command): count_unrecognized_commands
2015-02-10 11:31:53.280424500 11626 count_unrecognized_commands plugin (unrecognized_command): Unrecognized command '�$�����9��8��5��3��2��/������'
2015-02-10 11:31:53.280522500 11626 Plugin count_unrecognized_commands, hook unrecognized_command returned DECLINED,
2015-02-10 11:31:53.280523500 11626 500 Unrecognized command
2015-02-10 11:31:53.318526500 11626 dispatching ������ÿÜ÷
™‰ßê'‰m1ß3QUIT
2015-02-10 11:31:53.318537500 11626 running plugin (unrecognized_command): tls
2015-02-10 11:31:53.318634500 11626 Plugin tls, hook unrecognized_command returned DECLINED,
2015-02-10 11:31:53.318635500 11626 running plugin (unrecognized_command): count_unrecognized_commands
2015-02-10 11:31:53.318635500 11626 count_unrecognized_commands plugin (unrecognized_command): Unrecognized command '������ÿÜ÷
™‰ßê'‰m1ß3quit'
2015-02-10 11:31:53.318663500 11626 Plugin count_unrecognized_commands, hook unrecognized_command returned DECLINED,
2015-02-10 11:31:53.318742500 11626 500 Unrecognized command
2015-02-10 11:31:53.319646500 11626 running plugin (disconnect): rhsbl
2015-02-10 11:31:53.319656500 11626 Plugin rhsbl, hook disconnect returned DECLINED,
2015-02-10 11:31:53.319667500 11626 running plugin (disconnect): dnsbl
2015-02-10 11:31:53.319767500 11626 Plugin dnsbl, hook disconnect returned DECLINED,
2015-02-10 11:31:53.319768500 11626 running plugin (post-connection): tls
2015-02-10 11:31:53.319843500 11626 Plugin tls, hook post-connection returned DECLINED,
2015-02-10 11:31:54.136564500 2573 cleaning up after 11626
$SENDERIP address and domain are in the wbl whitelisthosts db so I'm not sure what's happening here.

Is tls broken on their end or ours?

[CharlieBrady]

Is tls broken on their end or ours?

Probably their end, but you'd need to study a packet capture to be sure. What is the identity of the sending domain? Someone might be able to find other reports and other workarounds if you identify them.

As I mentioned earlier, disabling STARTTLS support on port 25, either globally, or just for their IP address range would be good ways of working around the problem.

[smiit]

Searching for a way to disable STARTTLS - not sure where that's configured.

Flight itinerary email sent from unitedairlines@united.com is one of the senders that are failing tls negotiation.

Now I'm wondering if our cert is configured incorrectly - if I connect from inside I get this:

Code: [Select]

[root@mydomain ~]# openssl s_client -connect localhost:465 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
followed by all the remaining certificate details and a tlsv1 handshake/session.

If I connect from outside I get this:

Code: [Select]

[root@outside ~]# openssl s_client -connect mydomain.com:465 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
10083:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:591:
How would I interpret that?  Does it just mean SME has SSLv2/v3 disabled?

Or that something isn't right on our mydomain.com server?

Still not sure this is a bug or a config error.

[CharlieBrady]

How is your server connected to the Internet? Are you sure that the connections from outside are really making it to your server and are you sure that nothing is corrupting the data path?

If you provide correct information to us, instead of mydomain.com, then we could check for ourselves.

[CharlieBrady]

Flight itinerary email sent from unitedairlines@united.com is one of the senders that are failing tls negotiation.

Probably not likely that they are insisting on SSLv2 in their connections.

I notice that you did the openssl client check to port 465, but the original problem is STARTTLS on port 25. You can use:

 openssl s_client -starttls smtp -crlf -connect 1.2.3.4:25

to test starttls on port 25.

[smiit]

How is your server connected to the Internet? Are you sure that the connections from outside are really making it to your server and are you sure that nothing is corrupting the data path?

If you provide correct information to us, instead of mydomain.com, then we could check for ourselves.

domain to check is smialcott.com - static IP via Comcast.  Possible that they have blocked port 25?

[DanB35]

domain to check is smialcott.com - static IP via Comcast.  Possible that they have blocked port 25?

Don't think so:

Code: [Select]

[dan@e-smith ~]$ openssl s_client -starttls smtp -crlf -connect smialcott.com:25
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.smialcott.com
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.smialcott.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFVDCCBDygAwIBAgIQavC7hn0IS9KoxsyuTOY//TANBgkqhkiG9w0BAQsFADCB
kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV
BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0xNDEyMjcwMDAwMDBaFw0xNTEyMjgyMzU5NTlaMFwxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEdMBsGA1UECxMUUG9zaXRpdmVTU0wgV2ls
ZGNhcmQxGDAWBgNVBAMUDyouc21pYWxjb3R0LmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMLyJ1XEVkQj4SnX5XjWxw/E1ZsifyD8L5UgIt/9n/b7
OWAceF4EVKHVa7R0mPB7Xc1akfryxJpAbQvNPijPIp4pkE7nW28nYgZmu/fxgT+b
xtITIL7qT1vvnDHerCUoqBIK/UEND82tmXPr6QNfNKDqfTuj7aaaNJSBzr8d3BWY
S94OsPewDNhiUWfJiJTzW40HmGt3MrqNzqdK0k6ku1UudNdn3wEKH+xL3J4tPTnH
BDrF1og7MDbBBX7fbpjvL6UKZ2yozZ0k/fGlxxVvMJ7qboriW1fvIBor+4u9h5/t
RxGYsVV8x9E4egru0DbOeFEf3C8uB1RsonRcSxbNKfsCAwEAAaOCAdswggHXMB8G
A1UdIwQYMBaAFJCvajqUWgvYkOoSVnPfQ7Q6KNrnMB0GA1UdDgQWBBTxBzAuQiMl
LlNBjIrPx8vlLUZ6QDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6BgsrBgEEAbIx
AQICBzArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQ
UzAIBgZngQwBAgEwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL2NybC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNy
bDCBhQYIKwYBBQUHAQEEeTB3ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LmNvbW9k
b2NhLmNvbS9DT01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0Eu
Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wKQYDVR0R
BCIwIIIPKi5zbWlhbGNvdHQuY29tgg1zbWlhbGNvdHQuY29tMA0GCSqGSIb3DQEB
CwUAA4IBAQCJAITTB7LfUUGPDQkHw8J0WLEay8aNWw/5hoUZ9eN5tVbirUDlB+Z7
hab3KYN03a096NQHNJmeQSHUcodsobx7nizHBKF35y1tNoiqxh933QfUjdP78dfv
3VZycrZUxiEf0MVenloJwuNbDuPHOHO/v+suH8VK5VCXnZa1F0YMNzzsS9431cPp
gpcsc89rJUaDh/sZMiJxFfpaGnNW9p4cxJZ9WpSYdQ0J1dqDb0naKgwNvYmFCWhB
6Wvbjxyy/GYU7ShOUUKuh2XcYA54yIvw3/ZgFDQqxk56oOB6S/ZZddDrCX5xnGYJ
j0xEpOCGXa/oemcEyQ3HRN/4BTNmDN+L
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.smialcott.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 5934 bytes and written 610 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 12BE100B4E03B9DB75D5995751D69C3C90EF247D1FB884B82C479DED0D4F98EB
    Session-ID-ctx:
    Master-Key: A6BA661F41432B2F2B5EF710184FEEA9DB8C0F2D1976E1120F117401EB93C8401552286BC71DF4D7F9E7E1484208A72A
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 41 73 a0 e1 45 42 0e 73-1d 96 55 bb 7a da 00 b6   As..EB.s..U.z...
    0010 - de 4c c0 bc e1 74 35 f6-9c 33 ff 03 e8 c8 fc d9   .L...t5..3......
    0020 - ec 23 f0 7e 0a 0f cc b6-8a e7 35 52 aa 83 b9 41   .#.~......5R...A
    0030 - 44 fc 7d 1e 14 81 18 72-ad d0 85 90 35 92 f3 79   D.}....r....5..y
    0040 - f8 7f 86 b7 44 87 a5 16-96 33 b9 73 08 c2 78 13   ....D....3.s..x.
    0050 - df 06 97 14 ed 40 65 23-41 35 66 6a bc fb ec 36   .....@e#A5fj...6
    0060 - 7b fc 15 71 b6 90 f2 1f-df bc 3d f7 00 4a b5 a1   {..q......=..J..
    0070 - 23 c6 c0 79 c4 79 c6 a6-a1 42 99 5a db 7d 00 bd   #..y.y...B.Z.}..
    0080 - 5e 6c 7f d5 d4 c0 b8 dc-51 d3 ce 5c 53 63 99 c3   ^l......Q..\Sc..
    0090 - 10 a0 8f 85 84 c8 29 85-45 7c a3 a8 53 0d 32 35   ......).E|..S.25

    Start Time: 1423681639
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
250 STARTTLS


[CharlieBrady]

I get different results to DanB35, from a test host which doesn't have the latest openssl installed yet:

Code: [Select]

-bash-3.2$ openssl s_client -starttls smtp -crlf -connect smialcott.com:25
CONNECTED(00000003)
26059:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:591:
-bash-3.2$

But I wonder whether this is an SSLv3 v TLS1 difference:

Code: [Select]


-bash-3.2$ openssl s_client -ssl3 -connect smialcott.com:465
CONNECTED(00000003)
26056:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1092:SSL alert number 40
26056:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:536:
-bash-3.2$ openssl s_client -tls1 -connect smialcott.com:465
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify return:1
depth=2 /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
verify return:1