[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnutls-cli fails to handshake with Exchange server that uses DES-CBC
From: |
Ted Zlatanov |
Subject: |
Re: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher |
Date: |
Mon, 02 Apr 2012 08:39:58 -0400 |
User-agent: |
Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) |
On Sat, 31 Mar 2012 19:32:16 +0200 Nikos Mavrogiannopoulos <address@hidden>
wrote:
NM> On 03/30/2012 02:02 PM, Ted Zlatanov wrote:
>> On Thu, 29 Mar 2012 20:22:31 -0400 Thomas Fitzsimmons <address@hidden>
>> wrote:
>>
TF> Emacs allows overriding the default GnuTLS priority string using a
TF> variable (gnutls-algorithm-priority) so I set it to "performance" to
TF> work around this server-side issue. In cases where Emacs would
TF> otherwise fail to connect to a server because of a weak ciphersuite
TF> maybe the UI should warn the user and ask them whether or not to
TF> proceed. Anyway, thanks for analyzing the logs.
>> I don't think currently Emacs can distinguish this case from a normal
>> negotiation failure. The best we can do is to generally suggest a
>> weaker priority string, which seems to be a bad idea. Is there a way to
>> determine that this case has occurred?
NM> You cannot in general distinguish a negotiation with a broken server and
NM> negotiation failure. What (I think) browsers do is if negotiation fails
NM> they fallback to the most compatible mode (SSL 3.0 or so).
So you're suggesting to try a weaker (more compatible) priority string,
right? We could do that per server name. Considering we have just one
bug report on this and from a broken server, I'm not sure it's worth the
effort to automate the fallback. In your experience, is this a
widespread problem worth addressing through code, or is it better as a
FAQ?
Thanks
Ted
- Re: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher,
Ted Zlatanov <=