calpolysec / seclab-bot Goto Github PK

Using 32 bits for our timestamp may break our code a couple decades from now, if not properly planned for.

See: Year 2038 problem.

If yes, and we've pinned correctly, close this, else, let's figure out what we need to fix.

So that we can Let's Encrypt without breaking everything.

Update seclab bot to properly display lab status when remote is set to fire. #18 fixes the source. Next step is updating the raspberry pi that runs seclab-bot.

Let's make a "client-init" request that connects via SSL and receives a new PSK.

Format:

1 byte 0xAA
8 bytes timestamp
HMAC keyed with old PSK

Thoughts?

It would be useful to have some sort of indicator on the bot (e.g. LED on an Arduino) that confirms the lab status has been changed successfully. This will verify that the bot is on, button press was registered, the server was up and reachable, the HMAC was accepted, and the actual status indicator (e.g. a badge on the homepage) was properly updated.

If we want to implement this, some sort of response message would need to be specified, potentially HMAC signed (so an attacker can't MITM you, block all your "open" messages, and respond to them saying they were successful so no one notices).

An example might be to respond with the same 5-byte message, followed by some kind of status byte (0xFF for "all good", 0x00 for errors such as a bad hash, problem updating status, etc.).

Another possibility would be either an "all good" message as a response, and simply closing the connection when there's an error of any kind.

@nickago perhaps?

SSL_CIPHER_LIST should be set to only the best ciphers in TLS 1.3.

Additionally, the ssl socket is a TLS 1.2 connection. It should be 1.3 ASAP.

We need a spec for the format of lap open/close messages, so that a listener can be built to consume those messages.

For instance, an HTTPS request with an Authorization header, or a binary protocol over TCP with some kind of HMAC signing.

Write tests? At least for cert verifications

I'm like somewhat sure it works.

Here's an attack vector - I watch all the (unencrypted) message traffic until I see one close message and one open message. Each of these messages include a valid hmac. So if the server isn't validating timestamps, I can replay either of these two messages and control the open status without ever knowing the key.

Note that expiring messages by age won't always solve this issue. Suppose I close the lab by accident, then realize my mistake and open it again. If the second message is sent before the first message expires, an attacker could replay the "close" message and override the "open" message.

The client should send HMAC'd keep-alive pings (with no user interaction) to the server every 10 minutes while the lab is open, and if the server misses three keep-alives it should close the lab. Keep-alives should be responded to with an "all good" from the server so the client knows not to retry the send. This can be done in a background thread in the client which gets a message to start and stop the ping loop on open and close, respectively. A thread may seem like overkill but they're cheap if long-lived and we don't want to block the UI thread while pinging.