Outgoing White House Emails Not Protected by Verification System (axios.com)

The security advocacy group Global Cyber Alliance tested the 26 email domains managed by the Executive Office of the President (EOP) and found that only one fully implements a security protocol that verifies the emails as genuinely from the White House. From a report: Of the 26 domains, 18 are not in compliance with a Department of Homeland Security directive to implement that protocol. Imagine the havoc someone could cause sending misinformation from a presidential aide's account: Such fraudulent messages could be used in phishing campaigns, to spread misinformation to careless reporters, or to embarrass White House employees by sending fake tirades under their names.

Comments

SubjectsSuck

[aardvarkjoe]

Imagine the havoc someone could cause sending misinformation from a presidential aide's account:

Imagine the havoc someone could cause sending misinformation from the President's Twitter account! ...on second thought, not much imagination required.

Re:SubjectsSuck

[gtall]

They'd be indistinguishable.

Re:SubjectsSuck

[Oswald McWeany]

They'd be indistinguishable.

Usually, Phishing e-mails can be identified by misspellings and poor grammar. In Trump's case, if an e-mail was sent with correct spelling and grammar it almost certainly wasn't from the real President.

It's e-mail, it's never going to be 'secure'

[guruevi]

There is this checklist that pops up here on Slashdot once in a while. There is no way of making e-mail secure. Yes, I could send an e-mail from obama@whitehouse.gov from my personal e-mail server and nobody would be able to prevent it. There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

Re:It's e-mail, it's never going to be 'secure'

[squiggleslash]

There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

I was under the impression pretty much everyone recognizes SPF these days.

Re:It's e-mail, it's never going to be 'secure'

[Thruen]

Your front door isn't truly secure, it can be knocked down. Does that mean you shouldn't lock it? Does that mean the President shouldn't lock his doors?

Personally, I feel like even if a problem can't be entirely avoided, it makes sense to put a reasonable amount of effort into reducing the chances of that problem occurring. Seems like most folks agree considering how often people lock their doors. I suspect you agree, too, but decided to throw logic out the window on this one for whatever reason. The fact that one of these domains was better protected tells us more could've been done to protect the others, and I don't think it's unreasonable to ask an administration that has stressed the importance of email security as much as this one has to put that little bit of effort in.

Re:It's e-mail, it's never going to be 'secure'

[blane.bramble]

Not strictly true - that SPF records says to treat a failed result as suspicious, not to reject it, so email servers will accept it and usually treat it as having a higher spam rating.

Re:It's e-mail, it's never going to be 'secure'

[mysidia]

but all parties have to agree on the method of verification

That's why we have standards, and the applicable standard is called DMARC, which involves implementing a SPF policy in the DNS zone, DKIM message signing, and a DKIM policy in the DNS zone, and signing the DNS zone using DNSSEC.

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

E-mail could use TLS between client/server and between relay servers. Authentication could use FIDO U2F for client-to-server. We could also rework the FIDO standard--and the hardware devices which use them--to include OpenPGP signing and encryption, and add Curve25519 to FIDO U2F and OpenPGP as the key exchange (i.e. your PGP key is Curve25519, instead of RSA).

The mail client would send each message to the FIDO device for signing using SHA-256 (if not encrypted) or a key-hashed message authentication code based on SHA-256 (if encrypted). Encryption would also occur to the target parties via the FIDO device, using AES-256 (the pubic key for each party encrypts a separate copy of this key) and CFB mode for the message (semi-parallelizable).

This scheme would actually never reveal the session key to any party using the FIDO/OpenPGP device. The sender encrypts the message to self, generating the session key on the FIDO device; however, the sender's private key is on the FIDO device, so the sender can't read the session key. Thus, to read the message, the sender must send the message down to the FIDO device for decryption. The device thus would decrypt the session key, read the message, validate the HMAC signature, and return the plaintext of the message and the validation results.

It is also possible to send the message down with "Also Encrypt To", so the FIDO/OpenPGP device would decrypt the session key, make an encrypted copy with the public key of an additional recipient, re-HMAC the whole thing, and send the result back. Note that because the session keys cannot be part of the symmetric-encrypted body or the signature (the hash is generated by signing, thus its value is unknown during signing), you can actually add recipients by just returning the new block of HMACs and encrypted session keys (you'll generate these encrypted keys before the hash, and they're independent of the hash, so you can include them in the signature), and not return a re-encrypted message.

