[rendx]

I can't see how this is a "0day".

This post talks about how you can identify a running Tor when you connect to the (operator-assigned, public) relay port. You can only "see" these TLS certificate details when you are connecting to the relay yourself. This means this does not allow network operators to detect traffic going to Tor nodes, or in-between nodes, let alone identify users or deanonymize anyone: To external observers, such traffic looks like typical browser TLS traffic.

So, what this does is allow you to identify Tor nodes, which is by definition not a problem for all Tor relays except bridges, which should not be as easily discoverable by a network scan. The problem has been known before, and work as been done so you can now run a Tor bridge without this problem. As this problem has been publicly discussed and outlined in the very first design documents, it cannot be called a "0day", even if it was more problematic than it actually is.

Tor came up with the concept of "pluggable transports" to address this very successfully, which allows clients and entry bridges to basically make Tor traffic look like anything you want.

[MrStonedOne]

Security is in the eye of the application. Unauthenticated editing isn't an exploit on Wikipedia but it would be on the CDC's website

In this case the fact that a user is using tor is considered protected information meaning any exposure of that is in fact a info leak vulnerability

[rendx]

The "fact that a user is using Tor" is not discussed in the post. There is zero connection between how Tor nodes generate their TLS certificates and whether or not you can detect that a user is using Tor. All you can do with this information (which is not a secret but a well-discussed tradeoff with no better option) is to identify Tor relays, which are already public.

[modzu]

tor will never be secure if you're running js enabled. trying to achiveve that is way out of scope of the project:

https://support.torproject.org/tbb/tbb-34/