21–30 of 74 posts
Earlier quoted context omitted.
> even HTTPS leaks the requested URL It does not. In the olden days the host name was leaked, but with SNI even that is gone. Anything past the first "/" is never and was never sent in plaintext in HTTPS
Most public web sites leak information about page accesses to anyone who can count bytes.
> Services on unexpected ports are more likely to be insecure than services on assigned ports. That line really surprised me. I'd have thought that somebody who knows enough to move a frequently targeted service to a different port to avoid low effort attacks/scans would know enough to use other protections, then I saw it was partly because of cheap IoT devices that have zero issues violating specifications out of th…
It doesn't surprise me _at all_. Security through obscurity doesn't work, if you have real security you wouldn't bother using another port because there's no (security) reason to do so. If someone is trying to use ports as their security measure then it's because they don't actually know how to make their API secure properly.
Strong disagree with that. If you do something as simple as moving SSH to a different port, the number of drive-by attacks will drop enormously. Raises the signal to noise of all connection attempts in the logs.
Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless. Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletp…
Agree, what I dislike most about https is the way it effectively has a forced expiry date. Have you ever stumbled across someones old abandoned university project page, a blast from the past with all sorts of interesting information. hopes and dreams from a bygone era. not gonna happen with https.
> Services on unexpected ports are more likely to be insecure than services on assigned ports. That line really surprised me. I'd have thought that somebody who knows enough to move a frequently targeted service to a different port to avoid low effort attacks/scans would know enough to use other protections, then I saw it was partly because of cheap IoT devices that have zero issues violating specifications out of th…
The bulk of these would just be embedded devices running multiple API services, like port 7547 highlighted in the article is your typical TR-069 service running on most consumer internet routers
I would argue most non-API/non embedded devices web applications would still be running on 80 and 443
Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless. Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletp…
If you're talking about certificate error pages, then yeah there's room for improvement. Not every site needs the same level of warning there. But caution makes sense as a default. Something went wrong.
Honestly I kind of dislike the security through scaring the userbase tactic. HTTPS is wonderful, but it is not needed in all situations. For your run of the mill static site, its essentially pointless. Sure, if you are dealing with money or customer data, use all the crypto you want. But I think people should respect tools should be applied where they are actually needed, not just arbitrarily. You dont need a bulletp…
What scaring? Chrome shows a gray "not secure" and firefox has a crossed out padlock. That seems understated to me. If you're talking about certificate error pages, then yeah there's room for improvement. Not every site needs the same level of warning there. But caution makes sense as a default. Something went wrong.
Earlier quoted context omitted.
What scaring? Chrome shows a gray "not secure" and firefox has a crossed out padlock. That seems understated to me. If you're talking about certificate error pages, then yeah there's room for improvement. Not every site needs the same level of warning there. But caution makes sense as a default. Something went wrong.
My Chrome does not allow me to visit HTTP page. Yours will do the same soon.
I just tried http://example.com/ in chrome canary and it's the same.
Edit: Okay, I found the "Always use secure connections" setting, but that has been around for a while. And it doesn't actually stop me, it asks.
Also downloads are or will be blocked on http but that's not too bad of an idea.
Earlier quoted context omitted.
Agree, what I dislike most about https is the way it effectively has a forced expiry date. Have you ever stumbled across someones old abandoned university project page, a blast from the past with all sorts of interesting information. hopes and dreams from a bygone era. not gonna happen with https.
Those pages are abandoned, but the servers aren't abandoned. The same person keeping it running should be able to update certs just fine.