Outgoing White House Emails Not Protected by Verification System (axios.com) 77
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.
SubjectsSuck (Score:5, Funny)
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: (Score:2)
They'd be indistinguishable.
Re:SubjectsSuck (Score:4, Insightful)
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' (Score:5, Interesting)
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: (Score:2)
Re: (Score:3, Informative)
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: (Score:2)
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: (Score:1)
Your example SPF record ends with "~all", aka SoftFail, meaning that receiving servers will still accept mail from other (unlisted) addresses and will likely not even flag it to recipients as being suspect.
If you want receiving servers to reject other mail, assuming they're even doing SPF checks, then the SPF record should end with "-all" instead.
Re: It's e-mail, it's never going to be 'secure' (Score:2)
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 pro
Re:It's e-mail, it's never going to be 'secure' (Score:5, Insightful)
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: (Score:2)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 c
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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).
I
Re: (Score:2)
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: (Score:2)
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.
Comment removed (Score:4, Interesting)
Re: (Score:2)
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: (Score:2)
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. S
Re: It's e-mail, it's never going to be 'secure' (Score:2)
There's a 50-50 chance I've been managing email systems since before you were born.
Re: (Score:2)
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: (Score:2)
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 s
Re: (Score:2)
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 ce
Re: (Score:2)
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)
misinformation from a presidential aide's account (Score:4, Insightful)
How would this be any different than normal?
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
There already is, it's the NSA, but their goals are the opposite of what you describe.
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
It's a start, but it seems that the planning phase was handled fine - they had nobody qualified to implement it.
cuts both ways (Score:1)
Or protects the white house by providing deniability for actual tirades.
reverse Poe's Law (Score:2)
".... 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: (Score:2)
Simple: The Dumb is not able to email. Genuine tirades will be on Twitter.
Re: (Score:2)
Blind relay (Score:1)
Re: (Score:2)
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: (Score:2)
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? (Score:2)
Plausible deniability? (Score:2)
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 (Score:1)
Re: (Score:2)
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 p
DMARC does not do what they think it does. (Score:1)
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.