If the vulnerability turns out to be that there is some high value deployment out there that generates self-signed certificates on the fly and just blindly puts the SNI hostname in the cert's SAN ext, I might have to cry
-
-
- End of conversation
New conversation -
-
-
Oof shit, I was using that. (Not the lib, but the protocol)
-
You and the rest of the internet :)
-
I was under the impression the other protocols were more common. I wrote against sni because it's wired into my client hello based load balancer/router.
-
I drop to splice after the negotiation, that's going to be a pain to replicate, might be easier to rearchitect
-
Dan Anderson and I wrote and usehttps://godoc.org/github.com/google/tcpproxy#Proxy.AddSNIMatchRoute …
-
Ya, same principle, though my routing is strict, I dead-drop certs into a place where stateless services can recover them. That fact is saving me right now, as I have 60+ days to recover if needed, even if the lights go out everywhere.
End of conversation
New conversation -
-
-
Is the package going to get fixed anytime soon?
-
It's not a bug in the package so "fixed" isn't quite right. Sounds like LE will reenable once they blacklist some hosting providers.
-
Sounds good and thanks for the clarification! I’ve read “package is now broken” and just panicked =)
End of conversation
New conversation -
-
-
Is the package only broken for people with multiple certs per IP address? Or literally anyone using Let's Encrypt?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Will live test soon, but Apache mod_md actively checks offered challenges against its implementation/open ports and will chose the proper one.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

