I've been seeing some odd behavior today with some of the servers that respond to smtp.comcast.net on port 587. Some, but not all, of the servers are presenting self-signed certs, causing my own server to balk at making a connection. (The Organization is RTFM, Inc. -- it'd be funny if mail wasn't queueing up on my end). Sometimes I get a server with a legit cert, so I can slowly drain my queue by flushing it over and over and over... openssl s_client output below. I can send a libpcap trace on request. --Jeff ┌─(root@bookcase)(04:48:06) └─(~)-> openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect smtp.comcast.net:587 CONNECTED(00000003) depth=1 /C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=localhost i:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 1 s:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 i:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 --- Server certificate -----BEGIN CERTIFICATE----- MIICGDCCAYECAgEBMA0GCSqGSIb3DQEBBAUAMFcxCzAJBgNVBAYTAlVTMRMwEQYD VQQKEwpSVEZNLCBJbmMuMRkwFwYDVQQLExBXaWRnZXRzIERpdmlzaW9uMRgwFgYD VQQDEw9UZXN0IENBMjAwMTA1MTcwHhcNMDEwNTE3MTYxMDU5WhcNMDQwMzA2MTYx MDU5WjBRMQswCQYDVQQGEwJVUzETMBEGA1UEChMKUlRGTSwgSW5jLjEZMBcGA1UE CxMQV2lkZ2V0cyBEaXZpc2lvbjESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCiWhMjNOPlPLNW4DJFBiL2fFEIkHuRor0pKw25 J0ZYHW93lHQ4yxA6afQr99ayRjMY0D26pH41f0qjDgO4OXskBsaYOFzapSZtQMbT 97OCZ7aHtK8z0ZGNW/cslu+1oOLomgRxJomIFgW1RyUUkQP1n0hemtUdCLOLlO7Q CPqZLQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAIumUwl1OoWuyN2xfoBHYAs+lRLY KmFLoI5+iMcGxWIsksmA+b0FLRAN43wmhPnums8eXgYbDCrKLv2xWcvKDP3mps7m AMivwtu/eFpYz6J8Mo1fsV4Ys08A/uPXkT23jyKo2hMu8mywkqXCXYF2e+7pEeBr dsbmkWK5NgoMl8eM -----END CERTIFICATE----- subject=/C=US/O=RTFM, Inc./OU=Widgets Division/CN=localhost issuer=/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 --- No client certificate CA names sent --- SSL handshake has read 1965 bytes and written 375 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 8B976D67A76BBFEF5E46CA9D079C1C1208D037B8F5825049C45B57C05786A891 Session-ID-ctx: Master-Key: 4DC43D803056BF32082F3E35B2818539E33B7321455AD625D3AD124BAD719C12C5903C9F1889EAB7A5F313B9A54D74A6 Key-Arg : None Start Time: 1232081287 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 250 OK
* Jeff Mitchell:
I've been seeing some odd behavior today with some of the servers that respond to smtp.comcast.net on port 587. Some, but not all, of the servers are presenting self-signed certs, causing my own server to balk at making a connection. (The Organization is RTFM, Inc. -- it'd be funny if mail wasn't queueing up on my end). Sometimes I get a server with a legit cert, so I can slowly drain my queue by flushing it over and over and over...
There's no PKI for Internet Mail routing, so I don't see what you get by checking certificates at all.
On Fri, Jan 16, 2009, Florian Weimer wrote:
There's no PKI for Internet Mail routing, so I don't see what you get by checking certificates at all.
Function, non-broken Outlook integration. Adrian (Who is -fed up- with outlook just randomly spewing crap at you from time to time if you use self-signed certs for various mail related activities. Or chained certs. Sigh. :)
* Adrian Chadd:
On Fri, Jan 16, 2009, Florian Weimer wrote:
There's no PKI for Internet Mail routing, so I don't see what you get by checking certificates at all.
Function, non-broken Outlook integration.
Oops, silly me. I assumed that this was about SMTP, it's about message submission (and the OP made that quite clear). Sorry for the noise.
On Fri, 16 Jan 2009, Florian Weimer wrote:
There's no PKI for Internet Mail routing, so I don't see what you get by checking certificates at all.
That's not entirely true. SMTP over TLS is intended to work for inter-domain SMTP, and it is in fact quite frequently used. However it is utterly broken, with the result that what PKI there is is not in practice used. The brokenness is: * TLS certificates verify host names not mail domains, so they only provide protection for the result of an MX lookup - they don't verify the MX lookup itself was not spoofed. * Most SMTP software does not check certificates and many certificates installed on MX hosts have different common names from the MX record target hostname. Turning on certificate verification breaks too much email, and there's no incentive for postmasters to install valid certificates. These problems are extremely hard to fix. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ FITZROY SOLE: WEST OR SOUTHWEST 5 TO 7, INCREASING GALE 8 AT TIMES, THEN BACKING SOUTH 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH OR HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Tony Finch wrote:
That's not entirely true. SMTP over TLS is intended to work for inter-domain SMTP, and it is in fact quite frequently used. My understanding is that Comcast uses it simply for encryption, not for authentication. * Most SMTP software does not check certificates and many certificates installed on MX hosts have different common names from the MX record target hostname. Turning on certificate verification breaks too much email, and there's no incentive for postmasters to install valid certificates.
You're right; certificate verification was turned on on my end simply because I'd never had a reason to turn it off (since in recent times the majority of my mail goes through their gateway, which has never presented an invalid certificate to me before). However, in this case, there is another benefit: the presence of what was clearly a default certificate on some of their servers, where before there were always valid certificates presented, could indicate that the rest of the mailserver was incorrectly configured. Better that mail is delayed than it is accepted and ends up bounced or disappearing into the ether (that was my main incentive for the OP) :-) FWIW, this seems to be fixed today. --Jeff
On Fri, 16 Jan 2009, Jeff Mitchell wrote:
You're right; certificate verification was turned on on my end simply because I'd never had a reason to turn it off (since in recent times the majority of my mail goes through their gateway, which has never presented an invalid certificate to me before).
Message submission is very different to inter-domain SMTP. There's no MX indirection, so the TLS certificate actually verifies the correct name, and certificate verification is normal on the client, and correct certificates are normal on servers. A much better situation. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ PORTLAND PLYMOUTH: SOUTHWEST 5 TO 7, INCREASING GALE 8 AT TIMES. ROUGH, OCCASIONALLY VERY ROUGH IN PLYMOUTH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
On Jan 16, 2009, at 8:54 AM, Tony Finch wrote:
On Fri, 16 Jan 2009, Jeff Mitchell wrote:
You're right; certificate verification was turned on on my end simply because I'd never had a reason to turn it off (since in recent times the majority of my mail goes through their gateway, which has never presented an invalid certificate to me before).
Message submission is very different to inter-domain SMTP. There's no MX indirection, so the TLS certificate actually verifies the correct name, and certificate verification is normal on the client, and correct certificates are normal on servers. A much better situation.
Tony.
Sure, but, in that case, it's also perfectly valid to load the self- signed root certificate for that SMTP server's cert. chain into the trusted roots set. Owen
I submitted a ticket to Comcast yesterday around 10:00 AM EST regarding this issue (ticket #151689315), received a standard reply last night, but as of yesterday 14:45 EST, the issue seems to have resolved itself. Here's the certificate I saw: Issued To Common Name (CN) - localhost Organization (O) - RTFM, Inc. Organizational Unit (OU) - Widgets Division Serial Number - 01:01 Issued By Common Name (CN) - Test CA20010517 Organization (O) - RTFM, Inc. Organizational Unit (OU) - Widgets Division Validity Issued On - 5/17/2001 Expires On - 3/6/2004 Fingerprints SHA1 Fingerprint - 15:13:DF:CF:8B:BE:63:2D:91:BC:2E:B3:ED:29:8D:74:06:4D:7D:8A MD5 Fingerprint - 21:91:FB:FE:F3:13:AF:74:53:48:56:B4:EF:7A:13:69 Eric
Eric Tow wrote:
I submitted a ticket to Comcast yesterday around 10:00 AM EST regarding this issue (ticket #151689315), received a standard reply last night, but as of yesterday 14:45 EST, the issue seems to have resolved itself. I can verify that it was still happening as of about 12:10 AM EST this morning, when I submitted the OP (the output there was grabbed right before I posted). I'm out of the country so calling them up to submit a ticket was not possible.
I did get word in a private message that the people in the department responsible say that it is fixed now. Thanks, Jeff
participants (6)
-
Adrian Chadd -
Eric Tow -
Florian Weimer -
Jeff Mitchell -
Owen DeLong -
Tony Finch