Once you have managed to poison DNS, so your server is contacted instead of the right one, without HSTS you could potentially⁰ serve your responses using plain

Once you have managed to poison DNS, so your server is contacted instead of the right one, without HSTS you could potentially⁰ serve your responses using plain HTTP with no in-your-face warning to the user¹. With HSTS that initial request won't be plain HTTP if the user has been to the site before or the name is present in their browser's HSTS preload list. Chrome will default to HTTPS when given a typed URL that doesn't specify protocol these days, falling back to HTTP if that connection fails, but that doesn't protect you from plain HTTP links in other pages or stored as bookmarks. In fact this doesn't protect you as much as you think it might: IIRC this fallback to HTTP happens for any connection error including being served an invalid certificate, so a DNS-poisoning based MitM attack could still work for some users² meaning HSTS would still be useful even if all browsers used the same HTTPS-default-HTTP-fallback procedure. > I always wondered how much of a peripheral problem HSTS solves HSTS, especially with preload, solves a potentially serious but likely-to-be-rare problem. Even if the circumstances where it saves the day are rare, it is so easy to implement it is worth (IMO) the small amount of admin for that protection. -- [0] if the initial request is plain HTTP [1] some browsers will display an “insecure” flag when a page delivered by HTTP contains a form, or at least a form with a password box, but a user focusing on just what they are typing may not notice that [2] as the fallback to HTTP, if not blocked by HSTS, will happen without warning