Hide session contents from clients

[garrettr]

Sigbin currently uses Flask's default session implementation (flask.sessions.SecureSessionCookieInterface). This implementation serializes the contents of the session object and stores it in an HTTP cookie, along with a cryptographic signature. The signature prevents clients tampering with the session cookie values; however, it does not prevent them from reading the values.

Sigbin requires authorization to post a new message. It encrypts a random nonce ("challenge string") with the public key used to sign the new message, and requests decryption of the nonce as proof that the user controls the corresponding private key and so can be considered "authorized" to post an update.

Unfortunately, the random nonce is currently stored in the session. Since the session contents are available to clients, the follow attack is possible:

1. Alice posts a legitimate message to Sigbin
2. At a later date, she posts a different message to Sigbin.
3. Bob, who has retained a copy of Alice's first message (signed with her key), posts it to Sigbin.
   1. Sigbin requests decryption of a random nonce with Alice's key, which Bob does not have.
   2. However, the nonce is stored in the session and its value is accessible to Bob. Bob retrieves the value from the session and enters it into the authorization form.
   3. He entered the correct nonce, so Sigbin posts the old message, overwriting the new one, without Alice's approval or knowledge.

In many of Sigbin's proposed use cases (e.g. warrant canaries or cryptographic key transition statements), this is a catastrophic failure, because an attacker could use it to prevent updates from being posted by continually re-posting old messages with valid signatures.

If the target (Alice) uses GPG elsewhere (for example, in an email with Bob or on public mailing lists), Bob will also be able to post any of those validly signed messages to Sigbin as well. The potential security impact here is less clear, but still problematic.

[garrettr]

Two potential solutions are:

1. Use server-side sessions, where the client only receives a "session ID" that does not leak any information about the contents of the session.
2. Encrypt the sessions with a key known only to the server