151–160 of 322 posts
Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…
Be careful with these. I had a subdomain like this (completely unlisted) with a Google OAuth flow on it, using a development mode Google app. Somehow, the domain was discovered, and Google decided that using their OAuth flow was a phishing scam, and delisted my entire toplevel domain as a result!
What do you mean "careful with these"? With subdomains?
https://www.ghacks.net/2021/03/16/wonder-about-the-data-goog...
Earlier quoted context omitted.
What do you mean "careful with these"? With subdomains?
Yes, unlisted subdomains. I updated my post to be clearer.
I have plenty of subdomains I don’t “advertise” (tell people about online) but “unlisted” is a weird thing to call those. Also I don’t see how it would matter at all when it comes to Google auth.
My guess is they blocked it based on the subdomain name itself. I made a “steamgames” subdomain to list stream games I have extra copies of (from bundles) for friends to grab for free. Less than a day after I put it up I started getting chrome scare pages. I switched it to “games” and there have been no issues.
Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…
"Security by obscurity does not work" This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. Obscurity is a fine strategy, if you don't post your source that's good. If you post your source, that's a risk. The fact that you can't rely on that security measure is just a basic security tennet that applies to everything: don't rely on a single security measure, use redundant…
I disagree. A subdomain is not secret in any way. There are many ways in which it is transmitted unencrypted. A couple:
- DNS resolution, multiple resolvers and authoritative servers - TLS SNI - HTTP Host Header
There are many middle boxes that could perform safety checks on behalf of the client, and drop it into a list to be rescanned.
- Virus Scanners - Firewalls - Proxies
Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…
"Security by obscurity does not work" This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. Obscurity is a fine strategy, if you don't post your source that's good. If you post your source, that's a risk. The fact that you can't rely on that security measure is just a basic security tennet that applies to everything: don't rely on a single security measure, use redundant…
> Subdomains can be passwords and a well crafted subdomain should not leak, if it leaks there is a reason.
The problem with this theory is that DNS was never designed to be secret and private and even after DNS over HTTPS it's still not designed to be private for the servers. This means that getting to "well crafted" is an incredibly difficult task with hundreds of possible failure modes which need constant maintenance and attention—not only is it complicated to get right the first time, you have to reconfigure away the failure modes on every device or even on every use of the "password".
Here are just a few failure modes I can think of off the top of my head. Yes, these have mitigations, but it's a game of whack-a-mole and you really don't want to try it:
* Certificate transparency logs, as mentioned.
* A user of your "password" forgets that they didn't configure DNS over HTTPS on a new device and leaves a trail of logs through a dozen recursive DNS servers and ISPs.
* A user has DNS over HTTPS but doesn't point it at a server within your control. One foreign server having the password is better than dozens and their ISPs, but you don't have any control over that default DNS server nor how many different servers your clients will attempt to use.
* Browser history.
Just don't. Work with the grain, assume the subdomain is public and secure your site accordingly.
Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…
[flagged]
Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…
[flagged]
There are a number of companies, not just Palo Alto Networks, that perform various different scales of scans of the entire IPv4 space, some of them perform these scans multiple times per day. I setup a set of scripts to log all "uninvited activity" to a couple of my systems, from which I discovered a whole bunch of these scanner "security" companies. Personally, I treat them all as malicious. There are also services…
Earlier quoted context omitted.
$ host 209.216.230.207 207.230.216.209.in-addr.arpa domain name pointer news.ycombinator.com.
Not sure what you are trying to tell me. This isn't guaranteed to work. If you define a reverse lookup record for your domain, then that counts as published in my book.