Hacker News Reader

Comment by asimpletune | Hacker News Reader

This is terrifying. Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass… it doesn’t feel good to imagine their reaction.

This is still limited in what you can do though. For example you can’t use this to forge messages from other people’s Gmail accounts.

> When the message is forwarded, the original DKIM signature usually remains untouched as long as the email content and headers covered by the signature are not modified

It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature. They should just change how their signing is configured, and email clients should warn when the email is legit but the intended recipient could have been changed.

View on HN

> Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass

Imagine explaining to a relative what dkim/dmarc/spf is!

These are all behind the scenes technology that users should not be aware of.

Honestly this attack is not as scary as it sounds. The article is being misleading to sell their product.

> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature.

I dont think that would really matter. How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.

> How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.

Perhaps if the address at which you received the email does not match any which are covered by the DKIM signature then your client could warn you about the potential for foul play?

I don't think that would be a good idea. The false positive rate would be too high and i don't think forging the to header is useful enough to phishing to make it worth it.

>These are all behind the scenes technology that users should not be aware of.

Every time I hear this statement, alarm bells ring in my head. We aren't immortal. None of us is omniscient, and unfortunately the bad actors we're trying to protect against obviously don't give two shits about getting their hands dirty. We can't just hide all implementation details from users, especially when today's users may of necessity become tomorrow's admins.

> always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass

This was the default state of email for a long time, and is still the level of caution some people apply to email: never trust `From`.

I've blown people's minds by spoofing "From" before. It's amazing the completely unwarranted level of trust people have in things. I tell people it's no different from me typing up a letter and putting "love from Mum" at the bottom.

I blame shiny email clients like Outhouse etc. It's really dangerous to make something look like a better system than it is. If email were still viewed as plain text I don't think it would be seen the same.

Note, you can't forge the from header if DMARC is turned on. The From header was not forged in the article afaict.

It doesnt really matter because email clients usually dont even show the email part of the from header.

> email clients usually dont even show the email part of the from header.

Good email clients should, though.

Isn't it also SPF's role to check that the From domain is allowed for the sender IP ?

No. (If you mean the from header)

SPF (without dmarc) validates the envelope from, not the from header.

When DMARC is present, it changes this to be the normal from header (dmarc requires one of either spf or dkim to match the from header. So if dkim matches then spf doesn't have to)

> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature

It is, which is why they had to preserve it. The screenshot of delivery under the reproduction section shows the original To: address. This isn't the address that it is delivered to; you can deliver an email to any address with any other To: field in it.

My advice here is pretty standard: If you get an email that requires an action, go to the website directly. Don't click any links.

It adds friction, but does solve the problem. For banking/systems, I'd much rather have the friction.

> This is terrifying. Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass… it doesn’t feel good to imagine their reaction.

I mean, this has been policy at my work for a while now, and in general is good practice for anything on the internet. We deal with a lot of small businesses or just individual contractors, a good chunk still don't even use MFA, or if they do are still falling victim to token theft. We then get malicious emails from these compromised accounts, so to our users - they pass all checks and look legitimate, after all it appears to be actually from our customers.

So yeah it's fair to treat everything with suspicion, especially email.

Reply on news.ycombinator.com