51–60 of 79 posts
Noob question, if a.com gets a certificate, then b.a.com can use the same cert, right? As in the example of the fb impostor in 000webhost. So, in that same vein, can a TLD get a certificate? For example, com gets a certificate, so now anything.com has a valid certificate. Also, can I issue a cert specifically for d.c.b.a.com?
It would be slightly more credible if the response by the tech community both in comment and action to Snowden and Assange's revelations and invasive surveillance by Google, Facebook and others was not so embarrassing in inaction.
One can argue of degrees and doing both, but in this case it seems all the 'concern' gets expended in ssl leaving no energy for the far more pervasive SV surveillance culture the tech community props up without protest or even leaks.
I thought this was the point of EV certs.
No, the only point of EV certs is for CAs to make more money.
I remember that people were warned to avoid doing sensitive stuff on websites without the padlock. I don't remember any attempt to suggest that the padlock implied some sort of validity.
Most users do not understand the “necessary but not sufficient” condition. They need a “if (condition) { SAFE; } else { NOT SAFE; }” test, not an endless checklist, and the security community has continuously failed to deliver on this.
There is something disingenuous and false about those who have been pushing ssl 'vehemently' on the pretext of concern end user privacy and surveillance. It would be slightly more credible if the response by the tech community both in comment and action to Snowden and Assange's revelations and invasive surveillance by Google, Facebook and others was not so embarrassing in inaction. One can argue of degrees and doing…
Earlier quoted context omitted.
Banks and credit card companies have always been the absolute worst offenders for this, requiring people to use hidden iframes from all sorts of acmegenericsecure.net domains, and all the while professing to be the high priests of good practice with their absurd PCI racket, not to mention asking people to install random third party software just to use their websites because browsers apparently aren't good enough.
Chase likes to send emails from the not-at-all-suspicious "acctmanagement.com" domain[1]. [1]: https://twitter.com/8x5clPW2/status/1046244493203263488
The many mobile browsers which hide the address bar are training people to ignore website urls. Sites who use lots of nonsensical malware-ish url redirects (Google, Microsoft are guilty) train people to accept random urls. I guess the chief culprits are email tracking links. Everyone including banks use them. Often tracking domains have nothing in common with the destination URL. This teaches people to disable or ign…
Another thing is the login with Google/Facebook buttons that do a redirect where you enter your password. It always makes me nervous that a website could create a fake Google/Facebook login page and collect my password, and I make a point of looking at the login page extra carefully. However, I bet that the average computer user doesn't do this.
Earlier quoted context omitted.
Most users do not understand the “necessary but not sufficient” condition. They need a “if (condition) { SAFE; } else { NOT SAFE; }” test, not an endless checklist, and the security community has continuously failed to deliver on this.
I'm pretty sure that's actually impossible. If someone registers a domain and cert that's essentially a homoglyph attack against a common website, you're basically stuck with heuristics to detect it. You need a global database of targetable domains that supports similarity checking with arbitrary Unicode. You need some kind of fuzzy hash of the website to see whether the website your user is looking at is actually an…
If I were implementing it I would render the domain text and then check how significantly pixels differed from its nearest "known" domain. We used to do this with render tests where there was a bit of noise.
Don't let perfect be the enemy of good.
Earlier quoted context omitted.
Another thing is the login with Google/Facebook buttons that do a redirect where you enter your password. It always makes me nervous that a website could create a fake Google/Facebook login page and collect my password, and I make a point of looking at the login page extra carefully. However, I bet that the average computer user doesn't do this.
Sounds like you are talking about the OAuth authentication flow which is designed to use a separate window/iframe for entering credentials. This allows the application to authenticate the user without ever having access to the cleartext credentials.