This allows each user to use a hardware device paired with a mail client to authenticate themselves (private key, never leaked) and the message sent, as well as to make the message a secret to everybody but intended recipients and malware able to read the decrypted message. Note that you decrypt each message as you open it, so a bulk store of decrypted messages is not available. The security-conscious could individually encrypt each message they receive (automatically), thus avoiding a bulk store of plaintext messages in any case.

Mail server support is neither required nor useful.

Re:It's e-mail, it's never going to be 'secure'

[houghi]

If only there where some sort of General Purpose Guard or a some sort of Public Guarding Preference.

And secure does not mean secret. It means verifiable. I want to know if the email is from my bank or from a phishing site.

Re:It's e-mail, it's never going to be 'secure'

[rickb928]

Does no one remember the days of the Korean servers spoofing your mail server and sending error reports all over the globe in your server's name?

Ah, the good old days. Filling my Groupwise server volume with undeliverables in hours. The old Exchange servers just rolling over dead.

I really don't trust email I either do not expect or are new senders to me, and the White House doesn't send me anything. Neither does the IRS, except for, ready, online ID authentication and update requests. Yeah, great stuff. SSA does this also.

Really, the White House email domains are being spoofed by someone right now. It's just such a rewarding hobby for someone.

Re:It's e-mail, it's never going to be 'secure'

[Oswald McWeany]

There is this checklist that pops up here on Slashdot once in a while. There is no way of making e-mail secure. Yes, I could send an e-mail from obama@whitehouse.gov from my personal e-mail server and nobody would be able to prevent it. There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

I've long enjoyed sending e-mails to my co-workers from other people by setting the from-address to various things. It's amazing how many times they've fallen for the same joke.

Re:It's e-mail, it's never going to be 'secure'

[Sloppy]

There are ways of verifying, but all parties have to agree on the method of verification and how that is done depends on whether you're Yahoo, Microsoft or Google

Or you could, I don't know, use a standard like OpenPGP which always Just Works whether some company happens to agree or not. The only people who have to agree are the users.

If the users don't agree to have email be secure, then it can't be secure. If they want it to be secure, then it's easy.

This is hard to implement to society at large (because society's "users" never agree to do anything) but within an organization, it's no problem as long as whoever's in charge wants it. "Bob, you didn't sign your email, yet again? Ok, you're fired. I'm sure we can find someone else who is willing to follow orders."

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

Should the President have an unguarded wooden interior door as an entrance to the White House? You just don't use e-mail for highly secure communications. If you receive an e-mail, you should distrust it.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

But that doesn't prevent me from sending an unsigned message through a relay and unless the user has the technical chops to distinguish the two, it doesn't matter much.

Re:It's e-mail, it's never going to be 'secure'

[hey!]

There are absolutely ways of making e-mail safe. The technology has existed for decades and has been available in some email systems.

But to run a system like that, you've got to have administrators who can manage things like cryptographic trust delegation, and not everyone is willing to pay for that kind of expertise "just for email".

Now I think that if everybody *did*, it would be a net win. There'd be no more phishing. Claims of identity would have a kind of audit trail, and you could revoke trust in certificates issued by authorities that weren't up to snuff. Communications would be routinely secured, even against bad guys with physical access to your device.

But the thing is it only works if most people are willing to put up with the hassle. It's not our technology that needs upgrading, it's *us*.

Re:It's e-mail, it's never going to be 'secure'

[greenwow]

But Trump is stupid so there's no way he could use it. He can't even fix this simple damn email problem. He is incompetent and has never succeeded in a single damn thing in his life.

Re:It's e-mail, it's never going to be 'secure'

[Spazmania]

The White House could also turn the email servers off and lock them in the closet. Like DKIM this would have a negative impact on their function, but it would provide very solid guarantee on whether the received emails were legitimate.

SPF is okay in most email configurations. DMARC and DKIM are disaster areas which break common email scenarios like mailing lists.

Re:It's e-mail, it's never going to be 'secure'

[mysidia]

The White House could also turn the email servers off and lock them in the closet

That step is not an equivalent, And nope... turning off their servers would not stop 3rd party's mail servers spoofing their domains From: addresses.

DMARC and DKIM are disaster areas which break common email scenarios like mailing lists.

Most major mailing list software handle it just fine when posters' domain has implemented DMARC --- either change the From: address or preserve the headers so DKIM signature continues to match after forwarding.
The scenario you describe is not "common" anymore; in fact, it's so uncommon, that many major mail providers have
chosen to ignore it and implement DMARC strict enforcement with required DKIM upon their domains regardless.

Some legacy mailing list managers -- when used for discussion lists have issues with, But such mailing lists are
an exceedingly rare site these days; social media sites such as Facebook/Twitter, and Web-based forums have
all but completely replaced the concept of an E-mail based discussion list, so they've really gone the way of Usenet.

Also, enough of the SMTP servers on the internet support preemptiveTLS that some webmail providers are starting to provide visual security warnings to end users or refuse to deliver mail to servers that won't accept TLS connections.

Re: It's e-mail, it's never going to be 'secure'

[rickb928]

There's a 50-50 chance I've been managing email systems since before you were born.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

My point was that those schemes have been tried. The problem generally boils down to the fact that
a) Everyone needs to participate all at once for the plan to succeed
b) Everyone needs to agree on a plan to succeed in the first place
c) It doesn't account for anyone's privacy or personal security (eg. whistleblowers)

Re: It's e-mail, it's never going to be 'secure'

[oobayly]

SPF is ask well and good, but I've had to configure our server not to reject email that hard fails SPF (it gets flagged as spam) as the number of badly configured records is ridiculous.

I tried to explain to one colleague who had a call from a customer complaining that we were rejecting his emails, that he was doing the equivalent of posting us a letter with a big red warning that says "THIS LETTER IS NOT FROM ME, DO NOT OPEN".

Then I couldn't work out why I hadn't received a receipt from a supplier, same problem indirect hard fail. They were from a noreply address so the DSNs were never seen.

DKIM is also useful, if the MTA adds the header. The recipient doesn't know that DKIM should be expected, just to verify it if it's present. **I hope I'm wrong about that, so please let me know if I am**

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

Notice how the mail client above describes that the key isn't even on the device and the end users never even know the key (i.e. the mail client doesn't have the capacity to decrypt; it's on the hardware device)?

The mail client would tell you if it's signed properly. I also overbuilt the HMAC there: you'd only generate one HMAC, not one per user (because the HMAC will use the session key, and there's only one). So "HMAC", not "HMACs". My bad.

Just look for the green light on your e-mail.

Re:It's e-mail, it's never going to be 'secure'

[chihowa]

It's not a mistake. A huge number of receiving servers don't handle SPF correctly, so you need the softfail at the end to allow delivery (totally defeating the purpose, yes).

For example, every university system that I've ever been exposed to that uses Office 365 ends up with a server somewhere in the chain checking the SPF record against itself and always failing. Without the softfail, everything gets bounced.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

Okay, except that while you're setting up the infrastructure, pretty much every e-mail is going to be orange or red as will the e-mail for everybody that doesn't join the system. Eventually (in a matter of minutes-hours) you'll condition your users to ignore the thing.

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

Grey, for non-signed, no-signature-known.

Orange is for when you have no way to verify the signature (including no signature but known key), and Red when it's incorrect (e.g. different key than expected); and the e-mail client itself can fetch key and yellow you for an unknown/unsigned key. Green for soft verification (you send your public key encrypted/HMAC, they send back an encrypted/HMAC public key for themselves, and continuous exchange shows no anomalies); blue for hard verification (public CA).

Initially, everything is grey. Your friends will go green. Corporations will go blue.

The real user training problem is with the Yellow-to-Green transition and the Blue marker here. Marketing e-mails will all be Blue under the scheme I described. Non-public-CA e-mails from anyone who generates a signature will show up Yellow, and then your client can perform a likely verification to identify that the key is correct and go Green.

That only means you can trust the sender to be who you think they are.

It doesn't mean the message is safe.

In other words: all these Green or Blue e-mails can come from spammers and phishers. You can absolutely verify they're not spoofing your boss, but you can't verify that they're not trying to scam you.

I'll think up a more-complicated, less-technical scheme later, such as one that reserves the Blue level and a special decoration for long-term trust (i.e. you have a lot of conversations with a person, so they're a valid acquaintance and not just some marketing firm or 401 scammer). That goes beyond "was this message sent by the purported sender?" and into "Do I personally know and trust this person?" It's a different problem.

Re:It's e-mail, it's never going to be 'secure'

[guruevi]

Although this is a fun exercise, you have to think about the usability in security schemes. When it is more complex than red-orange-green, people will ignore it. And as I said, if you have more than 1% of grey areas, false positives or false negatives, you've conditioned your users to ignore it.

Re:It's e-mail, it's never going to be 'secure'

[bluefoxlucid]

Not really. You can have two parallel schemes and a neutral state if they're easily-differentiated and meaningful to the user (e.g. friends and people versus corporations).

