[Android Software/Hacking General [Developers Only]] Illidan Pornrage:
You completely mix up the semantic restraints.

You are admin of keweon. You can do whatever you want with it.

It doesnt matter from where you can do that or via which kind of access.

Nobody but you or your infrastructure hoster can see that.

Users cant verify that.

A DNS is a DNS. It serves IPs.

A DNS is not a proxy.

A DNS can lie and send whatever IP it likes.

A Proxy is something that accepts traffic somehow and forwards it.

DNS doesnt do that.

DNS can serve the IP of another webserver that it declares correct for "importantdomain.whatever"

Keweon sends blocked hosts to another IP that is not the original one.

There is a webserver or TLSonly service.

That webserver can accept the connection and serve the user with a fake site to harvest logins.

If that fake site proxies requests to the original site and just sniffs traffic for better consistency and less setup effort cant be discerned by a user.

With the root certificate installed it cant be discerned by the user if its the original site or not even with TLS.

You are able to do that.

We didnt do "pressure" you placed a bet you cant win, ignoring valid criticism

Which mod? I request that one to report in here.

How was it hard to understand my point?

Classify what as a lie? That you "arent able to mitm"?

So I am not a real security specialist? On the internet nobody knows you are a dog.

So your situation assessment is weird. You wouldnt classify it as a lie only if I were a real security specialist?

So if I am not, it is a lie? Thats semantical spaghetti.

I suppose you are just mixing german grammatics in here. But to an extent that distorts information. You can answer me in german and I will truthfully translate if necessary.

A good admin has to expect being hacked and dealing with the fallout.

Perfect hardening isnt possible.

Yes it is the whole point of admining to have the infrastructure under control.

But even if you managed to never get breached (which is impossible when popular), you could still be harvesting data for yourself and no user would be the wiser.

You are not even in control of your own narrative.

You wanted me to prove that I can MITM connections for anyone that uses my DNS and installs my root cert, nothing else in the way except pubkey pinning by some apps.

I proved that.

You say it is impossible for you to do the same.

I disproved that.

You cant prove that you cannot do MITM.

You claimed that you cant do mitm, even if you wanted.

That is a contradiction.

So here again your contradiction. You plan to do MITM.

I do not care if you block my site.

I do data collection on that site. Publicly.

That site is a demonstration that you can be mitmed via dns+rootcert.

The packet captures for the demo are public and live scrolling.

The page has a HUGE BIG FAT WARNING to not try actual logins because everyone can read them.

The logs of this arent saved to any persistent storage media and exist only in ram and are periodically wiped.

I cant prevent other people from logging the publicly accessible part.

(Well I can but I wont. I explicitly warn that this is a test machine and nobody should use it as permanent DNS for browsing.)

Because the certificate is the difference between you being able to intercept ssl connections and not.

It is not at all stupid to do that via a certificate as DNS brings you into a prime position to do exactly that. It is actually a brilliant excuse.

So secure is not the word signifying that Security was achieved?

Yes HTTPS isnt the proverbial "Eierlegende Wollmichsau" and the ends to all means of security. I have never claimed that.

But HTTPS is the most widely deployed effective system. The lowost common denominator.

Even if the WebPKI is sometimes brittle, we would all be worse off without it.

Pages cant just grab your login credentials if you dont enter them.

Password managers dont paste to different domains.

Yes there are people trying to login anyway because it looks right.

Doing a phishing blacklist is good.

Redirecting wrong urls to the right one is good as long as its only obvious typo things. This can misfire if you redirect things that arent phishing but look similar.

As in last paragraph +

Nobody can know what you do on the server. You could tell non technical people all kinds of things.

What is possible but not yet active? The phishing corrector? THe MITM?

Keweon is running on hetzner and vultr infrastructure, not on your private server.

If you did colocation where you actually had exclusive access to machines, it would be a lot more expensive than you claimed.

Yes it provides benefits for you.

What is a ZSBP? That is not a widely used abbreviation.

Explain your private abbreviations instead of bragging with them.

Why would you need TLS to redirect a phishing site?

Phishing sites are ephemeral. These domains never exist long, so they propably didnt have a chance to set strict transport security flag.

You can just CNAME them or send to a site that warns the user that he clicked an incorrect url with a link to the correct one.

You just forked BIND and replaced strings to your brand.

This whole paragraph is so imprecise and full of implications.

This does not convey any coherent meaning. Be concise and detailed.

"Es ist zusammenhangloses Geschwurbel."

So inferring meaning by context: ZSBP means the server that receives the redirected TLS connections for blocked domains and is propably an uncommon abbreviation for this thing using german words.

Again english with german semantics that doesnt work the way you think.

