If the FCC calls ISP’s common carriers will that prevent them from molesting packets? Such ad sticking in ads or doing redirects?
I wonder if Obama is just blowing more smoke (or hot air) in that regard. Given his apparent love for the War on Terror, and for corporate lobbyists, I find it hard to believe that he would actually make any meaningful changes, or impose any hard limits on ISP actions.
I don't think he loves those things, he's just a coward, like most Democrats these days.
Random thought. Some email client extension that would show the Received: headers in some way, and highlighting the unencrypted hops, so the normally hidden network behavior would be better visible. On advanced level, remembering the history of the servers’ support, highlighting changes (“mailserver X changed crypto up”, “mailserver Y degraded crypto to 64 bits”, “mailserver Z used to do TLS but is not anymore”), and generally shining light on the behavior.
I’d propose it to show in e.g. a top right corner of a mail as a transparent overlay, in small font and with colors encoding both status and changes, that could be zoomed in with a click or mouseover.
The situation can be shown as a graph, where the servers are nodes and the communication between them is the edges. Each Received: line shows two adjanced nodes and one edge. The edge shows the lowest-common crypto level available to both the edge nodes (when it mentions what was used, usually it just mentions SSL/TLS). A database can keep history of the “edges”, for detecting and highlighting of the changes.
For bonus points, the behavior of the servers can be shared between a geographically diverse crowd (with some privacy risks as this leaks the communicating server names to a third party so beware). Any attempt to degrade the security will then be much more likely to be seen.
Same logging can be used during the upstream connection itself, for keeping track of the SSL certificates and their changes. This can not be derived from the email headers themselves as not even the cert fingerprints are stored in the headers. Direct connections to the servers, initiating STARTTLS and looking at the certs are of course possible - but they may not catch MITM attack with forged or spoofed cert if done from a third-party location outside of the monitored network (e.g. your country national firewall does it but my one does not, so testing from my side to a server in a third country will not show anything suspicious; geolocation-based load balancing may also provide false positives, but these are comparatively easy to whitelist).
FTFY.
Pox on both their houses.
Don't take the lazy road of equivalence.
Is it that much worse than the lazy road of partisanship, or - worse - Faux News?
Not lazy. More of an epiphany.
Republican: Sure I screwed you over. What about it? Wanna fight?
Democrat: I’m sorry but I couldn’t prevent you from getting screwed over…yet again.
It’s the yet again part that tells the tale. You can count on it. Every time.
Its exactly as bad. Its lazy in exactly the same way. You turn to a theory with lower information content so its easier to think about. Its easy to say "The hell with all of them!" Its hard when you have to compare and evaluate. Saying "all politicians are equally cowardly" is like saying "all worldviews are equally true".
Makes no sense.
I saw what you did there. It’s called a strawman argument. Look it up.
It just so happens that there is a recent story on BoingBoing about this very issue:
The list in the story shows both Democrats and Republicans taking the money and doing bad things. I’m making the observation that they have different ways of explaining it to the rest of us. It’s an observation, not a theory. You might try refuting it with observations of your own. However, they will probably have to be from a parallel universe. Which is fine. I’m getting used to it.
Both parties have corruption, sure. But as for cowardliness, the democrats are singular. They lost thus election because they are afraid to stand up for their policies.
If they are both evil though, just think about which party supports gay rights, equal pay, raising the minimum wage, voting rights, civil rights, etc.
One party stands up for these things, the other doesn’t, they are not equal.
So we’re down to disagreeing on a matter of degree. You say there is corruption in both parties. I say Washington is drowning in money and corrupt to the core. They know what happens if they don’t take the money - it’s game over. The last one to do that as I recall was Russ Feingold who declined to take any money from the leadership fund(of course with strings attached). He lost his reelection bid to the well financed campaign of Ron Johnson. But he has my undying admiration for what it’s worth.
So they take the money and do what their monied masters tell them to do. And those issues you and I both care about? Red meat. The Republicans do the same thing with abortion and taxes. But in the end, it’s all about the money. Huge piles of money.
Speaking as a security practitioner of ~20 years there is more than a bit of smoke and mirrors in this post and the EFF’s article. Lets clarify what SMTP over TLS really is and what it isn’t.
- SMTP over TLS is not a VPN by any means. The reason to do SMTP over TLS at all is because for whatever reasons, message level security like PGP or a VPN where you have far more granular control over channel encryption is simply impracticable. SMTP over TLS is basically a way for Organization A to talk to Organization B with moderate channel security only while retaining the ability to talk to everyone else in the usual manner. Since it is not a VPN, making the distinction that SMTP over TLS secures metadata is not helpful fundamentally.
- SMTP over TLS is best effort only. Unlike a VPN you simply can not say “do not establish any communications with the next hop server unless the following encryption requirements can be established”. Doing so fundamentally breaks email and that is generally unacceptable. SMTP email works because it is designed so as mail is highly likely to reach its eventual destination even if the destination mail server is temporarily unavailable or several relays are involved. Mandating SMTP over TLS in this case would mean that one would require that every potential mail relay supported an evolving list of communications requirements.
The EFF’s article is slightly disingenuous in a few places:
a well-configured email server with STARTTLS can provide Forward Secrecy for emails.
That is a bit of a sketchy claim. Forward Secrecy is about key exchange, which is a part of but not generally descriptive of channel security. What they seem to be implying here is what a VPN does do in that VPN traffic only shows connections between point A and point B but not what kind of traffic or the ultimate source or destination of the traffic. See above bullet points.
Some firewalls, including Cisco’s PIX/ASA firewall do this in order to monitor for spam originating from within their network and prevent it from being sent. Unfortunately, this causes collateral damage: the sending server will proceed to transmit plaintext email over the public Internet, where it is subject to eavesdropping and interception.
To the best of my knowledge this is a configurable option on firewalls if the option is present at all. The article the EFF links to makes that very clear. At the enterprise or ISP level its pretty darn unlikely that one drops in a firewall without understanding the config options for important or critical traffic but it does happen. In both these contexts spam monitoring is considered important and traffic inspection has been a feature of commercial and non commercial firewalls for decades. It isn’t really accurate to call this “collateral damage” considering the matter of what SMTP over TLS is and is not above.
STARTTLS was also relatively uncommon until late 2013, when EFF started rating companies on whether they used it.
Seems a bit tooting ones own horn but aside from that, based on what I know from other security professionals SMTP over TLS picked up some years before that mostly when Exchange servers started supporting it which gave Company A the option to encrypt email channels to Company B and leave other internet traffic in plain text. This became popular as a “zero cost, zero headache” solution avoiding the pain and pricing of commercial PGP or VPN gateway setup, both of which require the admins on both sides to know what they are doing.
It is important that ISPs immediately stop this unauthorized removal of their customers’ security measures.
Unauthorized? Was it promised in the contract? Was there any other form of guarantee of this service? Also SMTP over TLS is not a customer security measure as this isn’t about communications between the client software and the fist hop mail server at the ISP.
ISPs act as trusted gateways to the global Internet and it is a violation of that trust to intercept or modify client traffic, regardless of what protocol their customers are using. It is a double violation when such modification disables security measures their customers use to protect themselves.
But this is not about modifying client traffic and is not a client software setting at all. Client side would be PGP or S/MIME on the desktop. This statement is borderline deceptive.
Oh. Since when it is the common understanding that ISPs are supposed to tamper with traffic? They are (or at least should be) just dumb packet haulers. I can put up with port blocking, but looking into opened connections and degrading their security goes over the line for me.
There are some default reasonable expectations that should not have to be expressly specified.
Should a delivery company have to expressly specify in the contract that they will not look into the packages sent through them and remove opaque wrappers?
This IS a customer security measure. Look at the mail client SMTP setting, you will see the option there. Ipso facto STARTTLS is part of the customer security.
When I was adminning mailservers, in early 2000s I was running qmail-1.03 with SSL/TLS patch and some homemade patches (including the one enabling the DH suite of ciphers for forward secrecy, which was an inspiration of a differently done one for qmail-1.04 by its maintainer; my patch was rejected-code accepted-idea).
PGP and S/MIME are one facet, SMTP/STARTTLS is another one. As shown above.
Its been since the early 90s that I directly worked for an ISP but some other jobs I’ve had since then have had me working closely with them so I can confidently answer that traffic inspection or manipulating/dropping traffic based on Layer 7 content has been around at least that long. Two examples from back in the day would be part of sendmail.cf file where you would limit outbound SMTP traffic to only those domains which were explicitly authorized. X-POST header limits were commonly done with nntpd.conf as well. I’m confident there were other header related content limiting/changing options as well but can’t cite examples at the moment.
When you get to firewalls, content inspection/manipulation has been the norm ever since the world stopped pretending that a choke router was a firewall. When I worked for the company that did the first commercial L7 firewall I was involved with installing them at ISPs in a number of countries around the turn of the century.
I’ll partly accept some admonition here and your next quote in that I was not specific enough in my previous post. You will probably recall from your work with mail servers the issue I mentioned above about limiting SMTP “From” headers, also the “AUTH before SMTP SEND” issue on the server admin side. What I failed to mention and you begin to address here is that SMTP over TLS on the client side was a later solution to a previous and more important problem of user passwords being passed in clear text by POP3/IMAP clients. IIRC the first client side use of TLS by a mail client wasn’t for sending mail but to address the cleartext password problem which frankly was much more important on a customer security scale than obfuscation of who the customer is sending mail to.
Given that here the chicken did come before the egg, I’ll stick to my previous comments but accept admonition for a lack of thoroughness.
BTW I’ve used the term SMTP over TLS as opposed to STARTTLS as the second is kin of like referring to motor vehicles as IGNITIONSWITCH.
This topic was automatically closed after 5 days. New replies are no longer allowed.
