in fixing #38 I identified a potential vulnerability for a side channel attack on the server that could leak information such as when the Poet user was actually connected to the target and for how long. the vulnerability is due to the fact that the server can only support one connection at a time. if an adversary spammed the server with http requests (or sent it any data really), normally there's just an "empty reply from server" error (at least form curl) because the server rejects requests that aren't for /style.css and drops the connection on the floor, but if the poet user happened to be connected when the spam request was sent, the request will actually hang, leaking the fact that the user is connected to the client. as soon as the request goes returns, they know the poet user is done.
an additional side channel vuln that might not be possible to fix is that, if the server is running but the client is not connected, we get back "empty reply from server", but if the server is not running, we get back "connection refused".
to fix the first vuln, we need to provide the adversary with the same response as much as possible. this would require forking when we receive a connection and handling clients that way. ultimately if we're seriously considering this as a threat, there needs to be a way for the client to authenticate to the server as a legit client and not an adversary.
in fixing #38 I identified a potential vulnerability for a side channel attack on the server that could leak information such as when the Poet user was actually connected to the target and for how long. the vulnerability is due to the fact that the server can only support one connection at a time. if an adversary spammed the server with http requests (or sent it any data really), normally there's just an "empty reply from server" error (at least form curl) because the server rejects requests that aren't for
/style.cssand drops the connection on the floor, but if the poet user happened to be connected when the spam request was sent, the request will actually hang, leaking the fact that the user is connected to the client. as soon as the request goes returns, they know the poet user is done.an additional side channel vuln that might not be possible to fix is that, if the server is running but the client is not connected, we get back "empty reply from server", but if the server is not running, we get back "connection refused".
to fix the first vuln, we need to provide the adversary with the same response as much as possible. this would require forking when we receive a connection and handling clients that way. ultimately if we're seriously considering this as a threat, there needs to be a way for the client to authenticate to the server as a legit client and not an adversary.