PAPAS – Redesigning ParrotTalk as an Automated Protocol Analyzer & Selector…

Hits: 861

Through the AgentMap (config), a list of supported protocolNames are specified. In construction of the SessionProtocolSelector, a ProtocolSelectorRegistration with the SessionOperation’s subclass for that protocolName is installed into the Selector. A call and answer ProtocolState is installed into the Selector’s compiled stateMap, within the expectCall and expectAnswer states. As well, the protocol is installed as a selectable protocol through protocolOffered & protocolAccepted messages for explicit ParrotTalk protocol negotiation. The result is installation of the selected protocol sessionOperations into the subjectStack accomplished through either negotiation or the initial sending of initial call/answer message headers.

The last is possible due to ASN1 structure definitions which construct the appropriate header class from the DER encoding. So the appropriate header will be distinguishable between different protocol versions. As such, within the version history of ParrotTalk headers, due to the frame specification of ParrotTalk, each protocol can be determined & will setup the stack with that protocol’s sessionOperations, starting in the correct initial state to reprocess the frame that resulted in that protocol’s installation, so the rendezvous will proceed, for that version of the protocol.

Thought has been given to the other area of discrimination, which is the FrameBuffer. That includes an assumption about frame specification and is currently only supporting ParrotTalk frames. With full implementations of SSL (TLS v1.2) [1] and SSH [2], with its required Telnet [3] package, initially ported onto ParrotTalk’s [4] framework, in Squeak’s Cryptography project, a FrameAnalyzer may be able to be defined to automatically detect frame specifications for a given incoming frame and choose non-ParrotTalk frames and the associated SessionOperations.

From the package comment for ParrotTalk-rww.31 :::

I ported initial attempts to subclass an important stateMachine, from
each of SSL and SSH, to be rooted at ParrotTalk’s SessionOperations.
More work is needed, including defining active frameSpecifications that can detect appropriate frames for these new Protocols, in a new
FrameAnalyzer, to be used by the new SessionProtocolSelector. I
renamed the ParrotTalk SessionOperations. The current hierarchy of
SessionOperations as follows:

SessionOperations…
– ParrotTalkSessionOperations_v3_8
– ParrotTalkSessionOperations_v3_7
– ParrotTalkSessionOperations_v3_6
– SSLHandshakeStateMachine
– SSHTransportHandshakeStateMachine

and hence distinguish Protocol SessionOperations subclasses :::

  • ParrotTalkSessionOperations_v3_8
  • ParrotTalkSessionOperations_v3_7
  • ParrotTalkSessionOperations_v3_6
  • SSL_TLS_1_2
  • SSL_TLS_v1_3
  • SSH
  • Signal

That would be a powerful capability.

In thinking further about the current state of affairs, it would be a powerful addition to define a SignalSessionOperations and detect&read Signal [5] frames/messages.

For Squeak/Pharo…

[1] SSL – http://www.squeaksource.com/Cryptography/SSL-rww.20.mcz
[2] SSH – http://www.squeaksource.com/Cryptography/SSH-rww.13.mcz
[3] Telnet – http://www.squeaksource.com/Cryptography/Telnet-rww.105.mcz
[4] ParrotTalk – http://www.squeaksource.com/Cryptography/ParrotTalk-rww.31.mcz
[5] libsignal-protocol-java – https://github.com/signalapp/libsignal-protocol-java

Browse Oceanside or Cryptography, for latest developments.

Leave a Reply

Your email address will not be published. Required fields are marked *