31–40 of 40 posts
Earlier quoted context omitted.
I don't think cryptocurrency has changed much in that regard. Before CC mining the default use for an owned box was warez servers, IRC or jump hosts.
Those are much harder to detect, especially the latter two.
Earlier quoted context omitted.
Those are much harder to detect, especially the latter two.
I'm not sure. Most crackers don't use port knocking or other obfuscation techniques, so something that shouldn't be listening on a box and a large amount of bandwidth being used is normally a good indicator.
Earlier quoted context omitted.
I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. Also, DANE relies on DNSSEC [1], which is bad. https://sockpuppet.org/blog/2015/01/15/against-dnssec
> I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. I think this would be true except my statement wasn't just about SCT but the CA system in general. Furthermore, browsers like Firefox [1] do not even have CT checks. > Also, DANE relies on DNSSEC [1], which is bad. Handshake completes this…
If that works, I call ARPcoin next.
Earlier quoted context omitted.
Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier…
A better argument against the preposterous claim that DNSSEC is "government-controlled" (and one that doesn't rely on blockchains, which are controversial in their own right), is that with DNSSEC you can choose which government (i.e. ccTLD) your domain is under, or choose one of the many generic TLDs. The web PKI, by contrast, requires users to trust a bunch of CAs, any one of which could have been compromised by a g…
Earlier quoted context omitted.
With the CT system I can monitor the CA's issuance, with DNSSEC I can't retroactively monitor if someone has changed the DANE keys and intercepted traffic.
True, DNSSEC Transparency is not as developed a technology as Certificate Transparency. There has been experimental deployment of such a system[0] but to give higher assurance there is a small addition to the DNS data that needs to be adopted first[1], which is still going through the IETF process. [0] https://twitter.com/ln4711/status/754516056878772224 [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dele…
Earlier quoted context omitted.
I'm not sure. Most crackers don't use port knocking or other obfuscation techniques, so something that shouldn't be listening on a box and a large amount of bandwidth being used is normally a good indicator.
I think there's great overlap between servers that aren't monitored and servers that are vulnerable to exploits. If you're monitoring your servers for unknown listening ports, chances are you're keeping your systems up to date. Same with bandwidth, although if bandwidth is expensive (eg. cloud providers), your accounting dept might notice.
Agreed. CC mining would be CPU on most servers, and go undetected for the same reasons. Some servers and gaming rigs would have GPUs, but not many vs CPUs.
Earlier quoted context omitted.
A better argument against the preposterous claim that DNSSEC is "government-controlled" (and one that doesn't rely on blockchains, which are controversial in their own right), is that with DNSSEC you can choose which government (i.e. ccTLD) your domain is under, or choose one of the many generic TLDs. The web PKI, by contrast, requires users to trust a bunch of CAs, any one of which could have been compromised by a g…
With DNSSEC, when it becomes instantly clear that the United States Government controls .COM, Google can simply leave .COM, and tell every Google user in the United States never to use the tainted GOOGLE.COM domain, and all the users will stop using .COM and start using the new Google domain name, because that is how things work in the real world.
In contrast, when it becomes clear that the United States Government controls multiple certificate authorities, that won't be a problem for any websites.
Earlier quoted context omitted.
True, DNSSEC Transparency is not as developed a technology as Certificate Transparency. There has been experimental deployment of such a system[0] but to give higher assurance there is a small addition to the DNS data that needs to be adopted first[1], which is still going through the IETF process. [0] https://twitter.com/ln4711/status/754516056878772224 [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dele…
Certificate Transparency, by contrast, exists.
The problem with Transparent Logs / Certificate Transparency is that they don't have the best story with regarding to recovering from compromise. We wrote an article comparing The Update Framework (TUF) to CT/TL: https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...
Your blog post is about yet another X Transparency, rather than about Certificate Transparency. Because CT works well people tried to apply the same approach to lots of other problems, most of them obviously dumb. CT is a narrow solution to a narrow problem. We had that specific problem, and so this is a very good solution. You almost certainly don't have that problem, our solution can't help you, we aren't sorry abo…
Earlier quoted context omitted.
Certificate Transparency, by contrast, exists.
There was a time when Certificate Transparency didn't exist, and people didn't propose throwing away the web PKI because of that.