CIA, FBI And Much Of US Military Aren't Doing The Most Basic Things To Encrypt Email
from the are-they-that-clueless? dept
It's no secret that FBI Director James Comey is somewhat clueless about encryption -- to the point that he doesn't even realize that stronger encryption will actually better protect Americans. But it seems to go beyond that. Apparently he's so clueless about encryption that he doesn't realize that it will help protect FBI agents. Lorenzo Franceschi-Bicchierai has a great story over at Vice Motherboard concerning key parts of our government that should understand the importance of keeping emails secret, that have failed to take the most basic steps in securing email communications. And the FBI is one of the agencies that has not done so. Ditto with the CIA. Or most branches of the military (the Air Force -- which used to run the US cybersecurity efforts -- is the one exception).Specifically, the article focuses on the use of STARTTLS, which is used to encrypt emails in transit between service providers (it's not nearly as secure as doing full end-to-end encryption of the messages like PGP -- in which case the email providers can't read your email -- but it's a key tool for at least protecting your messages in transit between those providers). Most email systems use STARTTLS these days. Gmail has offered it since it launched over a decade ago. And for STARTTLS to work, both sides of the email provider chain need to be using it. Google has published stats on how much of the emails sent via Gmail are able to be sent with STARTTLS for a little while now and it keeps going up, such that these days, it's pretty rare for email providers not to offer STARTTLS -- with 80% of outbound mail and 61% of inbound mail using it. Yet the US military, the CIA and the FBI don't use it (the NSA does, because they're no dummies about encryption). Google and others in the tech industry have been begging email providers to use STARTTLS for a while, but apparently the US government, including agencies that you'd figure would want to protect secrets, apparently still hasn't figured this out.
When Franceschi-Bicchierai asked the Defense Department why most of the military doesn't support it, he got a nonsensical answer:
In a statement emailed to Motherboard, a spokesperson for the Defense Information Systems Agency (DISA), the Pentagon’s branch that oversees email and other technologies, said the DISA's DOD Enterprise Email (DEE) does not support STARTTLS.That opening sentence of the statement from the DOD reads like someone who is just discovering the technical details of email. It's stating something that is (1) meaningless to the question and (2) stated in a manner different than any knowledgeable person would say things. Someone who deals with this stuff would just say POP3 and IMAP rather than spell them out -- and again, that's totally unrelated to the question of STARTTLS. So is the use of PKI (public key infrastructure) for emails.
“STARTTLS is an extension for the Post Office Protocol 3 and Internet Message Access protocols, which rely on username and password for system access,” the spokesperson wrote. “To remain compliant with DOD PKI policy, DEE does not support the use of username and password to grant access, and does not leverage either protocol.”
The spokesperson did not respond to several follow-ups, asking to clarify the statement. Michael Adams, an information security expert who served more than two decades in the US Special Operations Command, said that DISA’s explanation is “an unacceptable and technically inept answer,” and criticized the Pentagon for not taking security seriously and implementing STARTTLS.
“I can’t think of a single technical reason why they wouldn’t use it,” he told Motherboard in a phone interview. “It’s absurd.”
In the past, I'd mainly assumed that when the FBI spoke out against encryption, it was mainly a smokescreen to try to get more backdoors to make its own life easier. But could it actually be that the FBI (and the CIA and the DOD) don't even realize how important encryption is to protect their own information?
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: cia, cybersecurity, dod, email, encryption, fbi, security, starttls
Reader Comments
Subscribe: RSS
View by: Time | Thread
"Trust us, we know how to keep you safe."
If they can't even be bothered with the most basic security on their own communications, the idea that companies should trust them to help secure their systems is a bad joke. If anything, government 'assistance' would likely take any security previously in place and shoot it full of so many holes as to be non-existent.
[ link to this | view in chronology ]
Re: "Trust us, we know how to keep you safe."
That does seem to be the agenda of some parts of the government. As long as they can gather whatever information they want whenever they want, they are happy, and do not care who else can gather the data; at least so long as it is not Joe public.
[ link to this | view in chronology ]
So who's in position to tap and exploit it? Even if have, takes huge correlation.
You're worrying more over emails than the everyday actuality of Israeli-owned (and therefore, the state of Israel) Amdocs having nearly all American phone meta-data and thereby able to find high-value targets:
https://en.wikipedia.org/wiki/Amdocs
[ link to this | view in chronology ]
on the other side though, those same security forces dont expect anyone to spy on them, because of the definite punishments dished out if anyone is caught.
in other words, they can do what the hell they like, but think no one else should!
[ link to this | view in chronology ]
STARTTLS is not the only encryption solution
While IMAP uses TCP port 143 for plaintext and STARTTLS connections, IMAPS runs on TCP port 993 and *only* accepts encrypted connections.
I'm no government apologist, but railing against the lack of STARTTLLS is a little much.
[ link to this | view in chronology ]
Re: STARTTLS is not the only encryption solution
[ link to this | view in chronology ]
Re: Re: STARTTLS is not the only encryption solution
Using IMAPS (port 993), POP3S (port 995) and SMTPS (port 465) is just not that hard given any of the usual MTAs, e.g., sendmail, postfix, etc. and any of the usual packages like UW-IMAP (or Panda IMAP), Dovecot, etc. So even if your internal mail system doesn't support these -- because the codebase hasn't been updated since 1992 -- you can easily set up gateways that sit between that internal mail system and the outside world and implement these. ("perdition" is one choice of many for IMAPS and POP3S gatewaying.)
[ link to this | view in chronology ]
In the wrong way of thinking
They protect the Government! If a situation came up where the federal government had to take a hit or a whole lot of citizens were going to die... we all know what will happen?
That is right, a whole lot of citizens are going to die. Yes the government has a vested interest in keep citizens alive, but that is only in the context that a functional population keeps the infrastructure funded but beyond that, they believe they need to rule over us and protect us even from ourselves, so these guys no longer even live in the same world we do.
They see threats day in and day out so they no longer have the benefit of being objective. They jump like scared little girls every time a spider pops its head our or a mouse squeaks! The invention of the DHS & TSA are nothing more than icing on the cake of the CIA/NSA. With the revelations brought by Snowden... enough said.
[ link to this | view in chronology ]
Maybe, just maybe she was smarter than the rest of them.
[ link to this | view in chronology ]
Re:
I would think if that was why, it would have been among the three or four explanations she's offered for the situation.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Is there any evidence her system was better?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Spin this one, Antidirt!
[ link to this | view in chronology ]
Leading by Example?
Do not use encryption on your emails. Only the terrorists would do that. If you're not doing anything wrong, you've got nothing to hide.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Encryption not necessary on governmental e-mail
[ link to this | view in chronology ]
I give up; let trump become president.
[ link to this | view in chronology ]
And this is how the US got involved in WWI
Obviously, the Germans learned their lesson by WWII. (Despite some sharp Pollacks getting one up on them.)
So not only can our agents security, they cant history either.
Do you think they'll need a similar embarrassment before they start taking encryption seriously?
[ link to this | view in chronology ]
Incompetency
DHS (a boondoggle in itself) was born out of the fact that upper officials didn't believe field agents reports that eventually proved true on 9/11. One of many examples where senior government officials were not able to make competent decisions.
[ link to this | view in chronology ]
Terrorism equals thinking for yourself when it comes to fascists.
[ link to this | view in chronology ]
The only sense I can make of the Defense Information Systems Agency spokesperson's statement. Is that the Defense Information Systems Agency seems to be using completely different email technology than the rest of the world?
If they're not using POP3 or IMAP. That only leaves Microsoft Exchange email Server using the MAPI protocol.
Email protocols: POP, IMAP and MAPI. What are these?
http://it.med.miami.edu/x1111.xml
[ link to this | view in chronology ]
Just because they don't use STARTTLS doesn't mean they are not encrypted.
STARTTLS is used when the client initially establishes an insecure, un-encrypted connection to the mail server. The mail server then says "hey, let's encrypt this session with TLS, here's my public key" and whatnot, they then negotiate .
HOWEVER, if are already you do the initial connection using TLS at the network/protocol layer (TLS is more commonly called SSL - as SSL was revised and enhanced and newer versions release, it's name changed from SSL to TLS. Therefore strictly speaking SSL refers to SSL 1.0 to 3.0. SSL 3+ was renamed TLS, and TLS1.0 is basically SSL 4.0, etc)
[ link to this | view in chronology ]
Re:
If you are already encrypted using TLS/SSL before you perform application level connection between the client software and the mail server software i.e. at the protocal or transport layer, VPN or already SSL'ed, they you don't need STARTTLS.
And that's what having a PKI infrastructure usually means. Users usually have their own user certificate, the server has a server certificate, and encryption is performed by the PKI system in place instead of relying on the mail server and mail client to support STARTTLS. Basically, think of it as using a propriety encryption layer instead of using the open standard STARTTLS which is only necessary if you don't have your own encryption layer on top already.
Take where I work for example. We have multiple offices around the country and the world. We don't use STARTTLS between our internal email clients and our internal mail server because we use a thick client on our desktop that has encryption built-in (outside STARTTLS) for the mail server from the same vendor. Sure, our 'thick clients' do support STARTTLS, but it only uses that if I decide to point my client at a 3rd-part, non-vendor supplied mail server.
And our mail servers when connecting to the mail servers of our offices and partners also doesn't use STARTTLS or SSL/TLS for encryption. Nor does out client encrypt our emails. Why? Because out network infrastructure has VPN routers with pre-shared-keys in it, as does every one of our offices and our partners. When we communicate bewteen any of these, the core routers do NOT forward the connections to the border routers, they forward the connection to the VPN routers that establish a VPN - an encrypted pipe - with our partner/office, and send the data down that already encrypted pipe, therefore no STARTTLS, no SSL, no TLS, no email encryption is necessary as the LINK is encrypted between the locations and if encryption fails, the route to the office/partner fails until the VPN is re-established.
Therefore the users of the mail client or browser connecting to a partner do not have to take any steps, don't even have to know about, encryption. The software doesn't have to implement, support or even know about encryption. It's all handled transparently for them at the network infrastructure layer.
Of course, this is a 2-edged sword. Since the users are "dumb users" who have no idea, if they have to send sensitive information (which is against policy, and could be a sackable offense) to someone who isn't in a branch office or partner organisation, they have no idea about encryption/message security. Hell, there have been cases where someone has sent sensitive email to a partner, but also put a non-partner (I think it also cc'ed to a home account of someone who was on already getting the email via their work email) on the cc list, the emails to the partners all went down the encrypted pipes, but the email to fred@someisp.com went through normal, unencrypted public internet. The user to this day still doesn't understand what they did wrong, because all they did was add someone to the cc list.
But this is the type of system these agencies ARE using. They don't need to 'do' STARTTLS because they don't need the application software to set up their encryption because they are already encrypted before the application software is even aware that someone wants to connect to it. Probably with a much higher level of encryption in their encryption layer than that used by STARTTLS. Hell, STARTTLS is vulnerable to man-in-the-middle (MIM/MITM) attacks since it has to negotiate key exchanges and so on. With network layer security this is not possible if using pre-shared-keys. This also has the added side-benefit of simplifying software that doesn't have to have encryption built into the software (the network takes care of that) and when encryption changes, the entire network's encryption can be updated by patching some vendor-specific hardware devices and a single client piece of software on the PC that enables connection to the encrypted network, rather than the dozens, hundreds of individual different pieces of software that have to be patched because they have encryption builtin...
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
STARTTLS is a fallback, something you use when you don't support proper link encryption. If you support SMTPS or IMAPS (which is equivalent to HTTPS), you don't need STARTTLS.
STARTTLS is at the bottom of the food chain for encryption of email connections. I very much doubt we are talking about them not using encryption, they just don't use STARTTLS. STARTTLS is what you use when you (as an admin) coulnd't be FireTrucked to set up SMTPS/IMAPS. STARTTLS has more vulnerabilities than SMTPS/IMAPS:
[ link to this | view in chronology ]
Re: Re: Re: Re:
An SSL link with who? If you're sending an email to some random address, which I assume government employees need to do sometimes, how do you do that over SSL? Isn't the point of STARTTLS to allow the message to be passed along securely without opening an encrypted link directly to the destination server?
STARTTLS is a fallback, something you use when you don't support proper link encryption.
That doesn't seem to jibe with what I'm reading about it. If SMPTS/IMAPS is the gold standard for all situations, why did they come up with STARTTLS later?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]