security@golang.org

(Go Security Policy).

CC @FiloSottile

I went through the security@golang.org archives and I did not find any reports matching this issue. Please follow the Security Policy and use that contact to report it. If you did contact that channel, please resend the report to me directly, my email is filippo@golang.org.

I suspect that it will happen, but once you've been able to confirm receipt of the PoC can you add a comment here @FiloSottile? A few people in the community are 👀 on this issue now and I'm sure we'd like to know that progress is being made, even if details are not shared until public disclosure.

The report pointed to the same issue and PoC of #22543, which was fixed in Go 1.10 by limiting the maximum consecutive warning alerts to 5. The issue there was that there was a way to keep a connection busy forever without an application noticing. That's not the case anymore.

The observed behavior is simply the server handling 50 local threads continuously sending ClientHello messages. Of the following warning alerts only 5 are processed, at which point the server correctly closes the connection with error tls: too many warn alerts as a mitigation.

To verify that this is indeed working as intended and not affected by CVE-2016-8610, you can run the PoC with 0 as the number of alerts, and the same number of threads. That neutralizes the actual attack behavior, but still causes full CPU utilization.

If an attacker can flood ClientHello messages faster than the server can answer, there's nothing the server can do on its own.

@FiloSottile thank you so much for the summary!