ATT Wants You to Give Them Your Data!

ATT wants to spy on all your Traffic, and has proposed an Internet standard, so that anybody can do it, anywhere in the world. To us, this seems like a BAD idea. Their bad idea involves decrypting any traffic you send via HTTPS, looking at it, then re-encrypting it and sending it to wherever you wanted it to go. Some call this a Man-In-The-Middle (MITM) attack. ATT’s proposed Internet standard, an IETF proposal, would make it part of the Internet protocol collection, to be adopted by ISPs and others around the world.

ATT’s motivations

One has to wonder why ATT would “stick its neck out” this way. Surely they realize that asking people to trust them after spying on you is unlikely to result in a favorable response. Here are two possibilities, both reasonably likely.

1. The NSA and other want this. It forces you to give permission for AT&T to spy on you and under the various US surveillance acts, makes it spying both consensual and legal.

2. It provides a mechanism for AT&T to implement the intellectual property provision hinted in the TTP and Trans-Atlantic treaties.

ATT’s proposal provision is not stupid and misinformed. It is Policy. Deliberate, planned, and driven by the current backlash against surveillance and the probability of the ISPs having to implement the intellectual property provisions of TPP and TTIP. They want to implement a technique that can be used worldwide to ensure that you’re not violating any of their secret intellectual property provisions in these trade partnerships that you’re not allowed to know about, except through the occasional leak by someone with a conscience. By the way, those agreements, if implemented in their present form, would do enormous damage to the Internet.

The serious side-effect is the Internet would be compromised forever for commerce and banking, because neither you nor your bank would be able to trust the “trusted proxy”.

In other words, it’s like giving your credit card to a stranger, and pre-signing all paper vouchers for the card.

Or publishing your Bank & Credit Card Statements, Tax Returns and Medical Record on the Internet.

What’s Going on in the IEFT (Standards Body) This article clearly shows the additional dangers that ATT’s “trusted” proxy server creates for you, the end user, who merely wants to visit a website with your browser. Notice this paragraph from the above SANS URL, which quotes the IETF draft document:

Users should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc. Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information.

So, for their own reasons, ATT & Ericsson engineers want to make your browsing dependent on the security of their “trusted proxy” in addition to all the other dangers that you face when browsing on the web. This danger is completely aside from the possibility that you might prefer them not to be reading over your shoulder. This blog spells out the response very well, here’s an excerpt:

No, I Don’t Trust You! — One of the Most Alarming Internet Proposals I’ve Ever Seen If you care about Internet security, especially what we call “end-to-end” security free from easy snooping by ISPs, carriers, or other intermediaries, heads up! You’ll want to pay attention to this.

You’d think that with so many concerns these days about whether large corporations, such as AT&T, Verizon, and other telecommunications companies can be trusted not to turn our data over to third parties whom we haven’t authorized, that a plan to formalize a mechanism for ISP and other “man-in-the-middle” snooping would be laughed off the Net. But apparently the authors of IETF (Internet Engineering Task Force) Internet-Draft “Explicit Trusted Proxy in HTTP/2.0” (14 Feb 2014) haven’t gotten the message. – Lauren Weinstein

As the blog entry states, what they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping! Of course, they don’t phrase it exactly that way. This is what they are proposing:

You <->  ATT “Trusted Proxy” <-> Your destination

to replace

You <—>  Your destination

So, as the diagram shows, you want to use a proxy server – possibly for anonymity, possibly because you’re at an Internet cafe and want to use the Internet without giving away your user credentials for your mail, or your bank, or other things for which privacy is important for your security.

(Note that privacy and security go together. It’s not “either-or”. It’s “BOTH or NEITHER!”)

The problem that the ATT and Ericsson engineers have is that you have chosen to protect your security with a proxy and encryption, and THEY WANT TO LOOK AT YOUR DATA. To do that, they want to decrypt your HTTPS data stream, look at your data, and then re-encrypt it and send it on its way. Therefore, they propose putting a “trusted proxy” in the circuit, where your data gets decrypted, viewed, and finally, is sent to the destination you wanted to go to in the first place. They want this to become an Internet standard, worldwide. Even if you trust ATT (and we know no reason why you should), you should oppose this, because your security is decreased. And, in the ATT-suggested method, if your security were violated, you would probably never know about it. If you don’t trust ATT, you now have two reasons to oppose this RFC draft from being adopted by the Internet Engineering Task Force (IETF). Let’s have a look at how this system could be abused.

Trusted Proxies as Criminal Hacking Targets

One of the key problems which this RFC would create is it would make targets out of all the “trusted proxies.” Entirely aside from ATT, or the NSA gaining access to your data stream, how about criminals stealing your banking, credit and health information? Any device through which that information passes, becomes desirable for criminals to access.

