Especially for resumed handshake, it's entirely possible for an epoch=0
ClientHello to be retransmitted or arrive so late that the server is already
at epoch=1. There is no good way to detect whether it's that or a reconnect.
However:
- a late ClientHello seems more likely that client going down and then up
again in the middle of a handshake
- even if that's the case, we'll time out on that handshake soon enough
- we don't want to break handshake flows that used to work
So the safest option is to not treat that as a reconnect.
Don't depend on srv.c in config.h, but add explicit checks. This is more
in line with other options that only make sense server-side, and also it
allows to test full config minus srv.c more easily.
Use a custom function that minimally parses the message an creates a reply
without the overhead of a full SSL context.
Also fix dependencies: needs DTLS_HELLO_VERIFY for the cookie types, and let's
also depend on SRV_C as is doesn't make sense on client.
This helps in the case where an intermediate certificate is directly trusted.
In that case we want to ignore what comes after it in the chain, not only for
performance but also to avoid false negatives (eg an old root being no longer
trusted while the newer intermediate is directly trusted).
closes#220
Once the mutex is acquired, we must goto cleanup rather that return.
Since cleanup adjusts the return value, adjust that in test cases.
Also, at cleanup we don't want to overwrite 'ret', or we'll loose track of
errors.
see #257
- allow up to 12.5% security/error margin
- use larger delays
- this avoid the security/error margin being too low
The test used to fail about 1 out of 6 times on some buildbots VMs, but never
failed on the physical machines used for development.
This is not required nor recommended by the protocol, and it's a layering
violation, but it's a know flaw in the protocol that you can't detect a PSK
auth error in any other way, so it is probably the right thing to do.
closes#227
