Commit 07465b76 authored by Paul Fiterau Brostean's avatar Paul Fiterau Brostean
Browse files

Learning results updated

parent ac666f91
......@@ -70,7 +70,8 @@ leads to 2 additional rekey states for every state permitting rekey. A considera
Figure~\ref{fig:sshserver} shows the model learned for OpenSSH, with various changes applied to improve readability. The happy flow, contoured in green, is fully explored in the model and mostly matches our earlier description of it\footnote{The only exception is in the transport layer, where unlike in our happy flow definition, the server is the first to send the \textsc{newkeys} message. This is also accepted behavior, as the protocol does not specify which side should send \textsc{newkeys} first.}. Also explored is what happens when a rekey sequence is attempted. We notice that rekey is only allowed in states of the Connection layer. Strangely, for these states, rekey is not state preserving, as the generated output on receiving a \textsc{sr\_auth}, \textsc{sr\_conn} or \textsc{kex30} changes from \textsc{unimpl} to \textsc{no\_resp}. This leads to two sub-clusters of states, one before the first rekey, the other afterward. In all other states, the first step of a rekey (\textsc{kexinit}) yields (\textsc{unimpl}), while the last step (\textsc{newkeys}) causes the system to disconnect.
We also found strange how system reacted to \textsc{sr\_conn}, request for services of the Connection layer. First of all, these services could be accessed once the user had authenticated, without the need of an explicit service request. But then, making this explicit request either lead to \textsc{unimpl}/\textsc{no\_resp}, as in the case of OpenSSH, or termination of the connection, as in the case of \textsc{BitVise}. The latter was particularly strange, as in theory, once authenticated, the service request should have become accessible to the user. Only \textsc{DropBear} seems to respond positively (\textsc{sr\_accept}) to \textsc{sr\_conn} after authentication.
We also found strange how systems reacted to \textsc{sr\_conn}, request for services of the Connection layer. These services can be accessed once the user had authenticated, without the need of an explicit service request. That in itself was not strange, because authentication messages already mention that connection services should start after authentication \footnote{This is a technical detail, the message format of authentication messages requires a field which says the service started after authentication. The only option is to start Connection layer services. }.
What was strange was that, making this explicit request either lead to \textsc{unimpl}/\textsc{no\_resp} with no state change, as in the case of OpenSSH, or termination of the connection, as in the case of \textsc{BitVise}. The latter was particularly strange, as in theory, once authenticated, the user should always have access to the service, and not be disconnected on requesting this service. Only \textsc{DropBear} seems to respond positively (\textsc{sr\_accept}) to \textsc{sr\_conn} after authentication.
We also notice the intricate authentication behavior, it seems that password authentication is the only form that allows you to authenticate after an unsuccessful attempt. Finally, of all implementations tested, only BitVise allowed multiple terminals to be requested over the same channel. As depicted in the model, OpenSSH abruptly terminates on requesting a second terminal. DropBear exhibits a similar behavior.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment