Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/burnett01/openssl-cookie-secret-vault

A simple vault for storing cookie secrets that can be used while generating and verifying a cookie during the DTLS handshake procedure (HelloVerifyRequest, RFC6347) (https://tools.ietf.org/html/rfc6347#section-4.2)
https://github.com/burnett01/openssl-cookie-secret-vault

cookie cookie-secret dtls dtls-handshake-procedure handshake hmac openssl rfc-6347 vault verify

Last synced: 4 months ago
JSON representation

Host: GitHub
URL: https://github.com/burnett01/openssl-cookie-secret-vault
Owner: Burnett01
License: other
Created: 2016-06-18T14:10:37.000Z (over 8 years ago)
Default Branch: master
Last Pushed: 2022-01-16T17:05:54.000Z (about 3 years ago)
Last Synced: 2024-07-30T18:58:52.677Z (6 months ago)
Topics: cookie, cookie-secret, dtls, dtls-handshake-procedure, handshake, hmac, openssl, rfc-6347, vault, verify
Language: C
Homepage:
Size: 40 KB
Stars: 8
Watchers: 1
Forks: 1
Open Issues: 0
Metadata Files:
- Readme: README.md
- License: LICENSE

Awesome Lists containing this project

README

# openssl-cookie-secret-vault

A simple vault for storing cookie secrets that can be used while generating and verifying a cookie during the DTLS handshake procedure (HelloVerifyRequest, RFC6347).

>The DTLS server SHOULD generate cookies in such a way that they can
>be verified without retaining any per-client state on the server.
>
>One technique is to have a randomly generated secret and generate
>cookies as:
>
>Cookie = HMAC(Secret, Client-IP, Client-Parameters)
>
>When the second ClientHello is received, the server can verify that
>the Cookie is valid and that the client can receive packets at the
>given IP address. In order to avoid sequence number duplication in
>case of multiple cookie exchanges, the server MUST use the record
>sequence number in the ClientHello as the record sequence number in
>its initial ServerHello. Subsequent ServerHellos will only be sent
>after the server has created state and MUST increment normally.
>
>One potential attack on this scheme is for the attacker to collect a
>number of cookies from different addresses and then reuse them to
>attack the server. The server can defend against this attack by
>changing the Secret value frequently, thus invalidating those
>cookies. If the server wishes that legitimate clients be able to
>handshake through the transition (e.g., they received a cookie with
>Secret 1 and then sent the second ClientHello after the server has
>changed to Secret 2)

RFC: https://tools.ietf.org/html/rfc6347

---

### Solution / How it works

Instead of storing cookies or using the same secret over and over again, we simply generate a specific amount of secrets, store them inside a vault and randomly pick one upon cookie-creation.
Later then we match the cookie against our secrets in that vault.

**Please note:** This solution does not reflect the most appropiate way as described in RFC 4347, where only 2 self-invalidating secrets should be used. My solution should therefor only be looked as a tool for implementing the RFC.

Thank's to Nathaniel J. Smith for clarifying this fact.

---

### Source code

Two versions namely stack and heap are included.

#### Stack version: [Here](../master/stack/)

#### Heap version: [Here](../master/heap/)

---

Requirements:

```c
#include
#include
#include
```