Half of All Phishing Sites Now Have the Padlock
krebsonsecurity.com
krebsonsecurity.com
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 ignore email provider warnings and click any link in official sounding emails.
is this still a thing? maybe this was true back in the days when activeX was still common, but not now.
[1]: https://twitter.com/8x5clPW2/status/1046244493203263488
Chase just said "go file a ticket". In other words, "fuck off".
The tradeoff has been CNAME-ing your own subdomain to your Email Service Provider’s tracking domain, which gets you a recognizable(-ish) URL, but has historically prevented https links, or using the ESP’s tracking domain directly, which allows https but makes sketchy-looking URLs.
I’d think Let’s Encrypt would make it possible to offer https on white-labeled (CNAME’d) tracking domains. Seems like an opportunity for some enterprising ESP.
(Yes, two other options are not tracking email links, or running your own tracking. I’m going to assume these are not realistic for most marketing departments.)
Technically, Let's Encrypt is not unique here. AFAIK, most CAs allow subdomain certs (and only validate ownership of said subdomain, not the top-level domain).
Let's Encrypt just makes it scalable financially.
This is my biggest complaint about forcing users to use apps to browse a website-- it hides everything. I have no idea if any given app is actually using SSL. Oversights have happened before to Credit Karma, Fandango and others.
It was truncated in the url-bar enough to look like "www.apple.com".
The landing page, of course, was a clone of the apple.com website with a "Scan Computer" button that did the ol trick of showing you some animations before suggesting you use MacKeeper to clean up 17 viruses.
The bigger problem with this is that the paths being requested can't be monitored by intermediary devices unless you're MITMing all outbound traffic.
It becomes impossible to tell whether a domain is simply cybersquatting or if they're up to something more sinister. '/' may return a parking page, '/login' may return a phishing page, and '/?id=c4010087800cf4e5753c80c9afbe0fe5' may be a malware callback, but as far as you can tell from your network logs all traffic to httpx://www.xn--bbox-vw5a.com is simply requesting '/'.
The percentage of people using network inspection for “good” like malware/phishing filtering is much lower than the percentage using it for bad stuff like ad/cancer tracking.
For local development localhost(and 127.0.0.1, and ::1) is explicitly in the definition of "secure" used by browsers and the html specs.
Device admin pages are about the only place you could legit claim the ssl isn't viable (because it isn't). But that's a problem that needs to be solved - if you can't make a secure connection to your device, then anyone can intercept the login creds. Those various peering steps required for a lot of new devices are explicitly there to act us a side channel to establish trust (either a shared key, or certs, or whatever) as until you have a source of trust that isn't from the network, you can't trust anything you receive from the device (and the device can't trust you).
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?
a.com does not match b.a.com
Only if the certificate is *.a.com does it match b.a.com
b.a.com can have its own certificate.
A certificate can have an effectively unlimited (CAs impose an arbitrary limit like 100, nobody is sure the maximum that could work) number of names listed (the subscriber will have to achieve proof of control for all these names to get the cert).
Each name can either be an exact fully qualified domain name, and will match only that single name, or it can be a "wildcard" like *.example.com which matches any DNS name with exactly one label (a part with no dots in, essentially) where the asterisk is and the rest an exact match.
Thus, a wildcard in com, even if it could exist (it is forbidden to issue such a thing) would not match service.example.com only the exact name example.com itself.
No, you can't get <star>.com. Typically, at least for known root CAs, you have to prove ownership of your top level domain. If you own a.com, they'll ask you to either put a file on a.com/random, or register random.a.com. If you try to do so with .com, you'll likely fail (but please feel free to try and prove me wrong!).
Yes, you can get a certificate for d.c.b.a.com, I don't see any reason why not if you own a.com. Unless your specific root CA has constrains on the depth of the domains.
Edit: replaced '*' with <star>
The CAs wanted a product with a distinct UI that could drive sales of a more expensive certificate.
The browsers wanted CAs to do a better job of validation.
So the agreement was: we'll add a fancy UI for these certificates if you promise to ensure all your certificates are properly validated.
But validating the shiny organisation data in the EV cert, while useful, is not a major priority for the browsers. A machine can't do anything with it. The browsers mostly care about validating the Fully Qualified Domain Name, which is done even in DV and OV certificates just the same.
Trying to solve security problems with EV means relying on fallible humans not to make mistakes. It won't work. If it makes you feel better to try, be my guest but the browser vendors have been there, tried that.
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.
- whether the domain is substantially similar to a trusted one - recent data breaches - whether the site has been known to sell data
Those could be indicated by different, intuitive colors:
- red - high likelihood of phishing/malware - yellow - recent data breach; user intervention required, but the service itself isn't fraudulent - green - reasonable safe - green padlock - trusted
It would be awesome to get all major browser vendors on board to ship it by default, and make sure that data is never sent upstream (download a database).
To answer your question, privacy addons started selling our data. I remember Adblock Plus added "Acceptable Ads" around 2012. MyWot redesigned in 2013. Times were changing. Surely enough in 2016 they were found selling sensitive user data. It's not like this was a surprise, since it's the reason I left years ago.
These days, I'd rather reduce my browser dependency. I hope the community finds a way to filter the 1% of useful data on the internet into like a .txt file, or something that doesn't make me solve puzzles to grep.
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.
Edit: grammar
But well worth skimming through for the excellent Firefox about.config tweak "network.IDN_show_punycode".
The point of the 3 month limit is to encourage you to set up automatic renewal.
`certbot certonly -d $1 -d www.$1 --manual --preferred-challenges dns-01`
The TXT records have to be edited manually then checked with DNS Toolbox. Once visible certbot can be allowed to process.
> all the LetsEncrypt certs I manage for clients
... if this contains some technical reason why it won't work, I think that's the problem.
But I'd be more inclined to believe you if you just told me that, your clients periodically need your assistance for other things, but they weren't going to call because as every good salesperson knows, "if you don't call, they don't come"... and since they trust you already, this is a reliable door-opener that gets you back into their offices, where you get to bill for something, even if this time they didn't need anything else... it gets you valuable face time and a pretty reliable, even if only nominal, payday.
If that's not it, then tell me that's not it, but... I think that's what you're doing. (And there's nothing wrong with that.)
I'm not sure I understand how a server certificate was supposed to provide protection against an entirely unrelated server hosting a phishing website.