Slashdot

This is a copy of the email I sent to AT&T.

A few years ago I began purchasing phones outside of Cingular's marketplace.
I found that Cingular did not carry the phones that I found useful or
attractive. A couple of years ago I picked up the Sony Ericsson K790a.
This is a CyberShot phone which does everything that I need for my personal
and business life.

Unfortunately, this phone is not an official Cingular phone. Even though it
runs the same operating system, Java Platform 7, as several other
Cingular-branded and supported phones, including several of the Sony
Ericsson W-series phones, I am prevented from making purchases online. This
includes ring tones, other multi-media, and Java games.

More importantly to me at this point is that I am prevented from using my
bank's on-line banking system because the application will not install on my
phone due to a missing root certificate.

I attempted to download the application using the link provided by my bank.
I found that the download would fail. I manually captured both the JAD and
JAR files comprising this application and discovered that the JAR file
*will* install and run on my phone, however as an untrusted application it
lacks some functionality.

Upon examination of the JAD file, I found that it contains two chained
certifications, the primary of which is signed by "Cingular Trusted Root CA"
root.

Certificate:
        Data:
                Version: 3 (0x2)
                Serial Number: 4955 (0x135b)
                Signature Algorithm: sha1WithRSAEncryption
                Issuer: C=US, O=Cingular Wireless, LLC, CN=Cingular Trusted CA 1
                Validity
                        Not Before: Nov 3 02:38:29 2007 GMT
                        Not After : Nov 1 02:38:29 2017 GMT
                Subject: C=US, ST=GA, L=Atlanta GA, O=Firethorn Holdings LLC, OU=ATT
Trusted for Java - Production, CN=CodeSigning for Firethorn Holdings LLC

Certificate:
      Data:
              Version: 3 (0x2)
              Serial Number:
                      50:3c:76:b8:74:c3:61:17:1f:2d:5f:c3:8e:af:fc:b5
              Signature Algorithm: sha1WithRSAEncryption
              Issuer: C=US, O=Cingular Wireless, LLC, CN=Cingular Trusted Root CA
              Validity
                      Not Before: Nov 3 00:00:00 2006 GMT
                      Not After : Nov 11 23:59:59 2023 GMT
              Subject: C=US, O=Cingular Wireless, LLC, CN=Cingular Trusted CA 1

The root certificate of this chain is not available anywhere for download.
I am told by Data Support that this certificate is not released to the
public and is only available on Cingular/AT&T-branded phones.

The implications are obvious to me: AT&T is preventing otherwise compatible
applications from running on unlocked phones by the use of a "secret" root
certificate. This artificially segregates the market and serves to help
reduce the overall value of my perfectly capable and compatible phone.

I can easily accept that AT&T does not know how to support unsanctioned
phones. For the most part, however, I have found that people capable of
selecting and purchasing an unlocked phone are also capable of supporting
themselves. We also can handle not being able to run Java apps which are
not capable of running on our phones.

But I cannot accept that an application which could run on my phone
otherwise is prevented from doing so artificially by way of a restricted
root certificate.

Thank you for your time.

--
Alan W. Rateliff, II

I have sat on this for a couple of weeks and I will no longer do so.

I have received spam email to an email address which was specifically used for communication with SprintPCS for my business data card account. Three other people who are also SprintPCS customers received the same email from the same source with the same content.

SprintPCS is adamant that it does not sell or give out customer account details.

According to my mail server logs, these emails began on January 17th. My concern at this point is that my email address, specifically crafted for use only with SprintPCS, that no one on the face of this planet or regional solar system has, and is not easy to guess, has been obtained by illegitimate means. That being the case, my concern is that other account details may have been obtained.

Over the course of two days and five hours on the phone I attempted to contact Sprint Corporate Security. I was shuffled from department to department so much that I have a detailed map of the phone tree. Only two people took interest in my problem: one person sent an email to a supervisor who never got back to me for more details, and another in Level 2 support tried to find someone who could help. Oh, well, one other person did offer to send me over to technical support so they could "block the email."

Sprint's fraud department told me that it could only act if my account had been used for fraudulent purposes such as unauthorized charges or phone calls. The fact that my private customer information, and possibly other customers', may be compromised did not raise any hackles in fraud.

At the behest of the Florida Department of Law Enforcement, I have filed a complaint with IC3, the Internet Crime Complaint Center, a joint between the FBI and the National White Collar Crime Center. At this time I have not heard anything else back and remain disturbed by the situation.

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.

END OF LINE

Mobile GMaps (http://mgmaps.com) is a free Java application for Java-enabled phones, like my Sony Ericsson K790a, which turns your phone into a GPS-enabled mobile mapping system, complete with on-line tracking, custom mapping, and a slew of other features continually being added.

Even though this program has been mature much longer than Google's own Java phone-based mapping program, which also does not include the heavily requested GPS functionality, Google has sent the author what is essentially a C&D email. The email apparently claims that MGMaps is a dirivative work, as this clause from the Google Maps for Mobile (http://google.com/gmm) terms of service is invoked.

Personally, I like MGMaps better than Google Maps for Mobile, if only for the GPS functionality alone, although it does provide many more features than GMM. I have always liked Google Maps over Yahoo! or MSN maps, but alas it is time to take up something new.

I think this is crap, and goes against the normally open spirit of Google, and the Google Maps API. I only found out about it tonight as I was driving home and decided to check for updates. I read in the release blurb about the new version removing support for Google Maps.

Read more about it at the MGMaps news page.

"Google requests removal of Google Maps support from MGMaps (July 31st, 2007)"
http://www.mgmaps.com/news.php?item=136