On Thu, 2022-03-24 at 16:37 +0700, Frederic Muller wrote:
> So I removed the #DEFAULT and typed the update-crypto-policies. It
> did ask me to restart which I did, as you're mentioning right
> below...
Hi,
you "removed the #DEFAULT"? I'm a bit confused, I'm sorry. Strictly
following the commands I pasted make things work here. I really pasted
them, from a terminal where I gave it a try. The update-crypto-policies
gives a hint what cipher set it enables and it's required to be ran
after the changes in the file, otherwise nothing is modified in the
corresponding places.
> > Unless your Exchange 2010 server uses something even more ancient
> > than the Exchange 2007 I have.
>
> Is that possible?
I do not know.
When I move back to the DEFAULT crypto policies and run:
$ gnutls-cli exchange.server.com --debug=100
then it ends with:
*** Fatal error: The TLS connection was non-properly terminated.
and several lines above this is shown:
|<4>| EXT[0x55873a619140]: Preparing extension (Supported
Versions/43) for 'client hello'
|<2>| Advertizing version 3.4
|<2>| Advertizing version 3.3
.....
|<4>| HSK[0x55873a619140]: CLIENT HELLO was queued [408 bytes]
|<11>| HWRITE: enqueued [CLIENT HELLO] 408. Total 408 bytes.
|<11>| HWRITE FLUSH: 408 bytes in buffer.
|<5>| REC[0x55873a619140]: Preparing Packet Handshake(22) with
length: 408 and min pad: 0
|<9>| ENC[0x55873a619140]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
and above that a list of supported signature algos and cipher suits and
so on. When I switch to the LEGACY crypto policies the relevant part of
the log says:
|<4>| EXT[0x55ec797a21a0]: Preparing extension (Supported
Versions/43) for 'client hello'
|<2>| Advertizing version 3.4
|<2>| Advertizing version 3.3
|<2>| Advertizing version 3.2
|<2>| Advertizing version 3.1
...
|<4>| HSK[0x55ec797a21a0]: CLIENT HELLO was queued [432 bytes]
|<11>| HWRITE: enqueued [CLIENT HELLO] 432. Total 432 bytes.
|<11>| HWRITE FLUSH: 432 bytes in buffer.
|<5>| REC[0x55ec797a21a0]: Preparing Packet Handshake(22) with
length: 432 and min pad: 0
|<9>| ENC[0x55ec797a21a0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
followed by:
...
|<4>| HSK[0x55ec797a21a0]: SERVER HELLO (2) was received. Length
77[907], frag offset 0, frag length: 77, sequence: 0
|<3>| ASSERT: buffers.c[get_last_packet]:1176
|<3>| ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1428
|<4>| HSK[0x55ec797a21a0]: Server's version: 3.1
|<4>| HSK[0x55ec797a21a0]: SessionID length: 32
|<4>| HSK[0x55ec797a21a0]: SessionID: xxxxxxx
|<4>| HSK[0x55ec797a21a0]: Selected cipher suite:
GNUTLS_RSA_3DES_EDE_CBC_SHA1
|<4>| EXT[0x55ec797a21a0]: Parsing extension 'Safe
Renegotiation/65281' (1 bytes)
|<4>| HSK[0x55ec797a21a0]: Safe renegotiation succeeded
...
and then it fails on not-trusted certificate, but it is able to connect
to the server when the LEGACY is used.
I do not know how the GnuTLS works under the hood, neither how to
decipher its log, I only know that the evolution-ews uses glib, which
uses glib-networking, which uses GnuTLS under the hood.
You can run as a regular user:
$ update-crypto-policies --show
$ update-crypto-policies --is-applied
$ update-crypto-policies --check
which should return, in the same order:
LEGACY
The configured policy is applied
The configured policy matches the generated policy
as it does here. There are probably other ways how to enable even more
ancient algorithms/ciphers/..., but I do not know them. If the above
doesn't work, then I suggest to search the Internet. Giving the search
page an exact error message, and adding "GnuTLS" to it, may help to
limit the answers, hopefully to the most relevant.
Bye,
Milan
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
