I didn't readily find details of this particular cloaking, but I'd be skeptical of how well it can work if your adversary is more determined to snoop on you than your bridge is to camouflage itself[1]. Is obfs4 sending an SNI header for the fake SSL session? If so, an observer can connect to the named server himself and see things like a) the SNI header is faked, e.g. if there is no DNS entry for that name, b) it's not really an HTTPS server, c) it doesn't have enough discoverable content to really justify you spending hours using it every day, d) nothing else on the web links to this server. If it's not sending SNI, that's probably unusual these days too, so they know your client is non-standard.

I don't know, maybe I'm overthinking and/or considering things you don't care about as part of your threat model. I suppose some of this could be overcome by using a client certificate whitelist as a plausible reason to not serve anything to snoopers, but then you and/or the bridge are somewhat identifiable as users of an obscure SSL feature. And since the client certificate is in plain text[2], you're either trackable by a static certificate, or identifiable as something unusual if using many rotating certificates all coming from the same IP.

[1] Maybe this is weird logic, but in other words, if you are paranoid enough to be trying to obfuscate your tor usage, I don't see why you should believe this can be secure enough (unless obfs4 has addressed these issues somehow.) But maybe the point is more about web filters just smart enough to block standard tor, than about constantly evolving spies bent on unraveling your communications.

[2] https://security.stackexchange.com/questions/24577/client-ce...