First we were able to determine that most of the IPs were using OpenSSL to terminate traffic. But it wasn't always impacted. In fact the really common OpenSSL users, software like nginx, Apache ... not impacted at all!
-
-
s2n uses OpenSSL's libcrypto for the underlying cryptography, and the same issue in that code /could/ have caused impact within s2n were it not for that practice. Basically this check .... https://github.com/awslabs/s2n/blob/master/tls/s2n_send.c#L94 …
Show this thread -
Of course the impact still would have been small, because of the other factors, but I'm glad we have that check! Anyway, thanks again to the issue reporters, read their paper when it comes! and thanks for Andrew and Steven from the TLS team. That's it, unless AMA.
Show this thread -
New conversation -
-
-
Does it send alerts? This was one of the reasons I argued that sending (error) alerts should be optional in TLS 1.3. (Early drafts mandated the sending of alerts.)
-
Nope! s2n never sends alerts in the error cases, it just pulls the rip-cord and closes() the connection after a uniformly randomized delay of between 10 and 30 seconds ... granular to nanoseconds.
End of conversation
New conversation -
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.