On Wed, Jul 4, 2018 at 1:07 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> Some background would be useful to help understand this. In the
> original Cisco protocol the ciphersuite and DTLS version were hard-
> coded, with the ciphersuite being exchanged over the TCP connection.
> The DTLS connection then "resumed" a fake session that had never
> previously existed. We added options using DTLS 1.2 and newer
> ciphersuites, following this model.
>
> Eventually we realised this was stupid, and we should just let DTLS
> negotiate a new session (including DTLS version and ciphersuites) for
> itself. So now we do it differently; instead of resuming a faked
> session we establish a new one, using a PreShared Key (PSK) that has
> been established over the TCP connection. That is the "NEGOTIATE-PSK"
> option.
>
> The --dtls-ciphers option that you're playing with, is what we send
> over the TCP connection to the server. We send a list of the options
> that we support, the server picks one and tells us which to use.
>
> If NEGOTIATE-PSK is chosen, nothing else from the dtls-ciphers string
> is taken into account. The standard DTLS negotiation happens using all
> the available ciphersuites. Perhaps we could entertain a feature
> request to restrict that dynamic negotiation... but nobody's made a
> good case for it yet.
If I'm digesting all this properly, --dtls-ciphers will effectively
*ONLY* allow arbitrary choices with Cisco AnyConnect servers ("legacy
protocol"), and *NOT* with ocserv.
Is that right? Should this be clarified in the manual if so?
Thanks,
Dan
