[erlang-bugs] Bugs in ssh regnotiation

[Simon Cornish]

Hi Hans,
The queue_data patch was more a proof-of-concept. There are a number
of potential problems because I wasn't particularly careful which
events are queued, nor what the condition is (eg. StateName == kexinit
or #state.renegotiate == true or both).

I was hoping there was someone on your side who was familiar with both
the code and the protocol who could take that up. If not, I could put
some more work into it but I can't guarantee the timeframe of that.

Regarding testing, the gist is highly likely to provoke the fault but
not certain. A better test would be manipulate ssh_connection_handler
directly with the "Internal application API" - send/5, renegotiate/1,
etc. Is this allowed for the OTP test suites since it uses knowledge
of the underlying code?

/Simon

On 29 April 2015 at 06:19, Hans Nilsson R
hans.r.nilsson-at-ericsson.com |erlang-mail/gmail|
<dkzjxnucdt@REDACTED> wrote:
> Thanks for the reports and the diffs!
>
> I have put the rekey_limit diff into the nightly builds so if it is ok (which I think) it will come in next OTP release (18).
>
> Do you plan to make a pull request of the queue_data patch?
>
> /Hans
> ________________________________________
> From: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] on behalf of Simon Cornish [zl9d97p02@REDACTED]
> Sent: Tuesday, 28 April 2015 16:08
> To: erlang-bugs@REDACTED
> Subject: [erlang-bugs] Bugs in ssh regnotiation
>
> Hi,
> There are two bugs surrounding the OTP ssh implementation of key rengotiation.
>
> The first is the handling of the sent data statistics. The port stats
> are not accumulated so that once rekey_limit bytes (by default, 1GB)
> have been transmitted the connection will be rekeyed every minute, not
> after the next 1GB.
>
> The attached patch, rekey_limit.diff, provides a simple solution.
>
> In the second bug, ssh_connection_handler processes channel data
> requests from either the application or the network during
> renegotiation. This is in violation of the RFC and causes the peer to
> disconnect (observed with sshd on Solaris 10 and SLES 11).
>
> The solution is to queue those events for processing until after
> renegotiation is complete. The second attached patch is in that
> direction. It's not particularly complete hence the reason this is an
> email to erlang-bugs and not a pull request.
>
> This gist can recreate the fault fairly dependably by ensuring a
> constant flow of data.
>
> https://gist.github.com/dotsimon/ef41296db307561d8f94
>
> /Simon