Embarq blocking port 465 used for smtps due to Cisco vuln 2007-11-10 03:11
Journal
by
LoadWB
on Saturday November 10 2007, @03:11AM
Port 465 was recommended for use as smtps, or SMTP using explicit SSL, in the Netscape SSL v3.0 draft date back in 1996. Unfortunately this port was already, or at least is now, used by Cisco for urd, or the URL Rendezvous service (whatever the heck that is.) For the past five years now I have been providing authenticated SMTP transport over SSL on port 465, as seems to be the de-facto standard (look at GMail's configuration section, for instance.)
Thursday I was made aware that several customers were unable to send email through my server colocated within the Sprint/Embarq network. At first it seemed that ComCast was blocking port 465 outbound as other ISPs did not appear to exhibit the same behavior, and neither myself nor my colocation have any ACLs what-so-ever related to ComCast or port 465.
What I discovered later, however, was that people using Sprint PCS data cards and my own AT&T data card and phone were unable to send email as well. Further prodding revealed that somewhere far upstream, Sprint/Embarq has a blanket block on port 465 due to a Cisco vulnerability.
Cisco Security Advisory: Crafted IP Option Vulnerability
Document ID: 81734
Advisory ID: cisco-sa-20070124-crafted-ip-option
http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb157.shtml
What really chaps my hide about this is that Sprint/Embarq could have easily put ACLs in place that protected their Cisco equipment without disturbing customers down-stream. I find it hard to believe that no one in their network administration has ever heard of smtps on port 465, and the implications of blocking this port to all destinations. Then to add insult to injury, not providing notifications down-stream.
Now for two days customers using what has been considered to be a standard set up for smtps have been unable to send email through my server. I've now spent numerous unbillable hours tracking down the problem and coordinating with affected customers to use an alternate configuration.
Of course I would prefer to use TLS with customers, but Outlook and Outlook Express, the predominate email client for business offices, do not support it. Thank $_DEITY that Exchange does. Then there's the issue of outbound port 25 blocking that several ISPs do, but I've been using port 925 (semi-random choice) to get around that since 2000. I understand now that port 587, the submit port, is the recommended port for this, but I imagine it's only a matter of time before that's blocked as well, and I have questions as to the legitimacy of using submit for this purpose.
Thursday I was made aware that several customers were unable to send email through my server colocated within the Sprint/Embarq network. At first it seemed that ComCast was blocking port 465 outbound as other ISPs did not appear to exhibit the same behavior, and neither myself nor my colocation have any ACLs what-so-ever related to ComCast or port 465.
What I discovered later, however, was that people using Sprint PCS data cards and my own AT&T data card and phone were unable to send email as well. Further prodding revealed that somewhere far upstream, Sprint/Embarq has a blanket block on port 465 due to a Cisco vulnerability.
Cisco Security Advisory: Crafted IP Option Vulnerability
Document ID: 81734
Advisory ID: cisco-sa-20070124-crafted-ip-option
http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb157.shtml
What really chaps my hide about this is that Sprint/Embarq could have easily put ACLs in place that protected their Cisco equipment without disturbing customers down-stream. I find it hard to believe that no one in their network administration has ever heard of smtps on port 465, and the implications of blocking this port to all destinations. Then to add insult to injury, not providing notifications down-stream.
Now for two days customers using what has been considered to be a standard set up for smtps have been unable to send email through my server. I've now spent numerous unbillable hours tracking down the problem and coordinating with affected customers to use an alternate configuration.
Of course I would prefer to use TLS with customers, but Outlook and Outlook Express, the predominate email client for business offices, do not support it. Thank $_DEITY that Exchange does. Then there's the issue of outbound port 25 blocking that several ISPs do, but I've been using port 925 (semi-random choice) to get around that since 2000. I understand now that port 587, the submit port, is the recommended port for this, but I imagine it's only a matter of time before that's blocked as well, and I have questions as to the legitimacy of using submit for this purpose.
- Nothing More
