Live data from Hacker News

HTTPS on Your Landing Page Is Important

troyhunt.com

301–307 of 307 posts

Re: HTTPS on Your Landing Page Is Important

#301

That edit, about NatWest buying up the example domain to "fix" the problem, gave me real good laugh. It's interesting how simple mindedness can be so unexpectedly expected.

Well, they probably got a process for buying domains, but changing the websites architecture requires a project/task-force/whatever, which can't be set up so quickly (I'm just guessing).

Re: HTTPS on Your Landing Page Is Important

#302
post #20

Maybe someday browsers won't accept http connections by default (except for a few domaines defined for test purpose, or for some specific tld like .local) Only then we can have 100% of the web encrypted.

It's moving that direction. As it stands, any website can opt-in to this behavior for future visitors with HSTS[0], or even for first time visitors with HSTS preload[1]. And Google has been doing HSTS preload on their .google TLD for several years, and recently rolled it out to their .foo and .dev [2] TLDs [0] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [1] https://hstspreload.org/ [2] https://securi…

While I understand why HSTS makes sense I hate it and I think it comes from poorly tooling around it. Two examples:

1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list.

2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers...

For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/

Re: HTTPS on Your Landing Page Is Important

#303

Earlier quoted context omitted.

My bank actually gets this right. They very, very rarely call me, but when they do it's "Hello, am I talking to Nick Lamb?" "Yes, this is me" "OK, I'm calling from Example Bank and our confirmatory password is Melons" [not the actual bank or password] "Thanks, that checks out, what can I do for you?" This happened because I had one of those conversations you're talking about, and they were like "Aha! We have somethin…

This reminds me of something my local credit union used to do. They had something where you picked an image during signup that they would always show you during subsequent sign-ons so that you knew you were actually signing into their site.

This seems pointless because an attacker could just proxy the login back to your bank. Well, not pointless -- it raises the bar attackers have to pass -- but not a real solution. Or am I missing something?

Re: HTTPS on Your Landing Page Is Important

#304

It's 2017, and my social media account is protected by a tamper-proof phish-resistant embedded-encryption U2F microcontroller dongle, in addition to a password of virtually unlimited length and charset. Meanwhile, my bank has a max password length of 12 and I can only use an alphabet of roughly 64 characters. The future is here folks. And it sucks.

I played Eve online for a while.

My corp (guild for non-Eve players) had a better and more secure login & SSO system than either my bank or my employer. My employer has replaced their SSO system by now, but my bank is still in the 90s.

Re: HTTPS on Your Landing Page Is Important

#305
post #75

Earlier quoted context omitted.

Gives me an idea! Why not go buy up a bunch of these types of names then tell them that they look similar to their login url. THEN when they come to try to buy it they find you own it and then charge them an arm and a leg for the domain?!

That's typosquatting and it's not very ethical. It's also in a grey legal zone, you might get sued for this. So I would advise you not to do it.

To be fair, it was more of a joke but this is a really good point. I wasn't intending to do it but thank you for the warning!

Re: HTTPS on Your Landing Page Is Important

#306

Earlier quoted context omitted.

A good reason to use at the very least adblock.

And to avoid Microsoft edge. Why do I have to open Windows store for an add-on to my browser? Why can't I do it from the browser like in Mozilla Firefox or in Google Chrome?

I quite like Edge tbh. It's my main browser. Nearly a year now.

Re: HTTPS on Your Landing Page Is Important

#307
post #239

Earlier quoted context omitted.

> As long as the checkout and account management pages are https, then I don't see the big issue here. How do you arrive at the checkout and account management pages? By clicking on a link. If the whole site isn't encrypted, the link can be modified to point to false checkout and account management pages. HTTPS is not only for privacy, it's also for integrity.

How far do you go down the chain? At some point you'll hit a layer that the internet has no control over - the users machine. You can https every page on every site if you want, but if the users machine is compromised, then it's not going to help one bit. ALL https says is 'hey i'm encrypted' it doesn't PROVE to the end user that it's really who it says it is. Extended Validation was supposed to fix this, but that en…

> And for those who say 'https prevents man in the middle attacks' - no it does not. There are several network level devices that by design decrypt/review/encrypt/spoof-cert traffic to clients

These network devices (middleboxes) can do that only if the client lets it. As you just said, once the client is compromised, all bets are off. HTTPS by design protects against a compromised network, not against a compromised client.

Post reply on HN