On August 4, 2018 8:52:33 AM UTC, Jeroen Balduyck <jeroen.balduyck at gmail.com> wrote:
>On 6 July 2018 at 08:28, Nikos Mavrogiannopoulos
><n.mavrogiannopoulos at 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 <dlenski at gmail.com>
>wrote:
>>>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
>>>
>>>_______________________________________________
>>>openconnect-devel mailing list
>>>openconnect-devel at 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.
The server should pick the same ciphersuite as in the TLS channel. However you raise a valid point, you have no way to affect that ciphersuite right? Either in the old or the new protocol. Indeed the oc client gives no control on the priority string used to negotiate. You can only configure it at server side. That looks like an omission.
>
>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.
It is a different protocol.
>
>***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?
It looks like a bug.
--
Sent from my mobile. Please excuse my brevity.