The false-positive and false-negative rate is zero in signature validation. The no-information rate is non-zero.

misinformation from a presidential aide's account

[Patent Lover]

How would this be any different than normal?

cuts both ways

[Anonymous Coward]

Or protects the white house by providing deniability for actual tirades.

Re:Maybe e-mail servers need to be easier to setup

[omnichad]

you would think the IT staff at the White House of all places would be experts on security

What we really need is a true military branch dedicated to cybersecurity, and actually put them in charge of some aspects of all government IT.

reverse Poe's Law

[cellocgw]

".... send fake tirades..."
How could anyone tell them from the real thing? I mean, unless the fake ones contained, like, real data or real science.

Re:reverse Poe's Law

[gweihir]

Simple: The Dumb is not able to email. Genuine tirades will be on Twitter.

Re:reverse Poe's Law

[BrianMarshall]

The real ones end with: SAD!

Re:Maybe e-mail servers need to be easier to setup

[turp182]

There already is, it's the NSA, but their goals are the opposite of what you describe.

Blind relay

[Anonymous Coward]

Considering how fucking stupid Trump and his staff are, I wouldn't at all be surprised if the Whitehouse is running a public-facing open SMTP relay. Not like that would be a big surprise anyway, it's not like all his tweets are SPAM to start with.

Re:Blind relay

[Oswald McWeany]

Considering how fucking stupid Trump and his staff are, I wouldn't at all be surprised if the Whitehouse is running a public-facing open SMTP relay. Not like that would be a big surprise anyway, it's not like all his tweets are SPAM to start with.

That's really not down to Trump; I wouldn't expect any President, past, present, or future, to know anything about setting up an e-mail server. That's really not part of the job description of the President. That's down to the staff hired for the job, and I have no way of determining if they are smart or otherwise.

Re:Blind relay

[Dragonslicer]

Considering how fucking stupid Trump and his staff are, I wouldn't at all be surprised if the Whitehouse is running a public-facing open SMTP relay. Not like that would be a big surprise anyway, it's not like all his tweets are SPAM to start with.

I'm probably being naively optimistic, but I would hope that the White House IT staff are not political appointees.

Why wasn't that done years ago?

[tomhath]

Was the security protocol implemented during the Obama administration and then backed out?

Re:Maybe e-mail servers need to be easier to setup

[omnichad]

Sure, there's an agency. But I'm thinking actual military branch. It's starting to make more and more sense to treat cyberattacks as acts of war and having a civilian agency handle that just doesn't make sense anymore.

Plausible deniability?

[MiniMike]

If I had the unfortunate job of defending what comes out of the White House, I'd be keeping this as a backup plan. I would guess that the one secure domain is for lower level employees.

Kremlin Says Fine with Us

[LifesABeach]

What? Me worry?

DMARC does not do what they think it does.

[r2rknot]

Simply put, DMARC tells a recipient what your desired action is in the event a message fails either SPF or DKIM checks. It also does some checks on the Header and author FROM fields to see if they match.

It is up to the receiving server to do one thing or another with its received emails. If you had SPF and DKIM setup and working, its hardly a big deal to not have DMARC done correctly. But if you do not have SPF or DKIM working. DMARC will not save you at all.

Re:Maybe e-mail servers need to be easier to setup

[_Sharp'r_]

So you're saying all these domains were setup with verification before January 2017, and then Trump Administration employees changed them to no longer be setup that way? Riiight.... have you ever been involved with a government IT project?

Yeah, somehow I think you're the one smoking something.

Re:Maybe e-mail servers need to be easier to setup

[Dragonslicer]

What we really need is a true military branch dedicated to cybersecurity, and actually put them in charge of some aspects of all government IT.

It isn't a military organization, but NIST does publish standards for computer security at federal agencies.

Re:Maybe e-mail servers need to be easier to setup

[omnichad]

It's a start, but it seems that the planning phase was handled fine - they had nobody qualified to implement it.

Re:No imagination needed

[careysub]

No, this reference to the Ems Dispatch is false. Bismark intercepted and forged nothing. The Ems Dispatch was issued by Bismark's office, and described an exchange between the French Ambassador and King Wilhelm I wherein the Ambassador made an impolitic request, or demand.

A bit like the game of Chinese Whispers ("Telephone") the account of the exchange, underwent changes as it was recounted by the King to Bismark, Bismark's public dispatch about the incident, and then translated and reported by the French press, being perceived as an insult to the Ambassador in France, and leading to a really poorly considered response - the declaration of war.