Please state the mentioned security reasons.

If DNS says that the domain pointing to the original "evil" host is not pointing to that anymore, to the user it isnt alive anymore. No TLS interception necessary.

What do you mean by "controlling functions"?

The certificate is a risk.

That is the third explanation of phishing correction now, that is a well known concept.

You can redirect properly even without TLS interception.

How does one double check this easily for every time one uses your DNS?

(From the perspective of an individual non technical user.)

This was a rhetoric question. I know how to cross reference IPs and check which is the issuing CA.

But non technical users propably cant.

It is a huge mental toll to compare that every time.

I could automate that but hey, with that effort I can just make my own resolver with blocklist and redirects.

I am afraid that I better understand what you are doing than you.

You do claim to prevent *list of everything the newsbla security people have declared as evil*.

Most security people actually provide solutions. You dont provide solutions, you provide a big honeypot.

Who is responsible when I lose confidential data because your service got hacked? Do you actually have remediations in place? Insurance? (We are germans afterall, we know how much that stuff is loved here.)

You actually pull this on a political correctness scheme?

You actually suggest that someone calling himself "Illidan Pornrage" cares about political correctness?

You suggest that "political correctness" would hamper my judgement even if none of these topics even touch the topics surrounding "political correctness"?

Even if true:

Having worked at Level 3 Networks does not mean anything.

Did you work at first level support? Where you admin? Hell I know.

"almost legal full access to the entire RIPE Database"

The RIPE Database is public.

So you had read access? Wew good job.

So you had write access? Almost legal? So you say Level 3 has bad security protocol because not every write access is accounted for?

I havent yet seen any public outlet of Level 3 endorse you.

This again sounds like rambling name dropping without actual backup.

How do you measure user agreement?

The default roots are overbroad thats right. But at least they are subject to multi party checks and balances that kind of work good enough.

These default certs arent responsible for data breaches.

You do not seem to understand how Web PKI works at all.

You do not seem to understand why sometimes illegitimate certs get issued.

You conflate TLS and and what webservices that use TLS do.

You conflate transport and application.

I do trust the default certificates for what they are worth:

- They do protect against adversaries with low resources.

- They dont protect against states.

- They dont protect against Google/Cloudflare/anything that runs a default CA.

- You can rely on default CAs for webshops and everything with low monetary risk.

For everything that carries more risk than I trust the default PKI with, I check signatures (of leafcerts, of gpg signed tarballs, git commits,....) explicitly if possible. Otherwise I cross reference hashes over many different networks.

Again "Rabulistik" here because you try to discredit my entire message using marginally related details.

I trust these for what they are worth as explained above.

That is not much but it is also more than nothing.

I did actually blacklist many default CAs because I will propably never use anything they sign for.

Usually CAs do not handle data connections. Conflation of technical things again.

Passive aggressive discrediting again.

You can have different levels of trust.

Default CAs are low trust for me.

They arent designed to protect against evil forces.

They are designed against Skiddies that look for low hanging fruit.

They are pretty good at preventing that.

IP Protocol is not "math", it is software.

It is also implementation dependent.

The entire point of using 0.0.0.0 is that nothing can connect to it because it is an invalid address.

Cisco surely has a huge place in the network world. But they do have their own interpretation about network handling in many facettes.

Thats why configuring cisco hardware is its own arcane science (okay thats an exaggeration but they sure use nonstandard terms) in comparison to other solutions. Cisco really is kind of market leader because of corporate stupidity.

They are also notorious for backdoors in their security products.

I havent seen a lot of months in the past years without one or more high impact vulnerabilities in cisco products of the types of hidden default credentials. This kind of backdoor that isnt even disguised.

Yeah thanks no thanks.

Relative percentages mean nothing.

You already pulled random implausible user counts out of your posterior.

I actually want to warn people to not use obvious scams or honeypots.

Nobody claimed that you do actually abuse your power.

But you are constructing the prerequisites to it and dont look competent.

You tell a lot of incoherent tech namedropping with a seeming lack of understanding for the actual concepts (or language [but in german you talk the same kind of garbage.])

You use a lot of excuses.

Nobody needs to prove anything to you.

I want to prove that using a setup like yours enables the admin to do evil things without any accountability.

I did that.

You still have not fulfilled your part of the bet.

A bet you started yourself.

Check the test server at http://https-interception.info.tm

(Other people: For questions about how to use it PM me)

I offered to work with you to make the flaw I pointed out go away.

A seasoned sysadmin should actually know how to mitigate that flaw.

It took me 20 minutes to find a less risky way of doing the TLS termination.

You as mighty industry admin certainly would have learned how to come up with a solution a lot faster than a mere peasant like me.