Lavabit Security Misconfiguration

I always favor STARTTLS in favor of implicit. I say so since implicit TLS on SMTP (465) is deprecated.

"I reported this issue only a few hours ago, but I don’t consider this category of problem to require a delayed disclosure."

It is not an issue that anyone but a highly capable adversary could exploit. As the post says, you have to assume that all internet traffic is being collected. Thus disclosure does not harm anyone and instead allows users to protect themselves.

There is a risk of leakage of credentials and private data. Delaying disclosure does not reduce that risk in this situation; if anything it increases the risk. People delay disclosure when disclosing early would increase risk. That is not the case here.

> If it's a security issue, then responsible disclosure.

No. Immediate disclosure when it is the right thing to do. Delayed disclosure when it is the right thing to do.

> If it's not a security issue, then it's not 'Security'. Right?

Yes. If an issue is not a security issue, then it is not a security issue.

> If it's a security issue, then responsible disclosure.

See: https://adamcaudill.com/2015/11/19/responsible-disclosure-is...

Responsible Disclosure is not necessarily the One True Way(tm). It's certainly debatable.

If I were a security researcher, I'd only consider an exceedingly few exceptional cases as something I need to give someone prewarning about. Once the knowledge is known, I'm generally of the opinion that in the vast majority of cases it should be immediately published to the world - not a select few elites.

Plus from a past life I know those embargo'ed bugs rarely actually are. They get leaked all the time by the community if the price is right.

There's no such thing as "responsible disclosure".

The term is an Orwellian scheme to promote vendor interests as if they were naturally shared by researchers and users.

This is a pretty boring discussion to be having on a thread about a new vulnerability. Better that we should be talking about the impact of the finding itself.

Not the OP, but I can explain why this decision makes sense to me:

Responsible disclosure involves weighing the competing needs of a company (usually reputation hits, increased support demand) with the needs of its users (if they're doing something insecure that they think is secure, would knowing about it allow them to stop being insecure? Will an attacker who reads the disclosure be able to exploit the vulnerability more before it's fixed?).

In this case, we have many users who are using a product specifically because they desire extreme security, but due to misconfiguration are getting very little. Worse, the passwords they have been using should be considered compromised, if they are affected by this bug.

Having your password compromised isn't something that can be made better for you by a product patch in a few days or weeks. You just need to abandon the compromised password everywhere it's been used as quickly as possible.

Since responsible disclosure doesn't help users have their passwords become uncompromised, and since the affected users don't yet know their passwords are compromised, I support avoiding responsible disclosure here. It doesn't help fix the compromise situation, and every hour that users aren't changing passwords actively hurts the situation.

The decision is made easier by the fact that there are many users but only one company. You would have to derive a huge positive benefit of responsible disclosure to the company to offset even a modest negative for each user, after multiplying that negative by the number of users likely affected. I think of it as a literal utilitarian calculation.

Does that make sense?

FOLLOWUP: Thanks to all who replied. Disclosure is far more complex than the article hinted at, and the discussion here provides the context around 'Should I disclose?' that was absent from the original article.