On 6 July 2018 at 08:28, Nikos Mavrogiannopoulos
<n.mavrogiannopou...@gmail.com> wrote:
> That option works only with older ocserv and openconnect versions. With the
> newer the TLS negotiation is the way the cipher is decided.
>
> On July 5, 2018 1:42:51 PM UTC, Daniel Lenski <dlen...@gmail.com> wrote:
>>On Wed, Jul 4, 2018 at 1:07 AM, David Woodhouse <dw...@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
>>
>>_______________________________________________
>>openconnect-devel mailing list
>>openconnect-devel@lists.infradead.org
>>http://lists.infradead.org/mailman/listinfo/openconnect-devel
>
> --
> Sent from my mobile. Please excuse my brevity.
Something really strange is going on. Please bear with me on this.
>From previous messages we arrived to this understanding:
1) with ocserv DTLS 1.2 one can only use PSK-NEGOTIATE in the cipher
string like so:
X-DTLS-CipherSuite: PSK-NEGOTIATE (= --dtls-ciphers=PSK-NEGOTIATE).
The DTLS-negotiation would happen with all available cipher suites.
2) Thus as a result, you are unable to force a cipher. The client
presents its ciphers, the server picks one (usually the first). So you
might as well not use it as it is the default cipher string.
Just to point out the obvious then: on the MacBook Pro this is the
result if you just let it do its thing:
X-DTLS-CipherSuite: PSK-NEGOTIATE
DTLS option X-DTLS-CipherSuite : PSK-NEGOTIATE
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(PSK)-(AES-256-GCM).
Let's say I were to ignore above and want 128-GCM instead.
I'll append "--dtls-ciphers=OC-DTLS1_2-AES128-GCM"
X-DTLS-CipherSuite: OC-DTLS1_2-AES128-GCM (this isn't allowed!)
DTLS option X-DTLS-CipherSuite : OC-DTLS1_2-AES128-GCM
DTLS handshake timed out
DTLS handshake failed: Resource temporarily unavailable, try again.
So all of this is as expected. It's PSK-NEGOTIATE or the highway even
when the server DOES support the cipher you request.
***But** on FreeBSD (Opnsense), this isn't true:***
X-DTLS-CipherSuite: PSK-NEGOTIATE
CSTP Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (highlighting server pref. here)
DTLS option X-DTLS-CipherSuite : PSK-NEGOTIATE
Established DTLS connection (using OpenSSL). Ciphersuite PSK-AES256-CBC-SHA
Yep, the server picked PSK-AES256-CBC-SHA as the client did not offer
any GCM-suites.
=> It was also the first cipher offered by the client.
=> I double checked with Wireshark.
Still nothing out of the ordinary going on. Negotiation did its thing.
But I'll append yet again "--dtls-ciphers=OC-DTLS1_2-AES128-GCM" for
completeness:
X-DTLS-CipherSuite: OC-DTLS1_2-AES128-GCM (here is that violation again)
DTLS option X-DTLS-CipherSuite : OC-DTLS1_2-AES128-GCM
Established DTLS connection (using OpenSSL). Ciphersuite AES128-GCM-SHA256
Now all is not as expected anymore. We managed to influence the
negotiation with the
--dtls-ciphers option. So, why is this happening? Why isn't the
DTLS-establisment failing?
And then I also got an unexpected present. But I'll update the correct
topic in a little while
So please head over to
http://lists.infradead.org/pipermail/openconnect-devel/2018-July/004978.html
regards,
Jeroen
_______________________________________________
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
