Ok, I missed a nuance here; The server (the MITM attacker in this case) must provide a certificate in order to serve the HTTP redirection response to downgrade the connection - so I guess if you can do that then you probably wouldn’t bother downgrading to HTTP, as you can already manipulate the request/response using the (what must be working) broken SSL implementation (ie DROWN).
So I’ll concede the HSTS header doesn’t have any effect for client requests made using HTTPS, but if you’re going to not implement HSTS purely because all your URLs are hardcoded, then it feels like you’re just making excuses to avoid doing something that can only have a positive effect.
“Defence in Depth” is layered security - you don’t just choose which are the best security measures to use - you use as many as you can to suit the situation, so that if one layer is breached, another layer will hopefully provide you with enough security until you can patch.
It’s not that anyone is saying don’t do it… it’s just a nice to have rather than ‘must be fixed now’. It could be an easy fix at Monzo’s end… or it could be a PITA to do. Totally depends on their platform.
Thanks for clarifying that. I wanted to nail down the technical details of potential attacks so it was clear what the various threats were.
I’d agree with @TonyHoyle in saying it’s a “nice to have” given the limitations we’ve discussed.
Mmm, I think this is the most important point from the thread. Sure - HSTS won’t help in some cases with e.g. a REST client but it might help in the context of poorly implemented web applications and the cost for this protection is a few extra bytes on each response which can be cached with HTTP/2 anyway. It’s a no-brainer to implement when there’s developer time.
http://api.monzo.com doesn’t redirect to https, so I’m not sure how you would write an API client that didn’t have the https URL hard-coded. However, if it does redirect at some point in the future and still supports CORS then HSTS becomes more relevant.
Technically if I was going to MITM that URL, it wouldn’t need to be functional. The attacker can proxy traffic to the https endpoint to simulate a valid HTTP connection.
NB: This post seems incredibly off-topic in this thread and has nothing to do with HTTP because it wasn’t originally posted here, but it seems this thread has become a huge catch-all for any security related discussion.
monzomail.com appears to have SPF and DKIM set-up, which is great - but it would benefit from an explicit DMARC policy.
This would enable a “policy to apply to messages that fail authentication (report, quarantine, reject)” which could send a copy of all phishing messages using Monzo’s domain illegitimately to Monzo for analysis and help to ensure only genuine emails reach customer inboxes.
I think Monzo customers would be more challenging to phish by virtue of the email login system (you’d have to try and get a login link from the customer, or ask for their email creds) but this is probably worth doing regardless.
On a separate note, I can’t say I’m too keen on monzomail.com. It looks less official than monzo.com or mail.monzo.com; not to mention it’s changed through at least 3 iterations since I signed up (I’ve had emails from getmondo.co.uk, monzo.com and now monzomail.com).
NatWest have a separate online banking domain nwolb.com and it’s incredibly good at training users not to care about the domain which they authenticate on. Nationwide train users to trust emails which have their postcode in at the top (spear phishing obviously doesn’t exist) and are currently using service-nationwide.co.uk for some emails which looks sketchy AF.
Yes I agree. The domain name system has hierarchy available for solving this problem. Creating new domains for email is a poor way to go, as described above, it trains people to not bother checking the domain name.
I strongly doubt monzo own all of the monzo similar domain names, and I could register one in seconds. You own monzo.com - everyone can rely on it being yours.
