Implement resilient transport channels #20
Labels
backlog
Issues that are not planned to be worked on in the near future; considered of low(er/est) priority
feature request
framework
Issues related to a framework, or a framework's logic.
It would be extremely useful if the c2 client had the capability to implement a fail-over transport mechanism. Ideally, in the event of an extremely long timeout where the client never receives a response from the server (e.g. 2 weeks), it should attempt to change over to attempt to use a different transport channel for communication.
The fail-over channel should be stored in memory in an encrypted or encoded fashion that would only ever be used in the event it is required. It may be beneficial to either encode/encrypt, or clear from memory entirely the now unusable communication channel.
The text was updated successfully, but these errors were encountered: