> I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.

If you look in the other threads about this, it's much more obvious. Look for brand new users. There's comparatively few in this thread, but the pattern is there: if the user's name is green, they're downplaying this.

This exploit is only ever relevant with BitLocker enabled (as a method to "bypass" BitLocker's security premise [categorically classifying this as, dare I say, a "BitLocker bypass"]).

To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.

2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.

3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.

4) Yes, this also fits the definition of downplaying.

I also disagree that the PIN bypass would be "10 times more impressive," but that's just my professional opinion.

I've seen every variant of:

1) "this is an authentication/privilege escalation bug, not a bitlocker exploit" (? what are you even trying to say)

2) "even though the attacker explicitly warns that this is capable of bypassing TPM+PIN, that isn't actually true or what he meant"

3) "we shouldn't jump to conclusions that this is a backdoor"

4) "we already knew BitLocker with just TPM isn't secure" (? except many organizations depend on it to be)

Microsoft goes beyond that: they've managed to have a critical vulnerability in almost every authentication product they have ever created. It's exceptional.

I'm reminded of Storm-0558 [1] where a stolen signing key was able to forge authentication tokens for any MSA / Azure AD / Government AD user. They downplayed the severity. Just imagine if that level of access was used to pull a Stryker on a nation-wide scale. That is an economic disaster waiting to happen.

[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...

> "To me, the bulk of Tailscale's overhead comes from the fact that the dataplane is running between user and kernel space."

Yes and no, it's more complicated. DPDK is the industry standard library for fast packet processing, and it is in entirely user space. The Linux kernel netstack is just not very fast.

Service Provider ISPs cannot use Mikrotik - It is impossible. RouterOS supports none of the features required for a service provider. VRFs are even still unsupported in HW [1]. I am confused why this is even a discussion as anyone with experience working at an ISP/SP would come to the same conclusion.

[1] https://help.mikrotik.com/docs/spaces/ROS/pages/62390319/L3+...

Take a look at AMS-IX, one of the largest internet exchanges: https://bgp.tools/ixp/AMS-IX

21/1020 (2%) of all peers are Mikrotik. 15 (1.4%) of those are >=1000mbps. 7 (0.6%) of those are 10gbps. None are larger than 10gbps.

Tailscale however, although it derives from WireGuard libraries and the protocol, is really not WireGuard at all- so comparing it is a bit apples to oranges. With that said, it is still entirely userspace and its performance is less than stellar.

Though there are definitely use cases where it is needed, and it is way easier to implement earlier than later.

With that said, I love Mikrotik for what it is: it is very approachable and it fills a niche. I believe it has added a lot of value to the industry and I'm excited to see their products mature.