Here’s one scenario:

Wait for the system to be firmly established. Say six months or so. Find a Sysadmin with no family connection in the US, unmarried and offer to enrich him for a few small changes to the “Trusted Proxy” Web site. Install back door and filter to obtain all the credit card, bank account, and other information as it flowed and then sell all the information for a huge sum. It may well be possible for hackers to simply attack the “trusted proxy,” without involving any insiders, but with insiders, it’s easier. If criminals were in a position to bribe more than one sysadmin, they might be able to do even more damage. Once they gain access, it’s a matter of copying and selling the data.

Can ATT guarantee that there won’t be a breach? Could Target? Their last estimate was 110 million customer accounts affected. Can you trust ATT? Should you trust ATT?

But WAIT! This is not proposed as an ATT practice. It’s proposed as a WORLDWIDE approved practice of the Internet Engineering Task Force, if the IETF adopts the draft written by ATT & Ericsson engineers. This is a time for people around the world to voice their concerns. Liability and legal issues are also involved.


Consider the following: Your account information is leaked somehow, even though you were using HTTPS, as your bank says you should. You’ve lost money from your account. Your bank says “It’s not our fault. You were connected over a secure path to our server. We won’t reimburse you.” What would you do? Sue ATT in small claims court? If the ATT RFC draft is adopted, and becomes standard Internet engineering practice, we expect ATT to require their users to “voluntarily” trust their ‘trusted proxy’ in their terms of service. As part of the TOS, they would include a clause indicating that they are not liable. Either you agree to be spied upon, or your Internet browsing days are over.

The time to stop this is NOW! Later is TOO LATE.

This post was read 248 times.


About author View all posts


3 CommentsLeave a comment

  • Thank you. Well written and scary.

    The day that is approved is the day I go offline for anything requiring security – banking, bill-paying, etc.

    Prior to the Internet, the business community had various communication systems to move information – banking and brokerage in particular invested heavily in such hardware/software systems. Most of the major players used dedicated circuits, often between mainframes. Dial-up was also an option, providing a ‘temporary’ dedicated circuit. The Federal Reserve Bank took it a step further, requiring their own custom-built modems on each end of the dedicated lines. There were a lot of security mechanisms implemented in this environment and it was all as secure as the physical security of the hardware. It worked because entities requiring such security numbered in the thousands, probably the low thousands. In a world with hundreds of millions of users, such methods would be impractical and prohibitively expensive. Cheaper methods of security were implemented – and you get what you pay for.

    I have never considered the Internet secure. TCP/IP was a great idea, very badly implemented. It’s not that one cannot have security. It’s just that it has to be done outside the protocols of TCP/IP and the Internet infrastructure.

    When banks and businesses realize no one will do online business, the kickback will begin. You think Jeff Bezos is going to shrug, take his billions and fold Amazon when he realizes nobody will trust them with their credit card data. My guess is that some enterprising chaps will simply provide a work-around. Not necessarily fool-proof, mind you, since NSA/CSI can always indulge in its usual skullduggery, but at least bringing us back to https level security.

  • TCP/IP was a great idea, very badly implemented.

    Move the certificates and mandatory encryption to the TCP connection.

    And I’m very familiar with TP before the internet, especially SNA from VTAM 1.0 through VTAM 4.2. Encryption was added early, for the IBM 3614 ATM and used widely.

    Because encryption was considered a munition by the US, and export prohibited I had to visit the UK from South Africa and carry the BQKPERS and BQKCYPH encryption modules back on punched cards, to enable the sale of the IBM 3614 ATMs.

    • Similar background, altho I predate SNA & VTAM considerably – think bisync and 83B3 Teletype. 😀
      Coded two different systems down-to-the-metal, using every method short of smoke signals, including some one-of-a-kind protocols.

      Part of the problem is that TCP/IP grew from a system of very limited use, restricted to ‘gentlemen’ (per Henry Stimson’s definition) via physically secure circuits between specialized computer systems. ComSec didn’t become a issue until late the the process and has always been an add-on rather than an integral part of the system.

      There was a company that developed software for moving files between systems. After several takeovers and buyouts and integrations, it’s now part of IBM as Sterling Connect:Direct. Originally using SNA/VTAM between IBM mainframes, it was ported to DEC, WinTel, Tandem and about any computer system out there. Originally relied on hunt-group dialup or dedicated circuits, they added the Internet to the mix via their own TCP components running thru their own assigned IP ports at each end, with proprietary encryption at the TCP level. They can thus keep their file transfers as secure as their encryption methodology provides. Assuming no one hacks into the pre-encrypted or post-decrypted file. 😀

Leave a Reply